When hiring at my last company, I suggested we should offer two possibilities for the technical part. Either to bring a simple but well documented engineering project compatible with the role or take out challenge, which consisted of deploying a couple of services and a static website to a cloud provider using whatever means of IaC and cd pipeline technology.
I made sure to do the challenge too both to have a reference and to validate it.
Not sure I agree about free work. There are things you can't possibly evaluate in an interview. For a senior role, I'd expect good documentation skills and the ability to present tradeoffs of their designs, which is the purpose of these technical steps.
It also creates the bar of "can this person actually code" that fizzbuzz used to cover. I would take an unpaid assignment 10 times out of 10 instead of a stupid leetcode session.
I would caution against the bring your own example. I’ve found myself nodding off and getting distracted because while it may seem interesting and important to you, and you may have done something legitimately cool, it may not be interesting to me, you may be bad at presenting it, you don’t have sufficient time to go into sufficient detail, or I may not have the requisite background to understand in the limited amount of time we’d have together. I think it tests things that aren’t a good signal.
Depends on how you use it. If you use the project as a motivation to start a technical conversation it's ok. You had access to the documentation before, so at least you have an idea of the project. If the documentation isn't enough for you to prepare for the interview, that already tells you something about the candidate.
1. Make a VERY lucrative well paid dev job posting (completely fake)
2. Make them do home assignment that is actual work that needs to be done. Make sure the candidate understand how important this assignment is for their chance to get hired.
3. Tell the candidate you are not moving forward with further interviews since their work was shite
4. Profit!!!
Yeah I don’t understand this. It’s a fantastic tool for young employees - it tests that you have the coding chops in a meaningful way, and it typically isn’t a huge time commitment for people who generally have limited responsibilities. You should make allowances for those who have limitations but I think people have been throwing out the baby with the bath water.
That being said, they’re a bit challenging to manage on the employer side for the same reason as hacker rank - maintaining a pool of high quality questions that haven’t leaked is hard.
As a proxy I usually instead give design questions about relevant difficult problems I’ve seen and solved at work. Even if I blog about it I’ll either be able to tell if the person is parroting the solution back to me or legitimately solving it on the spot and it’s something I know inside and out well enough that I can give answers to hypotheticals they ask me.
Still, figuring out who’s going to be a good hire is a challenge whatever tools you try to apply so I haven’t gotten so invested on any one technique. Bad review processes are much worse and orgs are stuffed with them despite best efforts (lots of subtle social pressure mechanisms with people oblivious to what’s going on or not caring).
I made sure to do the challenge too both to have a reference and to validate it.
Not sure I agree about free work. There are things you can't possibly evaluate in an interview. For a senior role, I'd expect good documentation skills and the ability to present tradeoffs of their designs, which is the purpose of these technical steps.