When you walk into a software engineer interview, the interviewers are looking for three things: technical competence, problem‑solving style, and cultural fit. The way they ask about each of these varies by round, but the underlying patterns stay fairly consistent. Below is a practical question bank you can use to map those patterns to your own experience.

1. Screening Round – The First Filter

Screening calls are usually 20‑30 minutes and focus on fit and basics. They often come from a recruiter or a hiring manager.

Question TypeTypical GoalExample Prompt
Resume walk‑throughVerify claims, gauge communication"Tell me about your most recent project."
MotivationAssess interest in the role/company"Why do you want to work at our company?"
AvailabilityAlign timelines"When could you start if offered?"

Sample Answer – “Tell me about your most recent project.”

“In my last role at a fintech startup, I led the migration of our payment processing service from a monolithic Java app to a microservice architecture using Spring Boot and Docker. The goal was to reduce latency and improve scalability. I designed the API contract, set up CI/CD pipelines with GitHub Actions, and coordinated a three‑person team. We cut average transaction time from 250 ms to 80 ms and enabled horizontal scaling, which supported a 40 % traffic increase during peak periods without any downtime.” (≈45 seconds)

Quick tip for the other three screen questions: keep each response to a single concise story (setup → action → outcome) and tie the outcome back to a metric or business impact.

2. Technical Phone / Coding Round – Core Skills

These rounds test algorithmic thinking, coding style, and sometimes system design basics. Expect 1–2 problems, each solved on a shared editor or whiteboard.

2.1 Must‑Know Algorithmic Questions (Top 5)

  1. Two‑sum / hash‑map lookup – tests O(1) lookups.
  2. Reverse a linked list – tests pointer manipulation.
  3. Binary search on a rotated array – tests edge‑case handling.
  4. Longest substring without repeating characters – tests sliding‑window technique.
  5. Merge k sorted lists – tests priority queue usage.

Sample Answer – “Longest substring without repeating characters.”

def length_of_longest_substring(s: str) -> int:
    start = max_len = 0
    last_seen = {}
    for i, ch in enumerate(s):
        if ch in last_seen and last_seen[ch] >= start:
            start = last_seen[ch] + 1
        last_seen[ch] = i
        max_len = max(max_len, i - start + 1)
    return max_len

Explain the sliding‑window idea, why you move start only when you see a duplicate inside the current window, and note the O(n) time / O(min(n, alphabet)) space.

2.2 System Design Mini‑Prompt (Top 2)

Design a URL shortener – focus on API design, data model, scaling reads vs. writes, and cache strategy. Design a notification service – discuss eventual consistency, fan‑out patterns, and throttling.

Sample Answer – URL shortener

Start with a simple REST API (POST /shorten, GET /{code}). Store mappings in a key‑value store (e.g., DynamoDB) keyed by a base‑62 short code. Use a hash of the original URL to generate the code, falling back to a random generator on collision. Add a CDN edge cache for reads, which handles the majority of traffic. For high‑throughput writes, batch insertions and use a write‑behind cache. Discuss how you would add analytics (click counts) via a separate write‑optimized store like Kinesis.

3. Behavioral Round – Culture & Collaboration

Behavioral questions probe how you work with others, handle conflict, and grow professionally. The STAR (Situation‑Task‑Action‑Result) framework is useful, but you don’t need to label each part.

3.1 Core Behavioral Questions (Top 5)

  1. Tell me about a time you disagreed with a teammate.
  2. Describe a project that failed and what you learned.
  3. How do you prioritize competing deadlines?
  4. Give an example of a time you mentored someone.
  5. What’s a technical decision you made that you’d change today?

Sample Answer – “Describe a project that failed and what you learned.”

“We built a feature flag system to roll out experimental UI changes. I was the lead backend engineer. Midway through, we realized the flag propagation latency was causing UI flicker for a subset of users. I missed an early performance test because I focused on functional correctness. After the rollout, we rolled back within an hour, but the incident highlighted the need for non‑functional testing early in the sprint. Since then, I’ve added latency benchmarks to every feature flag ticket and instituted a ‘performance gate’ before merge.” (≈55 seconds)

3.2 One‑Liner Guidance for the Remaining 5 Behavioral Questions

  • “What motivates you?” – Mention intrinsic curiosity and the joy of shipping reliable code.
  • “How do you handle ambiguous requirements?” – Emphasize clarifying questions, small prototypes, and iterative feedback.
  • “Describe a time you received critical feedback.” – Show openness, specific changes you made, and the positive outcome.
  • “What do you do when a deadline is at risk?” – Talk about early flag‑raising, re‑negotiating scope, and focusing on the highest‑impact tasks.
  • “Why are you leaving your current role?” – Frame it as seeking growth, new challenges, or alignment with the target company’s tech stack.

4. Role‑Specific Deep Dive – Senior vs. Junior vs. Specialist

Interviewers tailor questions to the level and focus of the role.

4.1 Senior Engineer Questions (Top 3)

  1. How do you ensure code quality across a large team? – Talk about code reviews, static analysis, and test coverage dashboards.
  2. Explain a trade‑off you made between performance and maintainability. – Provide a concrete scenario (e.g., using a cache vs. a more readable abstraction).
  3. What’s your approach to technical debt? – Mention debt backlog, ROI calculations, and scheduled refactoring sprints.

4.2 Junior Engineer Questions (Top 3)

  1. What’s the difference between a process and a thread? – Keep it high‑level, mention OS scheduling, and typical use cases.
  2. How do you debug a failing unit test? – Outline reproducing locally, checking logs, and adding assertions.
  3. Explain a recent bug you fixed. – Use a concise story, focusing on root cause analysis.

4.3 Specialist (e.g., ML Engineer) Sample Question

“How do you handle class imbalance in a classification problem?” – Discuss resampling, class‑weighting, and evaluation metrics like ROC‑AUC.

5. Putting It All Together – A Study Routine

  1. Chunk the list – Spend a day on each interview stage. Write out the sample answers in your own words, then record yourself delivering them.
  2. Use a mock interview tool – Have a peer ask the questions and give you real‑time feedback.
  3. Leverage Call Assistant – While rehearsing, let the assistant listen and surface follow‑up prompts, ensuring you stay on topic and keep your stories anchored in your resume.

How to practice this

  1. Create a spreadsheet with the 40 questions, marking the 15 you’ll master fully. Add a column for your personal story bullet points.
  2. Do timed runs: set a 45‑second timer for each of the 15 key answers; record and review for clarity and impact.
  3. Simulate the full interview: start with a screen‑round script, move to a coding problem on a shared editor, then finish with behavioral questions. Review the flow and adjust any weak spots.

FAQ

  • Q: How many coding problems should I expect in a technical round? A: Most companies ask one to two problems, each lasting 30‑45 minutes. Expect at least one algorithmic task and optionally a design or debugging scenario.
  • Q: Should I memorize code snippets? A: Memorization is less useful than understanding patterns. Focus on the underlying algorithmic idea (e.g., sliding window, two‑pointer) so you can adapt it on the fly.
  • Q: How important are metrics in my answers? A: Quantifying impact (e.g., reduced latency by 60 %, improved test coverage to 85 %) makes your story concrete and memorable. Use numbers you can back up with your resume.
  • Q: Is it okay to ask clarifying questions during a coding interview? A: Absolutely. Clarifying the input constraints or edge cases shows you think critically and reduces the chance of mis‑interpreting the problem.

Frequently asked questions

How many coding problems should I expect in a technical round?

Most companies ask one to two problems, each lasting 30‑45 minutes. Expect at least one algorithmic task and optionally a design or debugging scenario.

Should I memorize code snippets?

Memorization is less useful than understanding patterns. Focus on the underlying algorithmic idea so you can adapt it on the fly.

How important are metrics in my answers?

Quantifying impact (e.g., reduced latency by 60 %) makes your story concrete and memorable. Use numbers you can back up with your resume.

Is it okay to ask clarifying questions during a coding interview?

Absolutely. Clarifying input constraints or edge cases shows critical thinking and reduces the chance of mis‑interpreting the problem.

#Software Engineer#question bank#interview prep#2026#behavioural