💻 Software Engineering
Most entry-level SWE interviews check three things: can you solve a problem in code under time pressure, do you understand the fundamentals behind what you've built, and can you talk through your own projects clearly. Depth beats breadth — knowing two projects cold is worth more than a long list of buzzwords.
Common interview questions
Not exact questions you'll be asked — but the shape of what gets asked, and how a strong answer is structured.
Walk me through a project on your resume.
Structure it: what problem it solved, what you specifically built (not the team), one real technical decision you made and why, and one thing you'd do differently now. Avoid narrating every file in the repo — pick the one or two decisions worth defending.
What's the difference between a process and a thread?
A process has its own memory space; threads within a process share memory. That's the one-line answer — be ready to follow with why that matters (context-switching cost, shared-state bugs) rather than stopping there.
How would you find a cycle in a linked list?
Floyd's cycle detection (slow/fast pointers) is the expected answer for O(1) space. Say the brute-force (hash set, O(n) space) first if you're unsure, then optimize out loud — interviewers weight your reasoning process, not just the final answer.
Tell me about a time you disagreed with a teammate's technical decision.
Pick a real, small disagreement. Show you argued with evidence (not just preference), and that you could also accept being overruled or find a middle path. Avoid stories where you were simply right and everyone else was wrong.
What happens when you type a URL into a browser and press enter?
DNS lookup → TCP handshake → (TLS handshake if https) → HTTP request → server processes and responds → browser parses HTML/CSS/JS and renders. You don't need to go deep on every layer — name all the steps, then let the interviewer pick one to go deeper on.
How would you design a simple rate limiter?
Name a technique (token bucket or fixed window counter), say what you'd store it in (an in-memory map for a single server, Redis for multiple servers), and flag the one real trade-off: accuracy vs. memory/complexity. You're not expected to write production code for this live.
Your learning path
In order — each step builds on the last.
- 01
Nail two projects, not ten
Pick your two strongest projects and be able to explain the architecture, one hard bug you hit, and one trade-off you made, out loud, in under 2 minutes each.
- 02
Drill core data structures
Arrays, hash maps, linked lists, trees, basic graph traversal (BFS/DFS). Most entry-level DSA rounds live almost entirely in these five.
- 03
Practice explaining while coding
Interviewers evaluate your thought process, not silent typing. Practice narrating your approach before you write a single line.
- 04
Know one system-design basic
For new-grad roles, 'design a URL shortener' or 'design a rate limiter' at a surface level is often enough — you're not expected to design Twitter.
4-week study roadmap
A week-by-week plan, not just a topic list. Check items off as you go — your progress is saved on this device.
Foundations
Core data structures & patterns
Graphs, recursion & mock practice
System design basics & polish
Before you walk in: field checklist
The field-specific things worth double-checking you've covered.
Interview-day checklist
The same basics matter whatever role you're interviewing for.
Free resources to study from
Cold mail tips for this field
- —Lead with one specific thing about their engineering work, not 'I'm very interested in your company.'
- —Link a project, not just a resume attachment — something they can open in one click.
- —Keep it under 150 words. A long cold email reads as unconfident.
Ready to put this to use?
Browse open roles →