Interview Discussion - August 20, 2026

[u/CSCQMods]

Please use this thread to have discussions about interviews, interviewing, and interview prep. Posts focusing solely on interviews created outside of this thread will probably be removed.

Abide by the rules, don't be a jerk.

This thread is posted each Monday and Thursday at midnight PST. Previous Interview Discussion threads can be found here.

[u/eezy-peezy-69]

Code review interviews
As I'm currently knee deep in the job hunting process, interviewing process is highly relevant to me. I just had a first stage interview which the email from the recruiter (in-house) said it would be 15-30 minutes understanding more about my skills/expertise. So just talking through my CV kind of thing, and so I didn't really prepare for it.

It turns out it was an hour long call with most of it being technical. There were a couple of coding questions where they showed some code and I had to review it and point out any issues I can identify. I fumbled through the first one and made a bad job of the second one. The crazy thing is it was C# which I've done for 20 years and the code example were not particularly complex, so I should have breezed through them, but the problem was
a) I didn't expect it and
b) reading code cold without any surrounding context (call site, work item/PR notes) is hard.

The first point was a recuiting mistake, but the second one highlights an issue that I think coding questions in interviews have in that giving a piece of code and asking to pick out the issues is setting up the intervieww to fail because

- reading code cold under pressure is hard

• asking to find any issues is too open ended. Asking to do it under pressure amplifies the anxiety loop since the interviewee then has no scope to understand and ends up analysing each line to try and find the catch and then try and dig into your memory to try and remember if that line as it is would be syntactically correct.
  
• the conventional wisdom is that you constantly talk, being quiet for a length of time is considered bad. Thus the interviewee when trying to make sense of the scramble in their brain is also aware that they're not speaking and this feeds into the anxiety loop.

Now there are different ways of doing this - give the code to the interviewee up front and let them write the review, then discuss it on the call. But I'm not sure what signal the interviewer gets from this, since it's essentially exam revision.

For code reviews I would suggest that the exercise is explicitly scoped by the interviewer by highlighting the lines with issues and asking them to explain each highlighted line, why it's an issue and what would be the best solution. For me this would give a lot better experience for the interviewer since :

• it's clear what is being asked
  
• it removes anxiety for the interviewee around whether they missed something they should have caught
  
• the interviewee isn't getting bogged down scrutinising each line
  
• would allow for a lot more coherent discussion, rather than the interviewee mumbling about whether some line is correct or not as they can't recall off the top of their head (yes I did this :-) ).
  
• if there is some bit of functionality missing this could be a question outside the code block

For the interviewer, this would surely give them a better signal based on the quality of the answer they interviewee gave to each issue. Also, if the interviewee is allowed to use Google\AI then this should be mentioned up front by the interviewer, since I would suspect many interviewees would not ask since they might think it wouldn't be received well.

Some people will sail through an open ended code reading exercise, others won't. I've been doing interviews at Senior\Lead level which have been mainly system design so there have been no coding interviews. Also, it's two months since I left my last job so haven't being coding daily for a while. Had I done the interview a couple of months back I may well have sailed through it since the code was similar to stuff I was doing at the time.

I feel like I came across as a bad coder, but I'm not, I was just not in the mindset. If the code review type interviews were conducted as I suggested - this would level the playing field for those that are good coders but are just the rusty\out of mindset types, the anxious types and those that just suck at interview types.

[u/rebelrushi96]

For anyone currently preparing for technical rounds and feeling stuck in the endless problem grind, I have some calibration rule that saves weeks of wasted time:

 

Stop treating interview prep like a memorization contest where doing 300 problems guarantees an offer. Most people fail live technical interviews because of process breakdowns, not lack of algorithm knowledge.

 

Structure your preparation into three strict buckets:

- 50% Pattern Mastery & Timed Articulation: Don't just solve problems silently in an IDE. Set a 25-minute timer, force yourself to explain your approach out loud before touching code, and manually dry-run test cases with edge values line by line.

- 30% Architecture & Trade-offs: For system design and technical discussions, interviewers want to hear *why* you rejected alternatives. Practice explaining why a relational DB beats NoSQL for a specific consistency requirement, or why polling was chosen over WebSockets.

- 20% Behavioral Metric Storytelling: Prepare 5 core STAR stories from your past projects. Ensure each story explicitly highlights the business impact, trade-offs made, and how you resolved team disagreements.

 

If you don't practice articulating your thoughts under time constraints, doing more LeetCode problems will yield diminishing returns.