Looking for a new job is a lot of work. The search process is a job in itself. You have to make sure your resume is up to par, your cover letter is specific to that job, and all the other stuff. It's stressful sending applications out into the void and hoping you're good enough.
On the other side, good developers are expensive. As a company looking to bring in new people, you don't want to hire a dud. So how exactly are you going to sort the duds from the stars? You have a limited amount of time and the backlog is getting bigger every day.
So it seems we've settled on a process that generally sucks for both sides. It's long, sometimes vague, and complicated. The whole thing is a mess, although there are a few parts that are especially ridiculous. But what are the alternatives?
Applications
Everybody has their complaints about filling out applications, like the ones that ask for your resume just to make you write everything that's on your resume. Or the ones that ask you to write an essay on why you want to work for them. That's fine if you only have a handful of jobs you want to apply for but that's not the case for most people. When you are really looking for a job, you're trying to apply for as many as you can because you know a lot of them won't get back to you.
It takes time to try and tailor your resume for 40+ jobs. This brings up the problem for the other side too. When you have 1 job opening and you get over 100 applicants, how to do sort through that many applications? That's why so many application processes are getting more cumbersome. If you can weed out the people with a long application process, maybe you'll get a better pool of candidates.
Of course that's not always the case. You'll find people applying for jobs at different points in their search and your energy level changes at each of those points.
Rounds of interviews
This is rough on both sides, but probably more so on the applicant's side. I've gone through half-day to full-day interviews called "running the gauntlet" only to wait a month for them to say no or nothing at all. It's a part of the process and we all get over it. (shrug) Still, it's frustrating when you have to use precious vacation time to go on interviews that lead nowhere.
You could have multiple rounds of interviews spread out over weeks. This leaves you in a place where you have to figure out how you can miss an hour or two of work so frequently. Going through three rounds of interviews gives you a better idea of how a person might perform in a job or with your team, but it will never really tell you how they'll do. Then you are taking time away from your current employees to get work done to go through all of these interviews.
Interviewing candidates takes up just as much of your time as it does theirs, but it's one of the best ways to get to know each other. After the first interview, a candidate could decide they don't want to work at your company anymore. Maybe your goals don't align with theirs or they found somewhere they like better. There's only so much both of you will learn from multiple people asking the same questions.
Coding projects/tests
By far, this is one of the most double-edged ways to test a developer's true skills. It's a great way to assess someone's experience, but it's not truly accurate. When you tell a person to start writing code in front of you for a problem they only get five minutes to review, that doesn't simulate the way we do real work. No one writes perfect code the first time or even the correct tests. It's amazing the thought paths that people can take to solve a problem.
So we try the "take home" coding projects. This was a wonderful solution until the projects turned into four hour tasks or issues from the real backlog. When projects start to take up two to three hours a night for a week, there's a problem. Who has the time to take a mini-job in order to possibly get a job? In theory it's a great idea, but in practice it still puts people in a weird place.
Do your current developers even have time to review the code for all of those applicants? Even if it's just ten applicants, that's still hours of time reviewing code that probably won't be useful outside of the interview. Your current developers still have work to do and that could take ten hours out of their work week, as an example.
All the other stuff
Take all of the things from above and combine them. Then you have a clearer picture of the full process of getting a new job. Now you can factor in whiteboard coding, demos for the projects they give you, and maybe some kind of multiple choice test. You might even get lucky enough to take a personality test. Overall, the whole job process is hard and it takes a lot of patience and work to get through.
Solutions?
At the end of the day, everybody wants to make sure they land a good position. Not one that just pays well, but one that lets you live your life while the company gets to make progress. What exactly can we do to make this whole thing better for both sides? The coding projects were a good idea until they started getting longer and longer.
Is it even fair for a company to ask you to work on something directly from their backlog? (question-face) Or would it be better for them to make up a relevant, random task? It feels like it hard to say because both sides are going to invest time and potentially money in this search. What can we do differently?
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (3)
The thing is that with all the tests being passed and only "the best" being hired, and with all the pattern and design and best practices books being written and debated, you would think that by now software development industry would be in great shape by now. Bad legacy code would be a thing of the past... Nope. New bad legacy code is being written right now as I am typing this. How come ? Technical tests are not the answer
I don't like those either. I took one earlier this year and got rejected, probably because I'm too much of an introvert. At least I know not to apply there again, and that I'm probably not going to want to work at a company that has a personality test.
Also with the take home projects, the success parameters are unclear. What are they looking for? It's a huge time suck with little to no return if you "fail." Sometimes there are a million ways to achieve the same result in code, which one are they looking for? With some tech leads preferring speed over quality, and "cleverness" over readability even if you complete the project there will always be some bias you're unaware of, I mean for example just look at how long style guides take to hash out and the disagreements over spaces vs tabs. The goalposts are often unimaginable!