When I was interviewing people, I wished they hadn’t been prepared.
I took my advice a few weeks ago and went for an interview unprepared.
In this post, I’ll tell you how interviewing people helped me get the feedback I wanted during my interview.
Interviewception 🧙
Why It Matters?
In 2020, we jumped on the massive tech-hiring wave.
I conducted tech interviews in 60-minute blocks.
With little experience in the subject, I did what I knew about interviewing: DSA problems and whiteboard interviews. But I quickly realized:
60 minutes of DSA is not enough to decide if you can work with someone
Candidates see such interviews as tests that can be passed or failed while I look for the person I will work with.
The only question in my mind remained almost always unanswered:
Who am I going to work with?
And preppers made things worse.
They knew everything.
Write a Two sums algorithm? Coming up, boss!
Knapsack problem? No worries, here you have it. Do you want the greedy optimization form or the Quantum approximate optimization? 🤓
But let’s not fool ourselves.
We’re web developers.
The chances that you’ll implement graph-traversing algorithms daily are close to 0.
Solutions kept coming my way, and I couldn’t help my self but repeat the same question inside:
Who am I going to work with?
Interviews are like a weird talent show where the performer prepares a highlight reel, but the judges secretly hope to see you trip to reveal your true self.
This is when I changed my approach and also decided if I were ever interviewed, I wouldn’t prepare.
Deep Dive
How I fixed my tech interviews
After a few months, I ultimately gave up on DSA problems and started making up assignments. Ones that didn’t have definite answers:
code a login form with a specific validation logic
create a deliberate race condition with form submit
These weren’t tricky problems, but I saw a little struggle, thinking, umms, and ahhs every time.
And it worked!
I improved in assessing people I’d love to work with because I saw them struggle, think, and find a way out of the problem.
How I did on a recent tech interview
Last week, I was interviewed by a company. I didn’t prepare anything except my positive mood and being hyped up to talk to new people.
Of course, I got a Leetcode problem. 😅
But I wasn’t worried—I knew exactly what to do. It’s what I always expected from candidates when I interviewed them: think out loud (and not to prepare, but I get that out of the way already).
So I did exactly that.
“I can brute force this!”
My reaction to the first problem caught them off guard.
I felt a temporary disappointment, but I knew if I could write a brute-force solution to warm up, I’d be able to write something better. So, I continue thinking out loud.
Recording videos helps with this immensely! If you’re into React, TypeScript, Web, and occasional Desktop App development, check out my YouTube channel! Making videos helps me learn to simultaneously type, talk, and explain concepts.
“Okay, but can we do any better?” - asked the interviewer.
I said, sure, let’s think about it. Again, I was thinking out loud, and while thinking, I made some pseudo-code that I turned into an actual algorithm and told that this is better, O(n), but there might be even faster ways to do this that I don’t know about.
“This is as fast as it gets.” - With this, we wrapped up the DSA part, did some system design questions, and said goodbye.
A few days later, the results were in: I passed the interview, and they mentioned two things they liked:
I didn’t bring answers
I revealed my thought process
I know. Shocking, right?
Most of you could beat me at pulling DSA solutions where I’d struggle.
But I have one thing that keeps me serving well:
Taking a stab at the unknown and dealing with it with what I have.
It’s a pretty liberating and worry-free experience. I suggest you try it!
How crazy is this idea?
📰 Weekly shoutout
5 API Performance Strategies and some notes on Devin - such a hot topic recently!
shares his thoughts on Devin and what he does best: performant API design!- - Our evolution as software engineers stops when we stop learning. Be open to new ways of learning because they keep evolving. I ignored YouTube and favored articles for a long time, but educators and platforms also evolved!
Lessons Learnt: “How to Win Friends and Influence People” –
shares his learning from the book “How to win Friends and Influence People”, something I’ve been looking to read for some time. This is a short, on-point summary. Make sure you read it NOW so you can get back to reading Dune! 😃
📣 Share
There’s no easier way to help this newsletter grow than by sharing it with the world. If you liked it, found something helpful, or you know someone who knows someone to whom this could be helpful, share it:
🏆 Subscribe
Actually, there’s one easier thing you can do to grow and help grow: subscribe to this newsletter. I’ll keep putting in the work and distilling what I learn/learned as a software engineer/consultant. Simply sign up here:
This is excellent advice Akos!
I wish more interviewers followed this approach for judging candidates. In fact, some of the best teams I worked in had similar interview processes, probably because when I was selected it turned out to be a far better match because of the process.
Also, while interviewing, I've found the best candidates for the team not asking pre-decided DSA questions but deeper discussions on actual problem-solving that reveal the person's thought process.
Loved the advice Ákos :)
For me as an interviewer - it also makes the candidate more ‘human’. I think that subconsciously, when you see someone think and struggle their way, even if the answer is only at 80%, we’ll prefer that candidate to the ‘perfect’ and rehearsed one.