Interview Playbook: What Worked for Me

#career #interview #learning #computerscience

I have been through a lot of interviews, and I would love to share what I have learned and how I tackle different types of questions.

The approach I follow while giving interviews is KISS — Keep It Simple, Stupid.

I have been nervous many times and forgotten answers I prepared the whole night before and that’s okay. I take a deep breaths, drink water, calm myself before going into the interview so that I speak clearly and confidently. I don’t wanna come across as someone unsure of themselves.

I own and present what I have done confidently.

In Technical Interviews

When I'm given one or two problems to solve in front of the interviewer, I follow this approach:

1. Listen Carefully
Whenever the interviewer starts explaining the problem, I listen carefully. I don’t try to act smart and start solving it midway. I pay attention to every word and understand the examples clearly.

2. Draw an Example
An example can dramatically improve your ability to solve a question, yet many candidates try to solve it in their heads. If no example is provided, I create a simple one and explain the question using it. I think about possible edge cases as well.

3. State a Brute Force Approach
After understanding the example, I state a brute-force solution. Sometimes I can’t come up with the optimal solution immediately and that’s okay. I explain each step and why I chose a particular approach or algorithm.

4. Optimize
Then I try to optimize. If my brute-force solution has a time complexity of O(n²), I try to reduce it to O(n) or O(log n) where possible.
For example: If I initially use Bubble Sort, I may switch to Merge Sort or Quick Sort to improve efficiency.

5. Walk Through Your Thinking
At each step, I share my thought process with the interviewer.
I explain:

Why I chose this approach
The time complexity
Possible improvements

If my approach is wrong, I don’t panic anymore. I adjust and improve it on the spot. This shows adaptability.

6. Implement
After explaining my approach verbally or through pseudocode, I move into coding. If I forget something small like a method name, I ask “Can I quickly check this?” But I never copy-paste code. The interview is meant to test my ability.

7. Test
Finally, I test the code. If it’s on a coding platform, the test judge evaluates it. If it’s written on a document, the interviewer reviews it. This is often where real learning happens.

Think clearly. Speak clearly. That’s half the battle.

In Behavioral Interviews

Tell Me About Yourself

This is basic but often difficult. I follow this structure:

Current Role (headline)
College
Post-college journey
Current Role (details)
Outside of work
Wrap-up

This structure keeps the answer clear and straight to the point.

What’s Your Weakness?

I answer this in three steps:
Step 1 — Own It
“I used to be short-tempered.”
Step 2 — Explain the Trigger
“When I get stuck in loops or repeated blockers, I get frustrated.”
Step 3 — Show Improvement
“Now I take short breaks, reset, and return with a calmer mindset.”

The key is growth.

What Questions Should You Ask the Interviewer?

Before interviews, I research the company and prepare questions like:

What does success look like in the first 6–12 months?
How does the team balance quality and speed?
What’s the most technically interesting problem the team is solving?
How do engineers grow and take ownership?
How are technical decisions made?
Good questions show preparation and maturity.

Explain your projects

For explaining my projects, this structure has helped me a lot:

Before interviews, I prepare 1–3 projects where I played a central role.

Points I Keep in Mind During Behavioral Questions

Be Specific, Not Arrogant: Confidence is good. Arrogance is a red flag.
Limit Details: I limit details unless the interviewer asks for more. This keeps answers concise and structured.
Focus on “I,” Not “We”: Even though we work in teams, interviews evaluate individual contribution. I focus on what I did.
Give Structured Answers:

Nugget First : I start with a short summary of what I’m about to explain. Example: “I’ll tell you about a time I had to step up as a leader to deliver a project on time.” Then I explain.
S.A.R (Situation – Action – Result): I explain: The situation. The action I took. The result. Example: “At 2 AM, our production server crashed. I analyzed the logs, restored from backup, added a load balancer to distribute traffic, and improved load handling. As a result, downtime was reduced and performance improved.”

Be honest. Be structured. That’s usually enough.

Interviews are not about being perfect. They are about thinking clearly under pressure.

I may forget answers. I may make mistakes. I may not get every problem right. What matters is how I think, how I communicate, and how I adapt. This approach worked for me and I’m still improving it. I live by this quote.