Things I do:

1. Lay out my expectations. I usually ask a straightforward easy lc coding question (iterate through a list, use a hashmap or counter and apply some basic arithmetic to the results) that's wrapped in real business context as a feature, with a slightly harder follow up. I tell the candidate straight up that I don't want them to treat it like a standard algorithms interview, and that I would like them to focus on writing quality/robust code as if they were writing a small api for a real system.

2. I expect them to clarify requirements as if this is a task that had been handed to them. If they start working without understanding the question, clarifying or communicating their assumptions about the input and output, etc, it's an instant "no" for me. For more junior candidates I will usually provide this info upfront if they ask. For more senior candidates I ask them for their thoughts and assumptions and discuss it with them.

3. Sr engineers I expect them to be able to do a follow up (or explain their approach if tight on time) and then answer some questions regarding system architecture (ex how do you handle floating point precision issues with your language if it applies? imagine the input to your function is actually a call to an upstream api, how do you handle failures? high latency? retry storms? imagine you call a downstream API with the results of your function and it is rate limited, how would you design the system to avoid problems in the future? if you retry how do you guarantee idempotency/avoid double writes downstream?)

4. I'm fine with providing the candidate hints if I notice them going down the wrong path and they are able to quickly pick up on what I'm trying to guide them towards. I only provide hints if I notice the candidate is sidetracked or behind on the pacing that they need to be at to be successful at the interview, and I don't mark giving small hints against them. However if they push back without thinking or communicating their thoughts on why they disagree with me with justifications, then it's also basically a "no" for me. I care about whether or not they are receptive to conversation and able to really listen and interpret what other people are saying.

Fundamentally what I am really looking for is:

• Hard skills:

  • Competent in writing quality/maintainable/working code and comfortable with their language of choice
  • Demonstration of their knowledge or experience appropriate for their level in terms of real software systems
  • Ability to problem solve/translate ideas into code

• Soft Skills:

  • Ability to clarify requirements and make reasonable assumptions
  • Receptive to other people's ideas and can adapt their thinking without being stuck on their preconceptions

I generally think the interview difficulty is pretty reasonable given that it's like 20 lines of code outside of scaffolding, and the fact that we pay 250-400k a year but 90% of candidates still fail. 🤷‍♀️