We’re a very small team with little experience in hiring but got approval for a new engineer. Basically HR will look for people through the usual channels and I think we have a reasonably good job description. Unfortunately the coding challenge (a 30h+ take home) is atrociously difficult and doesn’t really reflect what we do. On the other hand I think the false positive rate would be low. FWIW it’s a Linux application and it might be difficult to only count on experience from the CV.
Any ideas how to build a good challenge from scratch and what time constraints are reasonable?
A 30h+ take home that doesn’t even reflect what you all do is a waste of everyone’s time. I’d think most qualified applicants are going to ghost you when they are tasked with that. You have to keep in mind you’re not the only place they’re applying. Are you sure you want the engineer who has time for a 30h+ coding challenge for a potential job, that might then make a competitive offer?
I loved our test at my last company.
Do an API exposing a fizzbuzz. Make it “prodable”.
The definition of production ready is completely for the candidates to determine .
The subject is simple, doable in a few hours. What we were looking at was how code was organised, tests, usage of libs, …
What is your goal for the coding challenge? Right now you’re screening for the most desperate and willing to cheat with a 30hr busywork assignment.
Short answer: don’t. Ask questions that demonstrate familiarity with concepts that you and your team encounter in a regular basis.
If you insist on a coding challenge, give them an old but difficult problem your team encountered in the job and assess how they would solve it.
You will lose the best candidates with an onerous coding challenge.
Our process, which has been heavily influenced by debate on r/experiencedevs on reddit involves a short phone screen, a 30 MINUTE coding challenge, a tech interview consisting of pair programming, and a non-tech interview with management. Very light.
The coding challenge is a FILTER only. It’s not to evaluate who to hire, but instead it’s to filter who not to continue interviewing.
You learn a lot during pair programming in a short period of time, including personality and team fit. We let them drive and we just watch and discuss. The assignment is to fix a bug, and refactor the code the caused the bug.