The Golden Rubric for Technical Interviews
Landing your dream software engineering job is difficult. For many, the coding interview is the mighty beast that must be defeated before being hired. Thankfully, the internet is saturated with resources to help prepare for the data structures and algorithms questions that will be asked. However, your answers to these questions make up only 1 component of what interviewers look for in a successful candidate. In fact, it’s 1 out of 6.
In this article, I’ll shine light on the 6 categories that interviewers use to grade your performance. Each category is assigned a score (1 to 4) with 24 points being a perfect score.
Is My Score Good?
A perfect score is rare and not having a perfect score should not discourage you from applying to companies.
“There is no trap so deadly as the trap you set for yourself.”
— Raymond Chandler
The worst thing you can do is to convince yourself that you should apply to jobs only when you have a perfect score, or only when you have the right number of projects in your portfolio, or only when you feel like you have mastered all of the topics in Cracking the Coding Interview. Interviewing at companies is the best way to prepare for interviewing at companies. That seems obvious, but may not always feel so when you’re in the midst of studying for these interviews.
This rubric should be used as a North Star. Aim for perfection (24 points), but understand that not getting there does not mean that you won’t get your dream job. Now, I’ll go over the categories.
1. Coding & Syntax
4 Points [Strong Hire]
- No syntax errors
- Translated solution and future improvements into code effortlessly
- Demonstrated exemplary knowledge of language constructs as well as paradigms in other languages
- Compare several coding approaches
3 Points [Leaning Hire]
- Few-to-none syntax errors
- Translated proposed solution to code with little difficulty
- Showed familiarity with common language constructs and paradigms
2 Points [Leaning Don’t Hire]
- Minor syntax errors
- Coded the naive solution but stumbled on occasion
- Poor use of language constructs
1 Point [Strong Don’t Hire]
- Several errors (logical or syntactic) that severely impacted the correctness of the solution
- Poor use of language constructs
2. Data Structures and Algorithms
4 Points [Strong Hire]
- Explained the naive solution and its drawbacks, then explained several solutions, ultimately selecting the most optimal
- Explained runtime vs. space trade-offs within the context of different product constraints
3 Points [Leaning Hire]
- Produced a naive algorithm that properly utilized common data structures
- Fully explained or coded a slightly more optimized solution
- Correctly evaluated O-notation for runtime and space
2 Points [Leaning Don’t Hire]
- Selected sub-optimal data structures for the given problem, demonstrating minor misunderstanding about their inner workings
- Produced a naive algorithm and perhaps suggested improvements
1 Point [Strong Don’t Hire]
- Selected poorly suited data structures for the given problem
- Demonstrated lacking knowledge about the inner working of basic data structures
- Struggled to expand past a naive algorithm
3. Problem Solving
4 Points [Strong Hire]
- Rapidly produced a well written and accurate solution with ample time to deep dive into supplementary problems or alternative solutions
3 Points [Leaning Hire]
- Solved the problem and had limited time to briefly discuss additional problems or expand on their original solution
2 Points [Leaning Don’t Hire]
- Barely finished the problem in the allocated time
- Either moved slowly or made several incorrect attempts before arriving at a final solution
1 Point [Strong Don’t Hire]
- Did not finish the entire problem
- Often became lost and were unable to progress without assistance
4. Communication
4 Points [Strong Hire]
- Clearly explained their solution while also demonstrating tangential knowledge by explaining the inner workings of the standard library and data structures they used
- Explained the pros/cons of various common approaches to sub-problems within their solution
3 Points [Leaning Hire]
- Explained their thought processes very clearly
- Failed to elaborate fully on the design and rationale behind algorithmic/coding decisions
2 Points [Leaning Don’t Hire]
- Explained their thought process, but would meander when they became lost in their solution
- Sometimes fell silent while they thought
1 Point [Strong Don’t Hire]
- Spent little to no time explaining their thought processes
- Interviewer had to actively prompt the candidate with questions
5. Thrives in Ambiguity
4 Points [Strong Hire]
- Was able to work independently
- Accurately discussed edge cases early
- Engaged in thoughtful discussion by providing several solutions and challenging common assumptions/answers
3 Points [Leaning Hire]
- Required minor hints
- Asked a few good questions
- Handled unforeseen edge cases once they became clear
2 Points [Leaning Don’t Hire]
- Required several major hints
- Unclear if they could have progressed without assistance
- Did not engage in thoughtful discussion regarding the problem
1 Point [Strong Don’t Hire]
- Struggled to work independently
- Did not attempt unfamiliar problems
- Relied heavily on interviewer for direction
6. Values Feedback
4 Points [Strong Hire]
- Incorporated feedback quickly
- Tried to understand the feedback on a deeper level
- Challenged the feedback where appropriate
3 Points [Leaning Hire]
- Incorporated feedback quickly
- Did not challenge or seek to deeply understand the feedback
2 Points [Leaning Don’t Hire]
- Incorporated feedback, but slowly and didn’t demonstrate satisfactory understanding of the feedback
1 Point [Strong Don’t Hire]
- Blindly ignored or made little use of hints
Final Tips
There is a lot of content in the rubric. I recommend printing out the rubric to refer to when you are doing practice problems.
Try pairing with a mentor or friend. Have them be the interviewer and grade you. Then, switch roles. Be the interviewer and grade them. This will offer better insight into your mistakes and what the interviewer is really looking for.
Thank you for reading! Stay tuned for more guidance on interviewing for software engineering roles.
