Technical Interview Assignments Design Guide (An Interviewee Perspective)
I’ve been writing assignments lately due to interviews.
I am happy to see the software industry turning assessment approach from doing LeetCode (or whiteboarding) to a way that is more closely to how most engineers handle day-to-day works.
However, the recent experience with take-home assignments is a pain to me, mostly because of how the take-home assignment process is designed. I got rejected replies like “not fulfilling requirements correctly” or “we don’t like your architecture”… etc. Got rejected without solid clues makes people really confused and frustrated.
Here are some thoughts that I think could improve the process:
Explicitly Declare What Tools Can be Used and What Tools Cannot
Regarding the use of libs/frameworks, you might be thinking of using A is enough, but your candidate is thinking of B. The effort is bound to be different, and thus the time/effort estimation will not be on the same standard.
By explicitly saying what lib/frameworks can be used and what cannot, will help both sides to narrow down the scope, eliminate the grey zone, and thus clear potential misunderstands.
If you want to give your candidate the freedom of choosing libs/frameworks, please soften the time limitation. Your candidates might spend extra time evaluating tools and learning the usage.
Make Specification VERY Detailed
Explicitly define requirements like what browsers should be supported and what should not be, what platform the project should be deployed to, what it is going to do when a user clicks the button…etc.
Ideally, the mock-up design should be provided, but when it is provided, you have to name what will be taken into account in and what will not be.
These will help define the boundary of the assignment. Do it in the way like how you ask your project manager/product owner to write the specification.
No Bonus Requirements
The bonus section is a lie. There are only things that you will assess and things you won’t. Grey zone are not allowed here.
If you are going to assess criteria like tests, architecture, coding styles, be specific what you expect to see, otherwise, everyone has their own opinions on these parts and will possibly consume lots of candidates’ time if their standard is beyond your expectation.
Do it Yourself Before Sending it to Your Candidate
When you have done designing an assignment, please write it yourself like an interviewee. Ask engineers who match the mentioned experience in the job description to do the assignment. You have to estimate how much time the assignment is going to cost.
If you spend x hours, multiply it by 2 or 3. Your candidate might not have the same skillset as you do, they will require extra time to do some survey.
Arrange a Retrospective Meeting after Done Submitting the Assignment
This stage tries to simulate a PR code review. Human errors and have different opinions on things. Give the candidate a chance to justify him/herself, asking how to fix an overlooked bug in the assignment, asking why and what’s the reason for a specific approach. It should be a discussion like how your team runs a PR.
—
These are all the caveats that I conclude by now.
The whole thing is aiming to simulate the onboarding life of first 1 ~ 3 months before the engineer could take harder tasks.
A crappy defined assignment is like a foot gun. You shoot in yourself, wasting tons of time on reviewing assignments that you think that is poorly made, complaining why a capable engineer is so hard to find while overlooking the fact the way you access is not even clear. It’s a no-win situation, both you and the candidate waste tons of time on each other.
A good assessment should eliminate the grey zone as possible. For the god sake, please stop playing the game of “I have opinions, but I am not going to tell you. Guess what I want.”
