My eyes were rolling too much to finish this piece, but I’ll share a pair of tips:
In a technical interview, learn to recognize when the interviewer is trying to help you, and take notice immediately when they do. If they say, “Do you really need to use a float here?”, nine times out of ten what they really mean is, “Stop trying to use a float here.”
As an interviewer, it’s really unpleasant to be trying to throw a candidate a life preserver and have them keep shooing it away.
(Sometimes “Do you really need” questions are a trap and the interviewer is testing your confidence, but in those cases it’s usually said with a completely different tone.)
My other tip is for the squishy personality test interview: come into it smiling, and keep that up for no reason. The interviewer will usually start doing it too, and that leads their brain to think, “I’m smiling, so I must like this person.”
My top interview tip, and it's painful that I have to say this but so, so many candidates get it wrong, is "answer the actual question".
It is so frustrating when I word a question very specifically and the candidate doesn't answer it. Most commonly it's a question like "tell me about a time when you encountered a bug in production, how you discovered it and the steps to resolve it". And instead of answering the question, they tell me about what they _would_ do, if they _had_ found a bug. Or worse, they step me through some process that their company uses. I'm looking for personal experience, not what you read on a blog post once.
I also am mindful at the start of all of my interviews to tell the candidate I am not trying to trick them, I'm just trying to learn where they're at. So if I ask you for an experience you haven't had, that's totally fine - no one has done everything, we're just looking for the boundaries.
The problem is that you misunderstand the question you are asking.
When you say "tell me about a time when" you are really saying "Tell me a prepared story about when".
In this case the person didn't have a prepared answer for that question so they went with a generic answer to show to you that they knew what they were doing.
They could have found & fixed hundreds of bugs in production over their career, but trying to recall an example that will make a good story during an interview is hard and risky.
The good news is they will prepare a story for the next interview at a different company.
> Most commonly it's a question like "tell me about a time when you encountered a bug in production, how you discovered it and the steps to resolve it". And instead of answering the question, they tell me about what they _would_ do, if they _had_ found a bug.
Of course they do, it's only natural and smart. They hear your standard formulaic behavioral question and cut to the chase instead of being sheep.
If you want real answers, hold real, natural conversations. Don't read items off a checklist.
The question is just a jumping off point to talk about things like monitoring and alerting, production logging, your release process, testing, etc. It's why I want to start with personal experience.
> Don't read items off a checklist.
I've gone through periods of interviewing 3+ candidates a week for months at a time. It's just not reasonable to expect me to have a unique and interesting conversation with everyone. There are things I need to get into.
That's fine, just be aware that the way you phrase your question is indirect and smells of the typical interview BS. If you'd like to find out how the candidate handles bugs, ask for that directly. Otherwise you're no longer in the realm of a technical question anymore, but in the "can you, on the spot, come up with a plausibly-sounding story that puts you in good light?".
The ability to recall/make up/tell good stories (under pressure!) has nothing to do with engineering.
> Or worse, they step me through some process that their company uses.
Ugh, I've had this so many times and it's the worst. Often those candidates will pull that move multiple times in the same interview, too. Sometimes this is also paired with a level of oversharing that makes me think "wow, I sure wouldn't want a member of _my_ team going off and blabbing this much about _our_ projects when they start looking for their next job".
With algorithmic questions, the life preservers often throw me off more than they help. I had one which was actually wrong, i.e the path I was going down was correct _and_ simpler. More commonly though, if I'm struggling, I'm normally juggling too many things in my head, and them adding another thing to think about makes me drop all the balls.
I still value them in principle, but it seems to be a skill that many interviewers haven't developed to the point where they're a net positive.
I've had an experience where the interviewer tried to stop me from doing a DFS on a graph. Then they tried to tell me that's not how DFS is done. I am a pretty chill and curious guy, so I turned this into a discussion. At the end, I go like 'so my initial approach was correct', he goes like 'yeah, I guess it was' then I never heard from them again. I still think about that interview from time to time.
It can also be the case where the interviewer doesn’t really understand the question and are going from prompts. So when you try to get further understanding of their hint from them, they just repeat the hint. I think this reflects poorly on the company culture, that they’re throwing interviewers out there who aren’t ready.
It definitely can, but I've been asking one of my questions for almost a decade at this point, and I've seen nearly every attempt at a solution that anyone would come up with. Often the difficulty is that the candidate is working towards something that may be a possible solution, but has a myriad of edge cases that they're going to discover and end up needing to spend far too long trying to work out. Meanwhile, there's a much easier solution they could do instead.
I'm not sure of a good way to re-target someone in that situation. I have let a candidate just go down that line before because they were making swift progress on it, and I gave them pretty good marks at the end for an incomplete solution that I was pretty sure they could have worked out eventually, but for other people it's much harder. I totally sympathize with the disruption of an interviewer essentially telling you "not like that" when you're frantically trying to come up with a quick and workable solution, but at the same time, you're probably not going to make yourself look good if you're putting together an increasingly obviously unviable solution by bolting on more and more logic as you find holes.
Every interview is "Demonstrate you meet the hiring criterion, get $XYX/year". It's not as if I reject everyone who doesn't arrive at the perfect solution, but I do need to get some signal that even if they don't get to it that they're thinking about the problem in a productive way. Trying to do a problem one way and then adjusting when you realize it may not be a good way to solve it is a common and important thing that happens to most engineers regularly. Soliciting or synthesizing advice from your peers is a bit part of it as well. Obviously an interview isn't a normal "we're working together on a team" environment, which is why I'm musing about how best to provide advice and guidance without making an already stressful situation worse.
I don't just reject people who give a sub-optimal solution, but going down those unfruitful paths of solving the problem often leads to situations where they stymied and just staring at the problem trying to work out how to work around what have become larger and larger issues with that approach. At that point, I'd either want them to recognize the issue and try another approach, or ask me for advice, or accept my nudge to find another path.
It's a problem I like to give because it's a problem that's easy to demonstrate your baseline skill at and get out a simple working solution, and then we can spend the rest of the time improving and optimizing.
In a technical interview, learn to recognize when the interviewer is trying to help you, and take notice immediately when they do. If they say, “Do you really need to use a float here?”, nine times out of ten what they really mean is, “Stop trying to use a float here.”
As an interviewer, it’s really unpleasant to be trying to throw a candidate a life preserver and have them keep shooing it away.
(Sometimes “Do you really need” questions are a trap and the interviewer is testing your confidence, but in those cases it’s usually said with a completely different tone.)
My other tip is for the squishy personality test interview: come into it smiling, and keep that up for no reason. The interviewer will usually start doing it too, and that leads their brain to think, “I’m smiling, so I must like this person.”