Job hopping is not considered an admirable trait, at least by employers. There is not much for them to like about a developer that leaves after a short tenure. Hiring people is an expensive process since it requires the expense of recruiters as well as time spent by the existing development team for interviews. Time spent in interviews is time that could be spent building software. This makes a developer with wanderlust extremely costly for a company.
There’s also the issue that developers tend to take a while to become 100% effective at a new company. Software systems are complex and it takes time to learn how a company’s systems work. Depending on the company it can be as short as a couple of months, or it can take a year. A developer who leaves a company soon after gaining that context on a company’s dime will deny that company from getting the full value out of that developer.
That’s from the employer’s perspective. Here’s the developer’s perspective:
Job hopping is advantageous most of the time.
Software development is complex. There are many tools a developer can choose to use for a problem at hand. The more technologies and patterns a developer uses, the more tools they have. That enables them to make better decisions.
Starting a new job is a huge opportunity for learning new things and getting new tools. A developer learns the most while gaining the context in how a company’s systems work. They experience technologies that they may not have experienced at previous companies since every company tends to do something that is different. There is always something a developer doesn’t know, but can learn: be it a new programming language, framework, database technology, cloud provider, etc. More importantly, there is the opportunity to work with other developers who have different experiences and knowledge that can be shared.
Yet most of that learning happens as a developer is just starting out at a new company. The developer will experience a diminishing return on time spent at a company the longer they stay. They could learn more by moving on to another job and repeating the learning process.
The exception to this is the fact that developers need to balance making technical decisions that benefit a company in the long term versus the short term. But there is no magic button for “make this work for the long term.” Sometimes what you think will work in the long term ends up not working as well as you thought. Developers learn to make good long term decisions by seeing the results of their earlier decisions. Getting feedback on whether you are right or wrong about something is essential to making better decisions in the future.
A job hopping developer will never have the opportunity to get the feedback on their long term decisions. They simply aren’t at a company long enough to see how their decisions will play out. All they will ever have to go on is what sounds good on paper. They will lack the experience required to know what will actually work.
Making good long term decisions is one of the most important tools in a developer’s tool belt. Not having this will severely hinder a developer’s ability to do good work.
So companies clearly benefit from developers sticking around for a while. Developers can benefit both from sticking around and hopping from place to place. Companies can collectively choose not to hire developers with a history of job hopping. However the job market is clearly in favor of developers these days. The laws of supply and demand have made it so that unless that company is Google, Microsoft, Amazon, or any other hot name, a company can’t afford to be picky. A great developer with a history of job hopping is better than no developer or a developer who does negative work.
I’ve had recruiters contact me my first week into a new job asking me if it’s working out. That is how little companies care about job hopping because of how hard it is to hire a developer in this job market.
What needs to happen is that companies should make it just as advantageous for a developer to stick around. That means creating plentiful learning opportunities.
Conferences and meetups sound great, but they are not sufficient. You can get introduced to a lot of new ideas at a conference, but it won’t help very much until you get to put the ideas into practice.
Hackathons and side projects can help sometimes, but those tend to be of limited benefit. A lot of software development is adapting to situations that come up when lots of users are using the application. There’s also the level of motivation involved. “Don’t feel like it” is always an option to avoid working on a particular feature in a side project. It is less of an option for a job.
Unfortunately there are no easy answers to this problem. Every company is in a different situation and that affects what they can afford to do.
A larger company with multiple teams could allow their developers to switch teams every 6-18 months. That will allow the developer to try new things since different teams tend to work with different technologies. It also helps to work with new people that have different experiences to share.
Google made famous “20% time” which allowed developers to spend 20% of their time working on a project that they come up with. This can fall into the same issues as side projects though unless those projects are going to actually have users using them.
A company could allow a new technology to be used for a new project solely for the sake of trying something new. This is a very poor reason to do something from a project management perspective. But it may be worthwhile from a human resource perspective.
Some companies are in complex businesses that requires a wide variety of technical solutions. This complicates the development of their project(s), but it does provide the advantage of giving their developers variety in the work.
In the end, most ways of providing developers with learning opportunities will have a cost to a company. The short term math of letting a developer try something different rather than do what they do well will never work out in favor of letting a developer learn something. Spending time learning will always be an immediate productivity hit. But that cost needs to be balanced against the cost of a developer leaving in order to improve their skills.
I would love to hear from you if you have experienced a company that handled this situation well!
This post was originally published on blog.professorbeekums.com
Top comments (10)
I'm not sure where I'd be without this kind of feedback. Making it valuable for both the developer and the company to create lasting relationships is key.
One more thing... what about the third option of leaving and coming back? I feel like that's a reasonable scenario that doesn't wind up happening enough due to resentment or old-timey ideas of loyalty. If I wanted to go to a different kind of company, learn a lot, but be welcome back with open arms if I were to return in the future, it would be a pretty great outcome for everybody. It's not unheard of, but it's rare.
Hi Ben,
I totally agree with you about the third option. This is an absolutely valuable option.
It's great for developers to see other company structures, policies and tools. This will let developers value the things, they had in the previous job.
As you already said, it's also great for employera. A developer may come back with great possibilities to improve processes, which have been successfully established in other companies.
It should happen more often.
Yeah, I think there is definitely an advantage to sticking around for a little bit. I've met a lot of developers who know a wide variety of technologies, but don't actually have the skills to maintain a large production system because they've never stuck around long enough. Yet there's a balance there. Stay at some places for too long and the developer usually stagnates a little. At that point the option to leave becomes more advantageous than sticking around.
I don't have any scientific evidence of how well leaving and coming back would work, but anecdotally I have never seen it work out well. The people I know who've done it only did so because the place they went to was much worse. Going back was more a decision made out of desperation rather than positive intent.
I've received feedback on projects done at former employers from former colleagues. It's not as formal or measurable, but it's something.
At what point is changing jobs considered job hopping? Is it based on time at a company? Would switching jobs after working for a company for a year be considered a hop? I'm thinking it would probably depend on the time required to get to 100% effectiveness, but is there a general trend recruiters look for? And what if a developer is changing jobs due to relocating? If a developer started a new job and then moved to a new city 6 months later, would that look like a job hop?
It really depends. I think getting ramped up at an early stage startup is much easier than ramping up at a place with years of technology built. Usually takes me 6-12 months to be fully effective, though most developers should be able to produce good work within the first few weeks.
Not sure if relocating matters. Most developers have the option to work remote when moving. Even if a company doesn't want it to be general policy, it's better to have a remote developer who's proven to be extremely valuable than to lose them simply because they want/need to live elsewhere. Besides, the resume is probably not going to say whether a relocation was due to wanting to switch jobs or for other reasons. That'll most likely be covered in the interview at which point it's up to the interviewer's discretion.
I think it is mostly based on the time at a company. How could a recruiter possibly know the time to get 100% effective at a specific company?
I also think that it is not considered a "job hop" when you change your employer once or twice in a short period of time. If it happens more often, it is definitely job hopping. But that is my personal opinion.
Most of my short tenures have been involuntary. Startups that double or triple in size within the year, get acquired, or pivot (I hate this buzzword) can turn my job on its head. Maybe I enjoyed working there when I joined but aren't happy with the direction now. What am I to do? Suffer through the pain of working somewhere when my heart isn't in it anymore just so that I can hit that arbitrary 12 months milestone?
Sticking around isn't just about feedback, but also longevity of project. Spending a quarter turning up a new service and spending two years maintaining that service require different mental skills. You don't get the skill of maintenance without working a long stint.
I think you just pointed out one thing I missed in the post. 2-3 years is a good amount of time to start seeing the results of some long term decisions. But what about companies that prefer to keep you for 5-10 years? At that point there's a much greater advantage for the developer to leave while the company still prefers they stay.