Software engineering interviews have a reputation for being intense — and they are. But they're also predictable. Most companies test the same categories: coding, system design, and behavioral. The weight of each depends on seniority.
Junior roles lean heavily on coding. Senior roles add system design and leadership. Staff+ roles focus on architecture and influence. Knowing what level you're interviewing for changes your prep entirely.
Coding & Technical Questions
1. "Solve [algorithm problem] in your preferred language."
Live coding is stressful, but the approach matters more than the perfect solution.
Framework: 1. Clarify the problem — ask about edge cases, input constraints, expected output 2. Think out loud — explain your approach before coding 3. Start with a brute force solution, then optimize 4. Test with examples, including edge cases 5. Analyze time and space complexity
Tip: Interviewers care about your problem-solving process. A candidate who talks through their thinking and arrives at an O(n log n) solution beats a silent candidate who writes O(n) code without explanation.
2. "What's the difference between an array and a linked list? When would you use each?"
Fundamental data structures. These questions filter for CS basics.
Answer: Arrays offer O(1) access by index but O(n) insertion/deletion. Linked lists offer O(1) insertion/deletion at known positions but O(n) access. Use arrays when you need fast random access and know the size. Use linked lists when you need frequent insertions/deletions and don't need random access.
3. "Explain how a hash map works under the hood."
Goes deeper than "key-value store." Talk about hashing functions, collision handling (chaining vs. open addressing), and amortized O(1) operations.
4. "Write a function to detect if a linked list has a cycle."
Classic problem. Floyd's cycle detection (tortoise and hare) is the expected answer. Show you know the O(1) space solution, not just the hash set approach.
5. "What's the difference between a process and a thread?"
OS fundamentals. Processes have separate memory spaces; threads share memory within a process. Threads are lighter but introduce concurrency issues (race conditions, deadlocks).
System Design Questions
6. "Design a URL shortener like bit.ly."
The bread-and-butter system design question.
Cover: - API design (shorten, redirect, analytics) - How to generate short URLs (hashing, base62 encoding, counter-based) - Database choice (read-heavy → caching layer, Redis + persistent store) - Scale: how to handle millions of redirects per second (CDN, load balancing) - Analytics: click tracking, async processing
Key: Start with requirements and constraints before jumping into architecture.
7. "How would you design a notification system?"
Tests your ability to handle distributed systems, queues, and user preferences.
Think about: Push vs. pull, message queues (Kafka, RabbitMQ), delivery guarantees, batching, user preferences (opt-in/out), multi-channel (email, push, SMS), rate limiting.
8. "How do you handle a production outage?"
Not a design question — an operational readiness question.
Answer: "First, assess impact — how many users affected? Then communicate (status page, Slack alert). Debug: check logs, recent deploys, infrastructure metrics. If it's a bad deploy, roll back immediately. Fix, post-mortem, implement prevention."
Behavioral Questions
9. "Tell me about a technical decision you made that you later regretted."
They want humility and learning. Every engineer has made a bad call.
Structure: What was the decision → why it seemed right at the time → what went wrong → what you learned → what you'd do differently.
10. "Describe a time you disagreed with your team about a technical approach."
Shows collaboration, not stubbornness.
Good answer: "I presented my case with data, listened to their reasoning, and we found a middle ground." Or: "I disagreed, but the team decided differently. I committed fully and it worked out — which taught me that my way isn't always the best way."
Bad answer: "I was right and they were wrong, but they didn't listen."
11. "How do you handle code reviews?"
Tests your collaboration skills and standards.
Answer: "When reviewing: I focus on correctness, readability, and maintainability — not style preferences. I ask questions instead of making demands. When receiving: I appreciate thorough reviews and don't take feedback personally. If I disagree, I explain my reasoning."
12. "Tell me about a project where you had to learn a new technology quickly."
Shows adaptability. Pick an example where you shipped something real, not just completed a tutorial.
13. "How do you estimate how long a project will take?"
Senior-level question. Show you account for unknowns.
Answer: "I break it into tasks, estimate each, add buffer for unknowns (usually 30-50%), and communicate a range, not a single date. I also identify the riskiest parts early and front-load them."
Role & Culture Questions
14. "Why are you leaving your current role?"
Be honest but professional. Never trash your current employer. Focus on what you're looking for, not what you're running from.
Works: "I've grown a lot but I'm looking for [specific thing this role offers] — larger scale, different domain, more ownership."
15. "What questions do you have for us?"
Ask about: - What does the tech stack look like, and are there plans to evolve it? - How are engineering decisions made? (Top-down vs. team-driven) - What does the on-call rotation look like? - What's the ratio of new features vs. maintenance/tech debt? - How do you approach code quality (testing, CI/CD, reviews)?
What Separates Good Engineers From Great Interview Candidates
- Communication. You explain your thinking clearly — during coding, design, and behavioral questions.
- Trade-off awareness. You don't just pick a solution — you explain what you're optimizing for and what you're sacrificing.
- Pragmatism. You know the "right" answer and the "right for the situation" answer aren't always the same.
- Curiosity. You ask good clarifying questions before diving in.
- Ownership. You talk about projects in terms of impact, not just implementation.
Your Engineering Interview Is Unique
These patterns are common, but the specifics — the tech stack, the system scale, the team culture — depend entirely on the company and role.
Want questions tailored to your exact job listing? Paste the description at PasteJob and get a personalized cheat sheet with likely questions, answer structures, and signals from the listing — in 15 seconds.
Want questions specific to your job listing?
These are generic questions. For questions tailored to your exact role and company — paste your job listing at PasteJob