harisrid Tech News

“You get better at what you practice” ( but only what you practice 😛 )

Behavioral interviewing ( at higher organizational levels ) is harder. Personal learnings have let me identify reasons contributing to their difficulty. Let me share my insights ( from failed and passed behavioral interviews )¹!

What makes them difficult?

a. Scenario-specific experiences lacking – it’s hard to answer what you haven’t encountered such as “How you handled a crisis” or “How do you handle failure”. How do you answer if your company’s flagship products don’t entail a need for production on-call duties ( there’s no actual crisis )?
b. Longer-term tenure needs – scenarios usually arise from having created, shipped, and managed features to production environments. It’s harder for someone who works a role for less than a year to answer questions with satisfactory depth.
c. A literal interpretation of questions – you can be a junior engineer and still “lead” a project. Just because you’re not a manager or a staff+ engineer doesn’t mean you didn’t “take the lead” or “drive the conversation”.
d. Over-indexed technically – to many engineers over-index their leetcode or system design skills – skills that are easier to practice individually.
Partial blame rests on the inherent design and the process of company on-sites – leetcode-style coding questions occupy the bulk of their time. Asa the adage goes, “you get better at what you practice”. Let’s also run a calculation – suppose a senior engineer does on-site loops across five companies emulating a five-hour long big-tech esque style interview : a one hour coding phone screen, two hours of coding, one hour of system design, and one hour of behavioral interviews. Multiplying by the factor of five, we end up with 3*5 = 15 coding hours, 1*5 = 5 design hours, and 1*5 = 4 behavioral hours. Our day jobs and our interviews loops emphasize coding over communication.
e. Under-indexed behaviorally – there’s a need for more leadership, soft skills, or advisory-role emphasis – engineers need to get practice in other role requirements that are harder, such as work delegation, task decomposition, setting meeting agendas, and working on codebases at “higher levels”.
f. Subjectivity – technical and design interviews are easy to evaluate ; does your code work, did you arrive at a working solution, did you pass all the test cases, did you design to account for failure modes and scalability concerns? They nearly follow a templated structure ( see Alex Xu’s system design books ). Behavioral interviews are more subjective . Your interviewers index for character traits ; some desire an R&D-esque person who’s good at admitting when they don’t know something; some emphasize stronger leadership; others select for mentor-figures to grow junior talent. What helps you pass one doesn’t help you pass another.

What helped me ( and may help you )?

I struggled to understand how to answer commonly-encountered scenarios – online posts and other book material was really drab and dull to go through.

I lucked out on finding the ( at the time, around $25.00 USD ) The Behavioral Interview Deck². It helped tremendously ! The color-coded, gamified way of preparation got me through. On a quotidian, daily basis, I practiced one to two cards.

Step #1 : Play the cards that play to your strengths!

I focused on cards that played to my strengths and my experiences and answering questions that I knew how to better answer. Let me share the example questions ( and parts of responses ) that helped me :-). Some as S.T.A.R.-esque answers; others deviate from the template³.

• What motivates you?
  – Collaborating with other engineers – my best work has never been individual, it’s been working in collaboration with other engineers
  – Helping someone else “click” their mental lightbulb – seeing someone’s brain light on fire is amazing.

• Describe a time when you had to troubleshoot a problem.
  Situation : An enterprise event-stream failed to process payloads one day, and my PM noticed anomalies
  Task : I had to investigate and determine the root cause of failures
  Action : I bolstered our logging and debug posture by introducing more statements and making log outputs more verbose. I re-ran experiments in production and discovered that I needed to expand the rules engine for failed payloads to account for an unexpected edge case scenario with stale server-side assets on valid client events.
  Results : I expanded the underlying rules engine and re-deployed our team’s application to production with minor changes. We stopped observing failures for the next couple of days going forward, and felt more confident in our delivery.
  ⁴
• Can you describe a time you had to learn a new skill?
• Describe a time you had to adapt to a new situation

Tackling the easier, low-hanging fruit questions helped me build momentum and helped me build a “mental” response bank for more rigorous questions.

Step #2 : Don’t memorize the scripts. Modify them for your weaker cards.

I have my weak cards too. And for those, I have to leverage superpowers – creativity and out-of-the-box thinking.

One question example – “Have you ever manage a crisis”?

Ok so in reality, I’ve seldom run into a “crisis“. I haven’t been involved SEV-0 incidents where I hopped on an all-hours PagerDuty call, spending hours to resolve production bugs at 2:00 a.m.. Neither did I run into a crisis where I accidentally caused production to metaphorically “go on fire” or generated a net loss of $1 million plus in revenue.

Do I have the stories⁵ to present at higher levels, such as taking on the duties of a direct manager or a senior staff engineer who explicitly received customer complaints regarding major data breaches? Did I ever “break the glass” to activate internal data handling mechanisms to contain and to minimize the consequential blast radius? Absolutely not.

But I did manage my own levels of crises, as a senior. I ran into a situation with recent production releases to meet feature deadlines. I had to learn how to address issues pushing features, which I said would work in production, which clearly did not, because I signed off of them to early.

And in the process, I had to coordinate with two other developers and my direct manager on pre-production release meetings and production release meetings to push a feature deadline back by a few days. I had to work through a series of steps and review a mental checklist of checks – configuration values, secrets, network connectivity, and rules engine code deltas for unexpected edge case scenario handling . I also coordinated with my dev team to verify if we could deploy the changes as hot fixes on a release branch ( an undesired practice, since this avoids pre-check safety steps such as code reviews ).

And I learned. I learned a lot.

I learned that its easy to stay calm and composed by working together with other developers and not solutioning issues alone.

I learned how to collaborate with other developers in high priority release meetings.

And I also learned how to address issues collaborative and with efficiency. We delivered a working and more robust version of the feature to production. Basically, we “went-live”.

Step #3 :

1. This post was inspired by a friend who asked for help on preparation! ↩︎
2. I’m not affiliated 🙂 . https://9to5cards.com/product/the-behavioral-interview-deck/ ↩︎
3. We ( in my honest opinion) over emphasize S.T.A.R-esque responses. Not all behavioral questions need you to follow this format – you can deviate and answer differently, but genuinely ↩︎
4. (As of the articles date ) 05/10/2025 ↩︎