Related Posts
Anyone else barely make it through Q1? 😅
How important is QBI for REG?
I have over 20,000 unread emails in my inbox.
Additional Posts in Tech
Any advice on moving from L4 to L5 in Amazon?
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.




I think it is a common problem to not perform in an interview as well as you know you can. You might consider paying for mock interviews from somewhere like interviewing.io or asking friends if you want to practice mock interviews on each other. Good luck!
First, I suggest doing as many interview exercises as you can stand in preparation. When you're asked to complete an exercise in an interview, don't think of it as someone challenging your competence. Instead, imagine it's a colleague reaching out for help.
Show then your approach to gathering requirements.
"Okay, who's my PM? BA? What're the acceptance criteria? Is there a user story for this, or a business case? Who's the client and why do they want this algorithm? Who's consuming this code? What about subject matter experts - is anyone available for consultation and code review?"
Obviously they're not going to hold your hand all day long asking you for individual algorithms. So flip the script. Get them roleplaying like you're already a member of the team.
Is it so important to give them what they start out wanting if you give them what they really want?
I've done mock interviews with friends but someone like a former co-worker would be a good choice. They can give you immediate feedback which I found helpful.
It's hard in the hot-seat, when someone is looking over your shoulder. Even with near decades experience, it can be a lot. The only thing I can recommend is do it and do it again until it feels routine and you are comfortable. Don't forget to breath, Don't be afraid to be natural. Interview for positions you know you don't want or that you wouldn't even expect to be qualified for to experience this stress-free and get practice or to try different things.
In some cases, as long as you can talk through your thoughts, not only will the interviewer be able to see your critical thinking processes, but they will understand that you understand what the goal is, whether or not you achieve it.
I get that coding tests are a part of it, but a majority of what you're selling there is your personality and that decision is made within seconds. Chances are, by the time you get to a test (unless the result is disastrously bad) they've already have their answer.
Rising Star
I've struggled when I'm asked to solve an algorithm without looking at any code. Not even a whiteboard. Got to mentally waste bandwidth just visualizing the code. I don't get it, but I think some of it is that hiring managers aren't as knowledgable as you think. Over the course the interview, I think a lot of what I said went past the guy. I actually knew more than they knew, but there are only looking for one specific answer they know the answer to. Very weird situation to be in. I had a lot of smart answers, but I struggled on explaining the algorithm (not as quickly as I would have liked). I gave one solution immediately, but I opened panadox's box optimizing it.
What you're trying to do here is use your knowledge to figure out the problem. That's not what these stupid shittests are intended to show.
If you want to get better at these kind of tests, forget coding, because that's not the problem you're solving. What these leetcode shittests are intended to test is your ability to think mathematically.
In practice, if you can:
- define the problem's domain
- define how the variables transform;
- define a short series of operations to transform them;
Then every single question they ask following that point is trivial.
You may miss some of the obscure language paraphernalia (for example you might miss out on stuff like list comprehensions in Python) but you will usually solve the simple problem and describe what it is doing.
More complex stuff that that might require some domain knowledge.
If you're a maths guy, it helps to abstract yourself from the interview entirely.
Write the problem down, stop looking at anyone other than the problem. Then take the words of the problem apart, simplify it right the way down until you have a core mathematical statement that underpins the problem.
If you can get a domain of operation (all non-negative integers, all integers, some integers, some integers in a range) and define the problem in that way as a series of mathematical operations, the solution will usually fall out of your head automatically.
Ignore the answers you're supposed to have. There's always someone who has a better way of writing it than you on leetcode or whatever.
The reason you're freezing up is because the description of the problem is usually rubbish. Leetcode and Hackerrank etc usually have big sets of graphics designed to help you practice. They rarely just have a sentence description.
In most cases, a 100% working block of code isn't what the interviewers are looking for. They are looking to see how you perform under pressure and to judge if you can think broadly about the problem, solve the logic and math behind it and describe your thought process behind the decision. Yes, they will ask direct questions about algorithms or esoteric language objects or functions or whatever. To offset this, you could always just start with, "Oooh, ok, let's role play a little!" Then if you get stuck, you can tell the interviewer, "In a real situation, when I need a hint or a quicker path to best practices that you'd use here at xyz company, I'd ask a senior for their opiniong. As a senior dev lead, these are the questions I'd ask..." and then ask the questions, turn the problem around and put the ball in THEIR court. If they make you uncomfortable, make them equally so :) If they can't answer their own question you've won and you can always follow up with "In cases like this, we can discuss in front of a white board with relevant expertise and figure it out so we're all on the same page."
As a hiring manager, I would much rather have someone who is good at collaborating and problem solving than someone who pretends to know the answer to everything.
There are questions that will need to be answered and I need to trust the candidate, knowing that they will be able to solve it by themselves or with the help of others. I don't want a cocky know it all.
Let me guess - You're one of those analytical types where this sort of work comes naturally. You solve the problems without putting them into words. Like riding a bike - You can just do it, If so, I can relate. I found I can close that gap by doing some courses (sometime a number of them if I've been in the weeds too long). I usually look for something similar to what I already know just to have the awareness of another tech stack, but I'm mainly trying to restore the narrative. Being able to do something and being able to speak about it are related, but different skills. Changing the medium from hands-on to interview questions is like explaining how to tie a shoe. It's easy to tie a shoe, but explaining it over the phone is another story, The courses put that skill back into words. They also remind you what is and isn't implied knowledge, which is easy to get tripped up on in an interview. ..and if nothing else, having done relatable courses shows continuing growth and awareness of more than your hands on experience. People like to see that in a potential new hire. Hope this helps!
I had this happen to me and notably during my Google interview about 18 years ago. My brain sort of locked access, and I tried to keep calm. In that instance, all of a sudden the block was gone and I answered a bunch of queue up answers in my mind. Thankfully the interview was successful and I spent 7 years at Google. So, what can you do? Practice technical interviews, including for positions that are not at the top of your list. Here the practice is the social situation since it sounds like you already have decent technical preparation. Chances are you will become more at ease with this practice, and maybe you'll get a job you weren't looking for, but turns out to be a good move. Thankfully, a great many interviews are remote these days, so gone are the days of having to fly to other states just to interview (something I've done in the past). I would normally end with "Good luck!", but you don't need it, just practice and it will happen.
Happens to me too.. the irony is that those tests are not actually what they are hiring you for.
What's actually valuable is that you know how to figure out how to solve a problem, and that you can improve on it later.
INterviewers forget that we are *not* computer scientists studying efficient sorting algorithms. We are application builders, we get product built, and then improve them and keep them running. If we are spending all our time studying solved problems, we are wasting time.
This is to important in product development that we have a term for it. NIH (Not Invented Here).
So yeah, I agree, It's disheartening to know you are excellent for a position, that it's what you do and it's even got you motivated and interested, only to be presented with a nonsense test.
Unfortunately, some people believe that is what they need to do.
All we can do is when we get to positions where were we are hiring others, is to develop ways to interview that are more real for what we are hiring for.
The best people I have hired were not the ones that were great at passing a random purposely difficult comp-sci problem. They were problem solvers and makers, and learners, who loved their jobs.
Based on my experience, especially on initial intervie where the manager begins a conversation style where they want to know you, your background and why are you on a hunt on a role.
I work in tech but the hiring managers are looking more on SOFT SKILLS than the smartest, most technical engineers. Of course your years of experience count too but what you can bring to the new team, minus the drama and can collaborate well with others at work.
Practice relaxation, and learn to relax, It will all come to you!
Instead of having factual answers, prepare stories to narrate.
Think of interview as having a healthy conversations, have genuine interest in the interviewer and connect,
When I've conducted interviews, I usually throw in a difficult question. The point isn't the answer. What I'm looking for is someone who doesn't stop trying to solve the problem. As long as they continue trying, I help them out. If they give up easily, so do I generally on their candidacy. So don't be afraid to ask questions. Engage with the interviewer. Show what you and your thought process behind solving the problem. If you're a good programmer it will show, even if the solution isn't obvious. My two cents.
That happens a lot, is very common scenario! First, I would say: don't allow your brain to convert that to some sort of impostor syndrome.
Here some tips that I myself found helpful for my path:
1. Start the conversation in a friendly manner
Not all interviewers are super friendly so please tweak this sampling the vibe on your call; this is just a 30-50 seconds thing; remember that interviews are a 52% "do I like this person?" and 48% "did this person solve the problem?", here an example I did myself.
Me: I was able to review your linkedin, I have some questions I would like to ask you by the end but for now, is the japodogs a trend still in Seattle? I used to live there and seemed like seaweed on everything
Them: Ha! I heard of them but never tried
Me: I wish I could say you are losing something but, already on my second coffee and a matcha my brain is unable to process false positives
Them: Hahaha, okay, let's start with the conversation. Are you ready? Do you want to grab some water?
2. Practice the "tell me about yourself" question
This should not take more than 90 seconds; you cannot imagine how many good engineers we got a wrong impression and, used a lot of time clarifying things because this.
Focus on
— Tell them where you work, what is your role in that project; the skills you use
— Connect what you just said to the before-that employer, "before of that I was working for...", but only use one or two sentences explaining what you did and the technology
— End the note with "Let me know if you would like me to go back on time to a specific thing is not clear from my resume, happy to do so"
3. Every day do something random that makes you a better communicator
This may sound strange but heard me out; the main reason we feel anxious/nervous during interviews is our fear of rejection. Once you no longer fear the rejection, you just "vibe". Things like saying "good morning" walking at the street to a person, etc
One mentor I really respect told me once almost two decades ago: "Interviewing is like doing blood work; you can do it thousand of times but will always be afraid of one or the other if you never work your relationship with the real reason why you are scared of them". Find the real reason for you, mine was: unfamiliarity with rejection; once you see rejection as a possible "outcome", you don't really see it as bad but as a learning :)
I pressed enter earlier
why all these? one of the biggest reason we freak out during interviews is because we are nervous/anxious and get brain fog. Create a confident-peace environment and you will feel like you are talking with a coworker or a friend you just made after talking with them for a minute.
Interviewers want you to succeed, most of them. They are on your side
A cup of coffee and a piece of black chocolate 10 minutes before the interview - the trick I discovered after ~10 years of terrible failures.
Caffeine wakens, sugar stimulates brain cells.
just cool and think about it normally