Recently I’ve been asked by an HR person to tell which factors influence Java programmers wanting to change a job, what is important when we consider a change. I gave it a great deal of thought, and the result has been so extensive as to warrant a blog post. Which I now present here.
I don’t aspire to cover everything or to be completely objective, but I’ve tried to think of everything that can be important from my point of view. So, here goes everything.
- Compensation. You will hardly hear it explicitly named, but the truth is, we all want to eat. Please state at least the lower compensation limit in your vacancy. If you do, you will do vastly better than the usual generic ad that gives no financial details. Developers hate the ubiquitous question “and what kind of salary you would be satisfied with?”, which they usually get instead of an answer. I’d be great with a million dollars, why?…
We all know that the money factor will be one of the most important. OK, suppose the company policy doesn’t allow you to publish actual figures. But you know what? Almost all developers (and not just them) are acquainted with the website Glassdoor, and when you don’t give them an answer, they will use it to look it up. So, it’s your responsibility to make sure that what they find there will be as correct as possible.
If you company doesn’t publish any wages info in the ads, and you don’t have any statistics on Glassdoor, then you’d better provide some. It’s a lifehack I don’t usually share, but – please go ask some of your devs to go and post their real data. The transparency will be better for your company in the long run, at least if you really do competitive salary. If not, the dev will find out anyway, but he’ll be frustrated because of the wasted time.
You do want to catch the flies with honey, right? Not with the other stuff.
This also includes salary reviews. Are they regular or only happen when the dev comes to you with an offer from a competitor?
- Company reputation. Hard to make, easy to break. Don’t do anything that will be the talk of town on devs message boards and will turn off your potential employees.
This also includes a point of being hired by a “cool company” – it’s important for some people to work for one of those.
A lot of people would want to work for a cool company. There’s a robot in XXX’s company hall. It’s cool. Robots are cool. (quote from a colleague, company name taken out because it’s not relevant here.)
- Tech stack. In Java case – not many people want to work with Java version lower than 7; and for some even Java 7 is already not current enough. GWT? Isn’t it, like, ancient? Oracle database? Why don’t you guys use something noSQL? Ah, you have financial information and you need transactions and relational consistency? You are so 20th century.
- It should be noted though that there are two types of devs here. The first type wants to work with what’s new and current, the second type prefers to become experts in some specific field. So, if you are dealing with the second type, this factor will work the other way around – that is, the expert will prefer to be hired for his expert knowledge.
- Project domain. It’s a sad truth that most devs don’t like banking and finance a whole lot. Medicine, publishing business, energy sector will probably be neutral. Everything that is related to Big Data or Data Science or Microservices or Reactive programming or whatever the current buzzwords are will catch more “flies”.
- Even if the business domain doesn’t sound very hot right now, there might be challenging areas and tasks. For example, financial and banking apps are usually performance and consistency critical, should be very scalable and therefore have a lot of optimization and design task that might present a challenge, interesting for devs of a certain – senior – level. So, that’s what the job ad should focus on.
- Is is development or support? If it’s the latter, then the senior devs probably won’t be enthusiastic. If you have a lot of new features to implement, then why not.
- Is it a product company or an outsource? Here in Europe, a lot of devs start their careers in outsourcing companies, but then some get tired of being just a hired hand. They prefer to be a part of a company which is actually making something, so that they can feel they are making a difference. Though if I speak for myself, I don’t think I’d feel much difference, except in case when the product company would offer their stock or stock options.
- Professional growth. Is there a roadmap? Do you have a list of requirements which a dev must implement to be able to move up the ladder? Is that a formal or informal process? Also, what about conferences, courses, certifications?
- Telecommuting. The teams now become more distributed than ever, and therefore the companies must allow for greater flexibility. If part of the team is in US, part in England, part in Poland and part in India, do you really need all the people to work exclusively from the office? If you are flexible on this point, you win more souls again.
- Flexible schedule. But of course you must plan for adequate communication windows when all the team can sync together.
- Project duration. Not many devs like switching the context too often. On the other hand, there should better be a way to make a switch at some point when it just becomes boring.
- Relocation. It’s very relevant for some countries in the Eastern Europe, and especially for Ukraine right now. Is there a possibility that you will provide it? To what extent you help implement it? Do you cover the expenses, and if yes, what are the bounds? How much help are you with all the legal stuff? This topic can go on and on.
- Business trips. Contrary to the popular belief, they are usually a bonus, and not just for male devs (within sensible limits of course). It’s not just a way to work closer with the client, but a break in the routine, a change of scene. It’s beneficial.
- What happens if the project ends. Do you transfer the devs to something else? Do you just let them go?
- Social benefits. Insurance, vacations, maternity leave, dental, whatever you have there.
- The extras. All the frills and bells and whistles you also have in your company. Annual team building events abroad? Hot meals delivered to the office? Great holiday parties? Massage chairs? Stand-up desks? Bring them on.
- The size of the company. You can’t change it, but it will be something for people to consider anyway. Some will prefer a smaller company with an informal atmosphere, some will be content to work for a giant with a big name but a lot of bureaucracy. It’s individual, but it affects us anyway.
And in the end, the Java devs are only people who are just looking for a better life.
Aren’t we all?