Let's continue on the topic of designing a pragmatic coding interview and before we start let me share my view on what makes an interview pragmatic.
💡 A pragmatic interview is the one that evaluates one's ability to complete a real-world assignment that closely resembles a day-to-day task, where the evaluation is based on a standardized rubric.
It's as simple as that, however, it's easier said than done. This is why we'll continue with zooming in on how to design such an interview.
Today's topic is designing a challenge description. This one probably has the highest chance to define how much time will be spent on the challenge by both the candidate and the interviewer (and also it can both increase or decrease it). So let's see how to not screw it up.
We'll use this Github issue as an example.
Take your time to go through this issue but if we were to define a distilled structure it'd go like this:
1️⃣ Brief background - just gives an idea of what this is going to be about.
2️⃣ Setting expectations - telling them how their solution will be evaluated.
3️⃣ Submission checklist - for them to know where they stand with their submission.
4️⃣ The definition of done - good to be clear on, isn't it?
5️⃣ FAQ - they will have questions, this should cover most of those.
There're only 5 but very important steps here. If you got an interview assignment already take a minute to see which of the points above it hits.
And if there's something I missed, please share it in the comments below. I'm a big believer in incremental progress and that there's always a chance to improve. 🙏
Top comments (0)