[Zero Two]

Adding the behavioural side since I focused on technical in the main post and it's equally important.

Behavioural interviews (STAR format):
Situation, Task, Action, Result. Prepare 8-10 stories from your experience that can be adapted to different questions. Most behavioural questions fall into patterns:

• Conflict with a colleague/stakeholder
  
• A time you failed and what you learned
  
• A time you went above and beyond
  
• Handling ambiguity or unclear requirements
  
• Driving a project without formal authority
  

The "tell me about yourself" opener:
This is a 90-second commercial for yourself, not your life story. Structure: where you are now, what you've done that's relevant, why you want this role. Practice it until it feels natural, not rehearsed.

Questions to ask them:
Always have questions. Good ones: what does success look like in the first 90 days? What does the on-call rotation look like? What's the biggest challenge the team is dealing with right now? What do you like most about working here?

Asking genuinely curious questions signals interest and often reveals more about the company than any amount of Glassdoor research.

[Zero Two]

Coding interviews get a lot of justified criticism but for most engineering roles they're still the gate you have to get through. Here's what actually works based on personal experience and talking to people who do a lot of hiring.

What interviewers are actually evaluating
Most good interviewers aren't primarily evaluating whether you've memorised the optimal solution to a specific problem. They're evaluating: can you communicate your thinking, do you handle edge cases, can you take a hint and adapt, are you pleasant to work with under mild pressure.

The preparation that matters

• LeetCode: medium questions, topic by topic. Arrays, strings, hashmaps, two pointers, sliding window, binary search, BFS/DFS, dynamic programming. You don't need to do 500 questions - you need to understand the patterns.
  
• Implement data structures from scratch. Linked list, stack, queue, binary tree, hash table. Once. You'll rarely be asked to implement them but understanding them makes everything else easier.
  
• Practise talking while coding. Narrate your approach before writing. Most interview failures are communication failures, not algorithmic ones.
  
• Mock interviews. Pramp, interviewing.io, or a friend with a whiteboard. The format is a skill and needs practice separately from the problem-solving.
  

System design (for senior roles)
Read "Designing Data-Intensive Applications" (Kleppmann). Understand: load balancing, caching (Redis), databases (SQL vs NoSQL, indexing, replication), message queues, CDNs, rate limiting. Practice designing Twitter/Uber/URL shortener.

What to do in the interview
1. Restate the problem and confirm constraints before touching code
2. Talk through your approach first, get early feedback
3. Code clean and readable - names matter more than brevity
4. Test with the obvious case, then edge cases
5. Know the time/space complexity of your solution

The honest truth: the prep is boring and takes 2-3 months of consistent effort. There's no shortcut but it's a learnable skill.