harisrid Tech News

I’ve always wondered what it really looks like from the other side too 🙂

An Introduction

I’ve conducted mock algorithmic interviews on interviewing.io¹, and I thought it’d be cool to share a quick example of what good interviewing feedback looks like.

Personally, it takes me 5-10 minutes to write up feedback, because I want to be as thorough and as comprehensive as possible and ensure that I capture the right level of detail so that external reviewers – an interviewing panel, a hiring manager, or a bar raiser – can review them offline

I’m sharing example feedback of a case study where my interviewee² performed exceptionally. I think it’d be useful for both interviewees and interviewers – interviewees to understand what interviewers write up at the end, and interviewers to learn what they should write up.

Why solid Feedback Matters

• Onus – It’s the the onus of solid interviewers to set their candidates up for success. Good interviewers must build the best case and gather the most signals to support their candidates and evaluate them holistically – regardless of a candidate’s performance.
• Audience – External evaluators who didn’t conduct the interview read feedback and make decisions.
• Criticality – The feedback I write can really make for the decision of hire/no hire.
• Lack of Formal Training – there’s a strong dearth, or lack of, formal training for technical interviewing.

Alrighty then, let’s begin 🙂 !

Strengths

• TC is a fast coder.
• TC is a concise coder.
• TC demonstrated how to capture, store, and evolve computational state.
• TC has fast typing and problem-visualizing skills – I easily followed their visual examples of a grid/array/tree/<insert_other_data_structure>.
• TC’s code is – or almost meets – a mostly working state. A few minutes of tweaking and adjustments were needed to get it to pass all test cases on Leetcode ( or other equivalent websites ).
• TC needed hints or nudges here-and-there, but with the accompaniments, they worked their way towards an effective solution.
• TC demonstrates technical persistency ; they persist through a problem’s difficulty and they don’t give up.
• TC’s Big-O Time-Space Complexity reasoning was correct and met optimal solution.
• TC shows solid understandings of a rule’s engine, for loops, indexing and 1-off adjustments, pointers, and conditional expressions.
• TC solved ( most or all ) the problem within a reasonable time limit.
• TC finished ahead of time – I asked open-ended extension questions demonstrating high-level skills, such as extending a logging posture and asking how they’d refactor code in a production setting. Kudos points 🙂 !

Areas of Refinement

I also like the term “areas for refinement” over “weaknesses”; I think it communicates more empathetically.

• TC can focus more on edge case scenario thinking and can walk through their code/rules engines through different scenarios.
• TC can focus on leveraging a TDD approach, and mention the scenarios they want to think of ahead of time before immediately diving into code.
• TC can think more about case decomposition.
• TC can think about leveraging nested expressions/nested conditionals to evolve a rules engine.
• TC can consider modularizing code ahead of time.

Leveling Determinations

• Junior/Entry-Level or Mid-Level/2-3 YOE : Strong Hire.
• Senior-Level/Staff+ Leveling with 5 YOE or more : Hire.

1. Credit is due to to interviewing.io for their template structure/headings here. ↩︎
2. Credit to my mock interviewee for taking the time from her day – 1 hour and 10 minutes – to go through rigorous practice. I believe in journalistic integrity, and I’ve redacted all names and other Personally Identifiable Information. ↩︎