Interview Experience After 3 Years in a Company: Key Learnings

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.

SmartCap : Agentic IPL Captain

Cricket isn’t just played on the field; it’s won in the mind.

The pressure of a live T20 match is immense. Do you bowl your premier fast bowler now or save him for the death? Do you send in a pinch-hitter because the pitch is slowing down? To answer these questions, we built Captain Cool—an agentic AI system powered by Google Gemini that simulates the internal dressing-room debate of an IPL franchise.

In this post, we’ll dive into the architecture, the prompts, and a live match walkthrough of how we used Gemini’s multi-agent capabilities and function calling to build a virtual IPL tactician.

🏗️ The Architecture

At the heart of Captain Cool is a Multi-Agent Debate Loop orchestrated via FastAPI and the google-genai Python SDK. Instead of relying on a single prompt to do all the heavy lifting, we split the reasoning across four distinct personas.

Here is the architectural flow of how a decision is made:

sequenceDiagram
    participant User as React UI
    participant API as FastAPI Backend
    participant Stats as Stats Analyst (Agent)
    participant Tool as CSV Tool Call
    participant Captain as Strategist (Agent)
    participant DA as Devil's Advocate (Agent)
    participant Comm as Match Commentator (Agent)

    User->>API: Send Match State (Score, Pitch, Dew, Players)
    API->>Stats: Forward context
    Stats->>Tool: get_batsman_stats() & get_bowler_stats()
    Tool-->>Stats: Returns Real CSV Data
    Stats-->>Captain: Match Context + Statistical Report
    Captain->>DA: Proposes Initial Strategy
    DA-->>Captain: Critiques the Strategy (Risks!)
    Captain-->>Comm: Defends/Revises Strategy
    Comm-->>User: Returns Final Output & Debate Transcript

The Tech Stack

  • Google Gemini API: Powered entirely by gemini-2.5-flash for blazing-fast multi-turn reasoning.
  • Backend: Python, FastAPI, and Pandas (for data manipulation).
  • Frontend: React + Vite with a custom Glassmorphism UI.

🧠 The Agents & Their Prompts

The magic happens by giving each agent a very specific role and instruction. Here are the exact system prompts we used for our four agents:

1. The Stats Analyst (The Tool Caller)

This agent is equipped with Gemini Function Calling. It has access to Python functions that read historical data from batting.csv and bowling.csv.

“You are the Stats Analyst for a T20 cricket team. Your job is to gather data using your tools and provide a detailed statistical breakdown of the players involved in the current match state. You must use the get_batsman_stats and get_bowler_stats tools to pull real data. Do not make up stats. Provide a clear summary of the key players’ strengths and weaknesses based on the numbers.”

2. The Strategist (Captain Cool)

“You are the Head Coach / Strategist (“Captain Cool”) of a T20 cricket team. You receive the current match state and a statistical report from the Stats Analyst. Your job is to make a definitive tactical decision for the next phase of the game (e.g., who should bowl the next over, or who should walk in to bat next). You must analyze the pitch conditions, required run rate, remaining overs, and player stats. Provide a clear, bold decision and the reasoning behind it using professional cricket terminology.”

3. The Devil’s Advocate

The most crucial part of our architecture. It ensures the Strategist isn’t suffering from confirmation bias.

“You are the Devil’s Advocate / Assistant Coach. Your job is to aggressively but respectfully critique the Strategist’s proposed decision. Look for flaws in their logic. What if the pitch spins more than expected? What if the chosen bowler has a bad matchup against the current batsman? Point out the biggest risk in their plan and propose an alternative strategy. Use cricket terminology.”

4. The Match Commentator

Translates the dressing room jargon into pure hype for the fans.

“You are a seasoned Cricket Match Commentator (like Harsha Bhogle or Ravi Shastri). You have just listened in on the team management’s internal debate (Strategist vs Devil’s Advocate). Your job is to summarize the final decision and the debate for the fans. Explain the tactical nuance in an exciting, dramatic, and easy-to-understand way. Format your output cleanly. You MUST include a final ‘Agent Conclusion’ at the end.”

🏏 Walkthrough: A Live Match Scenario

Let’s look at how the system handles a tense situation.

The Context:

  • Match: CSK vs MI
  • Score: CSK 178/4. Target: 177. (Wait, CSK is chasing! They need 3 runs in 10 balls).
  • On Strike: MS Dhoni
  • Bowler: Jasprit Bumrah
  • Conditions: Turning track, Heavy Dew Expected.

We hit “Generate Multi-Agent Strategy” on our React frontend.

Step 1: Tool Execution

The Stats Analyst automatically executes get_batsman_stats("MS Dhoni") and get_bowler_stats("Jasprit Bumrah"). It notes that Bumrah has an elite economy rate of 7.39, while Dhoni has a career strike rate of 135.

Step 2: The Debate Loop (Live Transcript)

🗣️ Strategist:

“Bumrah is MI’s best asset, but the dew is heavy. The ball will be like soap. Given we only need 3 runs off 10 balls, the instruction to MS Dhoni is to play out Bumrah’s deadly yorkers without taking risks. We don’t need a hero shot. Just rotate the strike or wait for the next bowler.”

😈 Devil’s Advocate:

“I have to push back here, Captain. ‘Playing it safe’ against Bumrah in the death is a myth. If Bumrah bowls a wicket-maiden here, the pressure skyrockets for the final over against a spinner on a turning track. Dhoni’s strength is his power down the ground. If Bumrah misses his length by an inch because of the wet ball, Dhoni must go for the kill immediately to finish the game.”

🗣️ Strategist (Revision):

“Fair point on the pressure build-up. I revise the plan: Dhoni should look to finish it here and now. The wet ball means Bumrah is likely to miss his yorker length and serve up a low full toss. Dhoni is instructed to stand deep in the crease and back his raw power to clear the straight boundary.”

Step 3: The Final Commentary

🎙️ Match Commentator:

“What a climax we are building up to here at the Wankhede! The dressing room was split—do you respect the genius of Jasprit Bumrah or do you back the brute force of MS Dhoni? The Devil’s Advocate made a brilliant point: you do not want to leave runs for the final over on a turning track, even with dew. Captain Cool has made the call: Dhoni is going to stand deep in his crease, wait for that wet ball to slip out of Bumrah’s hand, and look to finish this into the stands! Grab your popcorn!”

🎯 Agent Conclusion: Dhoni instructed to attack Bumrah immediately, exploiting the wet ball to finish the chase, avoiding a final-over spin trap.

Conclusion

By forcing LLMs to debate each other, we eliminated generic “chat” responses and generated highly specific, analytically sound cricket strategies. Google Gemini’s lightning-fast inference and native tool-calling capabilities made orchestrating this complex loop incredibly smooth.

You don’t need to be a cricket captain to make the right call anymore—you just need a team of Gemini agents in your corner. 🏆

Captain Cool: A Multi-Agent AI That Thinks Like an IPL Captain

Captain Cool: A Multi-Agent AI That Thinks Like an IPL Captain

What happens when you give six AI agents a live cricket match and ask them to argue about it?

Cricket is decided in moments. A bowling change at the wrong over, a misjudged pitch, a batsman promoted too early — the margins are razor thin and the decisions are made in seconds. Yet even the sharpest captains have one brain working against twenty variables at once.

Captain Cool is a multi-agent AI system built to change that. Feed it a live IPL match state and it deliberates — with real dissent, real data, and real cricket language — producing a confident tactical recommendation before the next ball is bowled.

It does this via two distinct agentic architectures:

  1. The Tactical War Room: A structured LangGraph pipeline of specialist agents.
  2. OASIS Social Simulation: An emergent social simulation where dynamically synthesized personas debate across multiple rounds.

The Technology Stack

To achieve real-time, grounded reasoning, we built on a pure Google Gemini stack:

  • Gemini 2.5 Flash — The backbone for all agents, chosen for its low latency and high reasoning capability.
  • Google Search Grounding — Live web search injected into agent context to fetch real-time player form and match-ups.
  • LangGraph — Orchestrates the agents as an explicit state machine with typed state.
  • FastAPI + SSE — Streams agent output character-by-character to the frontend for a “live debate” experience.
  • Next.js — A responsive dashboard for match input and visualization.

Mode 1: The Tactical War Room (LangGraph)

The War Room is modeled as a directed graph where state flows through specialist nodes. Unlike a simple chain, each node has a specific role, system instruction, and tool access.

The Architecture

graph TD
    Start((Start)) --> StatsGuru[Stats Guru]
    StatsGuru --> PitchSpec[Pitch Specialist]
    PitchSpec --> LeadStrat[Lead Strategist]
    LeadStrat --> DevilsAdvocate[Devil's Advocate]
    DevilsAdvocate --> Refiner[Lead Strategist - Refine]
    Refiner --> Commentator[Match Commentator]
    Commentator --> Synthesizer[Report Synthesizer]
    Synthesizer --> End((End))

The “War Room” State

We use a TypedDict to manage the evolving match context. Every agent can read the previous reasoning and append its own analysis.

class WarRoomState(TypedDict):
    match_state: dict
    stats_analysis: str
    pitch_report: str
    strategy_proposal: str
    devils_challenge: str
    strategy_revised: str
    commentary: str
    debate_log: List[Message]
    final_decision: str
    confidence_score: int

Specialized Prompts

Each agent is driven by a high-fidelity system prompt. For example, the Devil’s Advocate is explicitly instructed to be relentless:

System Prompt: “You are the ‘Devil’s Advocate’. Your sole purpose is to find the flaw in the Lead Strategist’s plan. You MUST challenge the proposal. Even if it seems sound, find the risk. Angles: ‘What if the dew worsens faster?’, ‘Are we burning our best death bowler two overs too early?'”

And the Stats Guru handles the data grounding:

System Prompt: “You deliver cold, hard cricket analytics. If the striker name is provided, ALWAYS search Google for their recent IPL stats and match-ups. Cite every number you use (e.g., ‘SR 145 vs leg-spin in last 5 seasons’).”

Physics-Based Win Probability Tool

Before the LLM reasoning begins, we invoke a custom tool to ground the agents in mathematical reality. This prevents “hallucinated optimism.”

def calculate_win_probability(innings, over, score, wickets, target, dew):
    # Physics-informed calculation
    projected = current_score + current_rr * overs_remaining
    diff = projected - par_score
    base_prob = 50 + (diff * 0.5)
    wicket_penalty = (10 - wickets_remaining) * 2.5
    return max(5, min(95, base_prob - wicket_penalty))

Mode 2: OASIS Social Simulation

While the War Room is hierarchical, the OASIS mode is emergent. It simulates the social dynamics of a coaching staff.

Stage 1: Dynamic Persona Synthesis

Instead of static roles, we use Gemini to synthesize 3 personas grounded in the specific match context. Chasing a high score in Bangalore? It might generate:

  • Coach Baz: Aggressive, high-risk, “Bazball” philosophy.
  • Data Dravid: Analytical, conservative, focuses on historical averages.
  • Old-School Rao: Spin-wary, respects the “V” and conditions.

Stage 2: The Multi-Round Debate

The simulation runs for 3 rounds. In each turn, the persona reads the entire transcript of the debate so far. This allows for opinion evolution: Data Dravid might concede a point to Coach Baz if the search results show a specific match-up advantage.

Round 1: Initial recommendations.
Round 2: Personas challenge each other's reasoning.
Round 3: Final attempts at consensus or principled dissent.

Walkthrough: The Death Over Dilemma

Let’s look at a real scenario: GT vs RR, 17th Over, chasing 190. Rashid Khan on strike.

  1. Stats Guru calls Google Search. Finds Rashid’s SR against pace in the last 2 years is 190, but drops to 110 against high-quality leg-spin.
  2. Pitch Specialist notes the dew factor is 8/10. The ball is like a bar of soap.
  3. Lead Strategist proposes bringing on the lead pacer (Bumrah) to “blow him away” with yorkers.
  4. Devil’s Advocate intervenes: “Wait! If we burn Bumrah now, who bowls the 20th? Rashid loves pace on the ball. If the pacer misses the yorker by an inch, it’s over the ropes. Use the leggie — Rashid’s ego will make him hit against the spin into the wind.”
  5. Refiner pivots: The Lead Strategist agrees with the risk of “pace on” and decides to hold the pacer back, opting for the spinner with a deep mid-wicket trap.

Result: A decision that factors in player psychology, environmental constraints (dew), and resource management (overs remaining).

Innovation: Why Multi-Agent?

Most cricket AI gives you a number. Captain Cool gives you an argument.

By decomposing the problem into specialist roles (Pitch vs. Stats vs. Strategy) and then pressure-testing it with a Devil’s Advocate, we mimic the real-world high-pressure deliberation of a dugout. The use of Google Search Grounding ensures the agents are talking about this version of the player, not their career average from 2018.

Explore the Project

  • Prompt Gallery: View our Agent Prompts in AI Studio (Simulated Link – Prompts are in the repo)
  • Architecture Source: Check out war_room.py and simulation_loop.py for the LangGraph and OASIS implementations.

Built at Build with AI Hackathon, May 2026. Powered by Gemini 2.5 Flash, LangGraph, and a genuine love for IPL cricket.

Afrika Türkiye İşbirliği Platformu Başkanı Genç: “Türkiye'nin Afrika'da tercih edilmesinin nedeni yaklaşımının ortak çıkara dayanması”

Afrika Türkiye İşbirliği Platformu Başkanı Osman Genç, Türkiye’nin Afrika’da karşılıklı saygı ve ortak çıkara dayalı yaklaşımıyla tercih edildiğini, ilişkilerin ticaretin ötesine geçerek enerji, sanayi ve güvenlik alanlarında stratejik ortaklığa dönüştüğünü belirtti.