I recently replied to a tweet about take home projects for developers as part of a recruitment process. Well, it so happens the original tweet went wildly viral which meant my reply had more engagement than I’ve ever had on X! It also so happens that I have quite a lot of opinions on this, not only because I’ve hired dozens of developers over my career, sat a fair few tests myself but also because I was CTO of a developer testing platform for 4 years.

First and foremost, the biggest issue with take home projects is the invasion on the candidate’s time. The open ended nature of a take home project typically leaves the candidate with having to determine how far to take the project and trying to second guess what the hiring manager is actually looking for. Realistically, in a developer job, any throwaway project should probably be optimised for efficiency but take home projects are supposed to be your chance to showcase your skills. Honestly, if I set a test and a candidate came in and said they deliberately kept it as simple as possible because the project was going to end up in the bin - I’d probably congratulate them! We all know that’s not what the majority of hiring managers want to see though, and you’d better architect that FizzBuzz solution as if it’s some enterprise software that can scale to 1000 concurrent users.

The other problem with take home projects? They usually aren’t reviewed properly. The original tweet I referenced was a perfect example of this - spent a weekend working on it, invited the reviewer to the GitHub repo, rejected for the job and turns out they didn’t even accept the GitHub invitation! Even the ones that are accepted though - how much insight can you really gather from static analysis of code? Personally I’m not a fan of asynchronous code reviews generally because they tend to fall into two camps - small changesets get scrutinised to the nth degree, large changesets get a LGTM and signed off immediately. I know there’ll be some out there who will use the take home project as a discussion point at interview, and I’ve done this myself too, but how many times have you completed this kind of exercise without it even getting as far as interview? A waste of time for both parties.

So, what’s the alternative? Well in my previous role at Technically Compatible (I know, dreadful name) we supported a range of question types with a view to assessing candidate coding ability and knowledge. Firstly, we had code challenges which recorded your actions for playback. The theory was that the playback element would catch issues such as copy and pasting answers, but in hindsight I don’t believe that was the right approach. If you have a task to complete a simple, well known code problem why wouldn’t you look up one of the widely accepted solutions to that problem? Other question types included video questions (again asynchronous) and multi-choice questions (not reflective of anything really) - both fairly commonplace but neither really reflective of anything you need to actually do the job.

Other approaches I’ve seen include candidates being expected to share their GitHub profiles - and as somebody who has always pursued side projects via GitHub I don’t mind that from a personal perspective, but realistically a candidate’s side project is a poor measure of their suitability to do a specific job, assuming they even have side projects to begin with. The context in which they completed that side project may be totally misaligned from how they would work on a project day in, day out. There may just be one refactor between an unacceptable solution and an acceptable one but that nuance is totally lost with a static code review.

When I look at all of the aforementioned I feel the major issues with them all are that they are a) asynchronous and b) not reflective of anything you do within work. The one thing I think you can do which is synchronous, reflective of work in the real world and provides a lot of additional insight is pair programming. As a hiring manager you could find a self-contained problem within your real code base and pair it with a candidate for an hour. You can discover their approach to new problems in an unfamiliar codebase, you can get an inkling for how well you will get along, you can check that they will ask questions when they don’t understand something - all things that are completely lost in asynchronous code exercises. Also, because you both need to make time at the same time there’s no pressure on the candidate to keep going and going until something is perfect (also no risk that your work is going to go unseen!) I appreciate that for some candidates they may find that a pressurised environment where they will struggle to thrive but this is one time where I feel the benefits outweigh the negatives.

What other approaches have you encountered that work well? Send me a message on X and let me know about your experiences - positive or negative!