I’ve been working as a full-stack developer at a startup for the past 3+ years. Recently, I decided to switch companies to explore new challenges and learning opportunities.
Over the last few weeks, I attended 10+ interviews and ended up with 3 offers. More importantly, I learned a lot about communication, pressure, and the difference between knowing something and explaining it clearly.
I also recorded most of my online interviews to track my mistakes and improve over time. I used a simple Python script to record the audio.
Some rounds went well. Some didn’t. But by the end of it, I understood myself better than I had in years of working as an engineer.
Here are the biggest lessons I learned.
Your writing already has strong reflection and honesty. I shortened it by removing repetition, tightening some sentences, and smoothing grammar while keeping the same conversational tone and storytelling style.
The first round, and realizing communication is a skill
The first round felt easy. Intro questions, project discussion, small system design.
I walked in confident. I had built production voice agents, worked on infrastructure migrations, and knew my work deeply.
The interviewer asked me to explain one of my projects.
I started talking about Twilio, WebSockets, streaming audio, EHR integrations, Athena, ECW, strategy patterns everything.
A few minutes in, I noticed his face.
He wasn’t following.
So I sped up.
That made it worse.
By the end, I had explained a lot, but very little had actually landed. He asked me to repeat things I thought I’d already explained clearly.
That was my first lesson:
Interviews are not just testing what you know. They test whether you can transfer what you know into someone else’s head clearly and quickly.
If communication fails, your knowledge becomes invisible.
The Twitter feed question, and the importance of clarification
One interviewer asked me to design a Twitter feed.
A million users. Each follows around a thousand people. Design the schema and read query.
I immediately started solving it.
Tables. Indexes. Joins. Redis caching.
Then he asked:
“What happens when the table grows to hundreds of millions of rows?”
I kept defending caching.
He kept hinting that I should rethink the data model itself.
I didn’t get the round.
Later I realized the real mistake happened in the first 30 seconds: I never clarified the problem.
I should have asked:
- What’s the read-to-write ratio?
- How fresh does the feed need to be?
- Are users mostly reading their own feed?
- Fan-out on write or fan-out on read?
Instead, I solved the wrong problem confidently.
Senior engineers don’t rush to solutions. They rush to clarity first.
Speaking faster doesn’t make you sound smarter
I discovered something uncomfortable while listening to my recordings:
Whenever I got nervous, I started speaking faster.
I thought I sounded efficient.
In reality, my explanations became harder to follow. My words blended together, my accent became stronger, and I skipped important transitions between ideas.
In one interview, I explained interruption handling in our voice agent system — VAD packets, WebSocket interrupts, stopping TTS streams mid-response.
I knew the system deeply.
But I explained it too quickly.
The interviewer asked me to repeat key parts because he couldn’t follow them.
That taught me something important:
Speaking fast is often a confidence costume. Real confidence sounds calm and slow.
The smartest engineers I’ve met rarely rush their words.
The notification system, and missing the hint
In another round, I was asked to design a notification system with email, push, and in-app delivery.
I designed queues, consumers, retries, and channel separation.
Then the interviewer asked:
“What happens if both the queue and the consumer fail together?”
I kept patching my design:
Kafka. Persistence. Backup tables.
He kept nudging me toward thinking about reconciliation and delivery guarantees.
I ignored the signal and kept defending my original approach.
That round taught me something subtle:
When interviewers repeat a question differently or say “think about that,” they are redirecting you.
That is the moment to stop, reset, and rethink — not defend harder.
A much better response would have been:
“Let me step back for a second. Are you pointing me away from this approach?”
That shows adaptability, which matters a lot in senior interviews.
Behavioral questions are slower than technical ones
One interviewer asked:
“Tell me about a time you disagreed with a teammate.”
I answered immediately.
Halfway through the story, I realized I picked the wrong example. They were evaluating leadership and collaboration, but my story focused only on technical disagreement.
I should have paused before answering.
Just 3–5 seconds to think:
“What is this question actually testing?”
That small pause matters more than people think.
Fast answers in behavioral rounds often sound less thoughtful, not more confident.
Preparing stories beforehand also helps a lot.
Filler words and fear of silence
Watching my recordings was painful for another reason.
I noticed how often I said:
“Yeah yeah…”
“Actually…”
“Okay so…”
“I think…”
Those filler words were not helping me think. They were just filling silence because I was uncomfortable pausing.
Eventually I realized:
Silence sounds more confident than filler words.
Now, when I need time, I simply say:
“Let me think about that for a second.”
And then I actually pause.
It feels strange at first, but it sounds much more professional.
The summary I never gave
After long explanations, I often ended with:
“…and yeah, that’s basically it.”
No summary. No closure.
The interviewer had to figure out which parts actually mattered.
A much stronger ending sounds like this:
“So the main reason we picked Gemini was the larger context window, we validated tool calls at the application layer, and the remaining bottleneck was post-call evaluation latency.”
That one sentence creates clarity.
It shows prioritization, structure, and confidence.
Now I actively practice summarizing long explanations into one clean closing sentence.
My resume became a question bank
One interviewer asked me about pgvector.
I had mentioned it on my resume because I used it briefly during a hackathon.
Then came deep questions about chunking, embeddings, retrieval quality, and indexing.
Every line on your resume is an invitation for deeper questioning.
If you can’t comfortably discuss something for 10 minutes, it probably shouldn’t be there.
A weak answer about your own resume creates more doubt than leaving the skill out entirely.
What I’m changing now
By the end of all these interviews, I had a clear list of habits I want to improve:
- Practice explaining my projects out loud
- Record myself and listen carefully
- Slow down while speaking
- Ask clarifying questions before solving
- Treat hints as redirects, not resistance
- Pause before behavioral answers
- Get comfortable with silence
- Revisit fundamentals regularly
- End long answers with a short summary
Most importantly:
When I feel nervous, I now try to slow down instead of speeding up.
The real takeaway
Interviews are not purely a test of knowledge.
They are a test of whether another engineer can trust that you will communicate clearly, think calmly, and work through problems effectively under pressure.
Technical knowledge matters.
But the ability to make other people understand your thinking matters just as much.
The good part is that communication is also a skill.
Which means it can be practiced.
And for the first time, I feel like I know exactly what I need to improve and that’s a much better place to start from than blaming nerves, language, or bad luck.
Onwards to the next round.
Top comments (0)