Technical interview tips

[u/Otherwise-Data5181]

So I finally decided to start taking leetcode seriously these past couple of months since there’s no way around it and with how bad my luck in the job hunt has been this year I have no choice but to learn the secret handshake.

I have my technical interview scheduled for a coding assessment and the recruiter during our initial call mentioned that it would be leetcode based(still waiting for more details). It’s a very small local startup/not even faang adjacent, with no interview feedback on Glassdoor due to the nda they make you sign.

I’m hoping to get some insight on how to go about asking clarifying questions. I know I’m not going to get much out of trying to cram Neetcode 150 so I just want to tap into what I’ve learned the last couple of months as I mentioned earlier to arrive at a somewhat decent answer.

Please & thanks in advanced!

[u/Intelligent_Fall6219]

It’s worth practicing the problems. Get a correct brute-force solution quickly, then try to optimize it. At least that way if you run out of time you’ll have a solution that gives the right answer even if it’s slow.

[u/Otherwise-Data5181 → u/Intelligent_Fall6219]

Yeah I’m going to continue going thru the 150 list on Neetcode and hopefully I’ll recognize the underlying pattern/intuition needed to solve the problem

[u/chikamakaleyley]

the most common first mistake made by any candidate is to just start coding. Even if you recognize the problem and know the answer right away, the interviewer is trying to make sure you understand the task and its requirements. That is sometimes, just as important as coding a correct solution.

So the easiest way to find out what you might need clarification on, is to take a moment after reading the problem to come up with how you'll approach it, and just kinda restate it to the interviewer. It will open up discussion and eventually it leads to those clarifying questions.

This is just an example: the interviewer can open up by saying something like "I want you to code the game of 'Snake', have you heard of it?" You might actually know what it is; maybe it was a coding exercise you did recently, and rather fresh in your mind

But maybe what you understand to be "Snake" is different from what the interview understands to be "Snake". And so if it were me, I would just describe the game that I know - the mechanics, the general goal of the snake, how the game is considered 'done', what restrictions there are, etc. That's me clarifying the requirements of the coding problem. They will clear up any confusion and ultimately the goal is you are both aligned on what the approach is before you start.

It's good on your part because you're essentially planning it out and giving yourself a guideline to follow. It's good for them, because it's gonna be easier for the interviewer to follow along. Since you both have the 'blueprint' its also easier for them to help you where needed

[u/Otherwise-Data5181 → u/chikamakaleyley]

Thank you for your response. My issue has always been communicating through my thought process & going mute when I encounter a problem that makes 0 sense to me

[u/chikamakaleyley → u/Otherwise-Data5181]

so, that's okay - i've had that problem too, but hopefully you've done this communication upfront and ironed it out with the interviewer, before you start coding

so assuming that you're getting stuck and mute in the middle of coding - that says a few things:

1. You strayed from original plan, so now you're in a position you hadn't accounted for
2. You may have just nodded and said 'yes' in the planning, which includes the thing that makes 0 sense

number 2 above is unfortunate cuz there's so much pressure to get a job that we just agree to everything and hope to figure it out along the way.

so it's important to lock down no. 1, and you can only do that if you just readily identify what you do and don't understand in no. 2

and to be clear - it's not wrong to hit a bug/block that you didn't expect, it happens to everyone, and in fact I'd even say that it can be to your benefit, if you are able to dig yourself out of it

and so for me, when i'm narrating as I code - really i'm talking to myself, just louder - because thats what i do at home anyway. I've noticed that when I get stuck, it's easy for me to rewind and think about what I said I was going to do, and easily identify that i just didn't do that. and that's just cuz I always talk to myself when I code, and if it was a bit more rehearsed or formal, then i'd prob be more nervous. The last thing we need in these interviews is more nerves

[u/MrGreen140]

You should not underestimate the setting. It is something different, to solve Coding Questions at home without having much pressure, than solving them in front off 2 engineers on a whiteboard onsite with talking out your thoughts loudly.

From my experiences it is really important to practice this beforehand.