If you have an IT interview coming up, you don’t need 200 random questions. You need a focused list you can actually practice—and a few clear ways to answer.
Most interview processes have two recurring parts:
- HR/behavioral (how you work, communicate, decide)
- technical (how you think, design, ship, and debug)
TL;DR
- Don’t memorize answers—prepare 6–8 real stories and adapt them.
- In technical rounds, explain decisions and trade-offs (not just “what you did”).
- Always start with context (scale, constraints, deadlines, team).
- If you don’t know: explain what you’d check, how you’d test, and how you’d reduce risk.
How to use this list (without wasting hours)
- Pick one role area (backend/frontend/QA/DevOps/data) + the HR section.
- Highlight 12–15 questions and write bullet-point answers.
- Practice out loud for 15 minutes. Clarity beats “smart-sounding”.
Table of contents
- 10-minute quick plan
- Prep checklist (24–48h before)
- Self-intro (60–90 sec)
- HR / behavioral questions
- Technical questions (general)
- Role-specific questions
- Coding test / take-home
- System design (practical)
- Questions you should ask them
- Salary & offer
Prep checklist (24–48h before)
- Re-read the job description and highlight 3 core requirements (stack + responsibilities).
- Prepare 2–3 highly relevant examples (impact + results).
- Have a clear self-intro (60–90 seconds).
- You can defend every CV bullet (details + context).
- You have a list of questions to ask (10–12).
10-minute quick plan
If your interview is soon and you want a tight plan you can act on immediately, pick a role area and copy the checklist.
Mini interview prep plan (10 minutes)
Pick your role area and get a tight prep checklist + story prompts.
Self-intro (60–90 sec) template
HR / behavioral questions (what they really want)
1) “Tell me about yourself.”
They want a coherent narrative and a signal you fit the role. Use the self-intro template and make it role-specific.
2) “What project are you most proud of?”
They want ownership + impact + how you think. Use: Context → Action → Result → Learning.
Short sample answer: “Context: [what was broken / what needed to happen]. I chose [decision] because [trade-off]. Result: [metric / outcome]. Next time I’d improve: [one thing].”
3) “Tell me about a conflict and how you handled it.”
They want maturity and collaboration. Keep it factual, no blame, show how you aligned expectations.
4) “How do you handle tight deadlines?”
They want prioritization and trade-offs. Clarify scope, cut nice-to-haves, communicate risks, deliver incrementally.
5) “Why are you leaving / why this role?”
They want stable reasons. Focus on growth, ownership, product/stack, not complaints about your current company.
6) “Tell me about a mistake you made.”
They want ownership and learning. Explain the context, the signal you missed, and what guardrail/process you added afterwards.
7) “How do you handle feedback?”
They want collaboration. Give one concrete example of feedback that changed your approach and improved outcomes.
Technical questions (general) — how to answer well
1) “How would you design an API for X?”
Cover: inputs/outputs + error cases, versioning, auth, rate limiting, observability, testing strategy.
2) “How would you improve performance?”
Start with measurement (profiling/slow queries), optimize the real bottleneck (cache/indexing/batching), validate with metrics (p95, error rate).
3) “How do you debug production issues?”
Reproduce → minimize → observe logs/metrics → validate hypotheses → add a test/guardrail to prevent regressions.
4) “How do you ensure quality?”
Testing where it matters, code review, static analysis, release safety, monitoring + rollback.
Role-specific question bank (pick what matches your role)
Backend
- Domain modeling: how do you keep code maintainable as product grows?
- Deploy/migrations: backward compatibility and safe rollouts
- Async processing: queues, retries, idempotency
- Security basics: auth, validation, rate limiting
- How do you avoid breaking existing API consumers?
- You have a slow production query: how do you investigate and fix it?
Frontend
- Performance: bundle size, LCP, lazy loading, caching
- State management and long-term complexity
- Accessibility and reusable component systems
- How do you debug intermittent UI bugs (race conditions, caching, browser differences)?
DevOps / SRE
- What metrics matter and how you avoid noisy alerts
- Incident response and post-mortems
- Safe deployment patterns (blue/green, canary, rollback)
- How do you handle secrets and access control?
Data
- Data quality checks and reproducibility
- Cost/latency optimization for pipelines
- Governance and access control
- How do you communicate results to non-technical stakeholders?
QA
- How do you decide what tests are worth it (unit/integration/e2e)?
- How do you reduce flakiness and speed up feedback?
- What does a “useful bug report” look like in practice?
Coding test / take-home — what to clarify
Ask before you start:
- What are the evaluation criteria (correctness vs style vs performance)?
- Expected time budget?
- What assumptions are acceptable?
- Are libraries/frameworks allowed?
- How should the submission be delivered?
Submission checklist:
- short README (how to run)
- minimal tests
- decision notes (2–4 paragraphs)
- limitations + next steps (clear, no excuses)
System design (even for non-leads)
You don’t need to be an architect to answer well. Interviewers usually want to see how you:
- structure an ambiguous problem,
- make trade-offs explicit,
- think about reliability, security, and operations.
Two good practice prompts:
- Design a URL shortener (API + storage + rate limiting + minimal analytics).
- Design a notification system (email/push) with retries and deduplication.
Answer checklist (in order):
- Requirements: in-scope / out-of-scope, main constraints
- Data model (simple first)
- API endpoints + error cases
- Scaling: caching, indexes, queues, batching
- Reliability: idempotency, retries, backoff, dead-lettering
- Security: auth, validation, rate limiting, audit (when needed)
- Observability: logs/metrics, and how you’d debug an incident
STAR worksheet (behavioral questions)
Prepare 4–6 real stories before the interview.
Questions you should ask them
For a full list, see our guide: questions to ask recruiters/hiring managers.
Short list:
- What does a typical day look like?
- What does success look like in the first 90 days?
- How do performance reviews and promotions work?
- Who owns priorities and how are decisions made?
- How does on-call work and how is it compensated (if applicable)?
Salary & offer (practical)
When you reach offer discussions:
- calibrate with Salary Insights
- use the salary negotiation checklist
- sanity-check numbers with the net salary calculator (2026)
A useful short answer to “What are your salary expectations?”:
- ask one clarification first: “Is this employee (CIM) or contractor (B2B)? What range is budgeted?”
- give a range (not a single number) and say what it’s based on
- confirm total compensation: bonus, stock, on-call, benefits, office days
FAQ
What if I don’t know the answer to a technical question?
Say you don’t know, then explain your approach: what you would check, your hypotheses, how you’d test, and how you’d reduce risk. Method matters.
How many stories should I prepare?
Usually 6–8 is enough: impact, conflict/collaboration, debugging/incident, and decision trade-offs.
Is a follow-up email after the interview worth it?
Yes. Keep it short: thank you + one sentence reinforcing interest + one relevant recap point.
Sources
- MIT CAPD — Career Handbook (interviews): https://capd.mit.edu/resources/career-handbook/
- Georgia State University Career Services — STAR method (behavioral interviews): https://career.gsu.edu/plan-your-career/resumes-cover-letters/interviewing/star-method/
