This was originally posted on my own website and LinkedIn, I want to open the discussion further though

Preface: Everything here is my opinion, and I'd love to have a discussion on this with anyone else involved in recruitment or if you're looking for a new role!

Hit me up on Twitter if you have any comments or want to start a discussion

Interviewing In Software Development Is Broken

Over the past couple of years I've been on both sides of the interview table, as well as speaking to many friends and colleagues who have been for interviews as well, and it's become apparent to me that interviews for software developers are broken, and we can do better.

Technical Tests

One of the main things that is very prevalent these days is the take-home technical test. Generally this appears to be given after a phone interview, sometimes a first face-to-face and is meant to gauge the skill level of the candidate.

I have to be very frank and say I don't think this helps anyone gauge a skill level.

Generally these tests are given with a provision of "we expect this to take a few hours, but take all the time you want to with it", this is wrong. Asking someone to do work in their own time to prove their worth to you as an interviewer does not sit right with me, and I say this as someone who has completed these assignments (and likely will continue to do so until the industry changes). This idea of doing homework to prove you're good enough can give me the impression that a company will expect you to work late when asked, and while I (and most people I know) don't mind this every now and then, it's not a great start.

Usually these tests are also based on a problem that has no bearing on what you'd be working on when working for a company. I appreciate companies can't give away their trade secrets in technical tests, but working on completely random problems does not give you an indication of what the work for a company will be like.

Candidate is interviewing you

This is a key thing that so many recruiters forget, I'm guilty of it myself. We think that the company we're recruiting for is good enough that it should just be about us being convinced a candidate is for us.

What it's easy to forget is that candidates are interviewing you just as much as you are them, they will have their own questions, they'll want to know about the culture you have, and there's no point in lying or bending the truth here, you'll be found out soon enough.

I've had interviews over the years where companies were very much against giving any information about what day-to-day life looks like, or how the interview process goes. It was a bit of a shock when one company told me after a second phone interview that there were still 3 more stages of interview potentially ahead of me. Had I known that upfront it wouldn't be so bad, but finding it out after getting to a stage where I felt I'd be in a position to either be offered a role or not, that was a shock.

Lack of Feedback

Now this isn't something that only happens in the tech industry but that doesn't make it any less problematic. This is an especially important thing when you are using technical tests to screen candidates.

Providing feedback allows candidates to grow and learn, and that is absolutely something we should be encouraging. A friend of mine had completed a technical test for a role and they felt they had produced good work with good test coverage and understanding of the problem they were asked to resolve, the only feedback they got? "This is the work of a junior", that type of feedback is not helpful to anyone. How can we expect people to learn if we won't discuss or comment on what we feel they didn't achieve from what was asked?

Maybe the work provided was that of a junior at the organisation, however what made it that way? One email, or a 20 minute conversation is all it takes to help people going forward.

How Can We Make Things Better?

So it's all well and good of me to complain about the process and say we can do better, but the big question is always going to be "how do we do better"?

I've spent a lot of time thinking about this, and there are a few things I believe we can do.

Utilise Probation Periods

I have never had a role that did not include a probation period, the chances are you're the same. Generally this is a pre-determined period of time that's either 3 or 6 months. This is when as a new start you learn a lot about the company and how they work, this is also your proper time to shine and show your skillset.

For me, companies should be using this time to assess whether someone fits the skillset they were hiring for, I know this may mean hiring having to start again, but if someone comes into the company and doesn't like what they've found, that's the case anyway.

Using the first 3 months to see if your new hire is fit for purpose lets you learn how they work with the others in your team, how they solve problems, what they can offer to the team and just how they are as a person.

This would be my recommendation instead of a technical test, you'll gleam so much more useful information about a candidate this way than what you can from a take-home test that they spend 4-8 hours on in isolation.

Technical Tests

Now, I've been very vocal on my dislike for take-home technical tests (as well as random Whiteboard questions), but that obviously doesn't mean you can dismiss assessing someone's technical skills for a role, especially as you get towards more senior roles.

During the interview process I feel it would be much more useful to talk through a problem with a candidate during a face-to-face or Skype interview, this should not include code directly, I've never met a software developer who was unable to learn how to use a tool or language when they had to, the value comes from their ability to solve a problem.

If you insist on using the take-home test, this can be made better. Provide a sample application for a candidate to work from, and then provide a ticket that would be similar to how a ticket would be picked up from your actual workflow. This not only allows the developer to have clear requirements (hopefully) and understand your process a bit better, it also lets them evaluate your code style, testing strategy etc and potentially add their own spin to it or provide suggestions if they feel there's something else that can be done.

Conclusion

I do truly believe that interviewing in software development is in need of some changes to make it simpler for both candidates and recruiters, as an industry we certainly can make this better.

I'd love to chat with people who have issues with software development interviews, discussing what they are. And also with people who find the issues I've raised above, well, non-issues and why they feel these benefit either the recruiter or the candidate.

Please get in touch on Twitter if you want to discuss more!