Yet Another SWE Interview Cheat Sheet
I’ve gone through many a SWE interview cycle. For my two internships at Twitter and Google, and then to secure my full time position at Google, and even after that to make sure I know what’s out there and stay up to date. There are many articles offering advice on how to handle that. Here’s a quick list of do’s I’ve adopted through the years. Add a comment if you have any of your own.
Application and Job Search Tips:
- Cold-emailing recruiters
- Mass-applying online
- **Networking/ Finding referrals from past employees
- Check LinkedIn or ask friends about people they know
- Alumni and any networking resources your college has
Code practicing websites:
- Cracking the Coding Interview by Gayle Laakmann McDowell
- Programming Interviews Exposed by John Mongan, Eric Giguere & Noah Suojanen
Interview Prep Tips:
- Practice on paper/whiteboard/Google doc
- Read up on Big O and data structures in particular. Cheat sheets and practice questions are online and in books.
- Find a quiet/lockable room if it’s a video call/phone interview and a reliable laptop with steady internet connection
- Get some rest beforehand — very important
- Practice, practice, practice. Try interviewing with your lower-stake “safety” companies first to get an understanding of the coding interviews work. If you can get a mock interview or two those help as well!
During the Interview Tips:
- Be calm — you got this, even if the problem seems challenging
- Ask all the clarifying questions — don’t just start solving the problem
- Ask for input/output examples if not specified
- Offer to write test cases first. It helps you think about the edge cases and gives you time to come up with an optimised solution. Also, let’s you understand the question
- The best way to answer is to clarify, go through inputs/outputs with the interviewer, say a potential straightforward solution while writing some pseudocode, think through those inputs/outputs to test your theory. WRITE CODE. They want to see real code. If you have time write tests or talk through edge cases.
- Say what you’re thinking
- Literally speak everything short of word vomiting. “Oh I’m not sure. Maybe a hashmap would be useful. Oh maybe not cause that’s more complicated than we need. I think I want to try a suboptimal solution first by iterating through….” Anything. Just let them know you’re thinking and trying to solve the problem
- The interviewer will steer you in the right direction if you say the right keyword. Also shows you have experience using something. They are not trying to trick you
- Say if you’re not sure. They’ll clarify
- Start with an easy solution and then optimise it later
For behavioural questions, prepare a sheet or note with common questions and your responses:
- Why are you a good fit for this company?
- Why do you want to work at this company?
- How would you suggest improving this company or its products?
- What did you work on last summer? (Alternatively, talk about a recent project you worked on)
- What was the hardest problem to solve?
- How many lines of code did you write?
- What language did you use the most?
- What is your greatest strength? What’s your greatest weakness?
Prepare a list of questions to ask the interviewer
- How are teams organised
- What does career progression look like
- Are there opportunities to switch teams and try new things
- What does success in this role look like
- What’s your favourite part of working there?
- Do you do all your own QA/testing
- What’s the most exciting thing you’ve worked on there?
- What sort of organisation and development methodology do you use?
- How is work distributed and how do short and long term goals get set?
Other great resources and citation: