Mid/Senior SWE Interview - Prep Anecdote. AMA.

Recently received some offers and made a post (https://www.teamblind.com/post/UJn3YDTL ). There were some interest in how I prepared. So creating a new post to capture my preparation. AMA. YOE: 4 (tech) + 6 (non-tech) TC: 370 # Preparations ## Resume • I use Overleaf (https://www.overleaf.com/latex/templates/tagged/cv ) to build and iterate my resumes • I sometimes throw a job description into ChatGPT and ask it to write some resume style bullets and tune it with a brief writeup of my own job/experiences/skills. I then select some good ones and rewrite it in my own voice. • I customize resume for roles I *really* like. And use a base resume for others. ## Coding, Data Structure, and Algo • LeetCode (neetcode.io's roadmap is how I would approach it if I were to start from scratch) • AdventOfCode (also great for learning a new language) • Work through a few LC Hards (e.g. segment trees, DP) but recognize that LC hards are a toss up when you come across them in an interview. Better to develop intuition on how to brute force something before trying to build intuition around the "trick". • Give interviews regularly when I was still employed • Do time-boxed mock interviews or take on real interviews • Get into a habit of visualizing DS&A with pseudocode and/or diagrams • Get into a habit of explaining your code ## Programming Language(s) • There are rare moments where companies will look for very specific in-depth understanding of a language. You should check with recruiter or develop an intuition against job description if this is something that will come up. • For example, distributed systems engineer interviews might ask about concurrency, threads, process, memory management, blocking/async interfaces, etc. I took the easy way out by using Golang because it has built-in concurrency primitives and garbage collection lol. But you should be familiar with your language of choice. • Think about some of the data structures you are using, interviewer might ask "are they thread-safe?", "how do we make it thread-safe?", "at what costs?", "can we mitigate the costs?". • Good grasp of your language's standard library. • Best way to prep is to perform on the job, LC, or building side projects ## System Design • I suck at back-of-the-envelope math w.r.t. to storage size and throughput • It always ends up being "let's design it for scale", implying our system needs to be elastic and can scale horizontally • Practice designing API specs (usually CRUD operations) • Understand socket connections (when to use it, why should we use it). But the moment it becomes bidirectional, our system becomes complicated (e.g. stateful connections), so be aware of the tradeoffs (e.g. additional orchestration of servers needed, how to discover and reach clients? how to handle reconnections?) • Develop intuition for when to use SQL vs. NoSQL along with limitations, tradeoffs, and ways to address limitations. • Practice designing schemas (think about indices, joins, etc.) • I've read up on consensus algos, fault scenarios, and linearization. But TBH these concepts don't really stick with me and no one has asked me about them so far. • Round out designs with understanding of load-balancer, TLS, authentication/authorization, and observability. • Some resources I used: DDIA, Alex Xu's books, YouTube (Interview Pen, Gaurav Sen, Neetcode, System Design Interview) ## Behavioral • Know your own resume inside/out • Being able to talk about your projects end-to-end (e.g. problem statement, scope, requirements, design, implementation, testing, production, impact, xfn collaboration) • Try to research the company/team/role (e.g. use their product, stalk LinkedIn profiles, read their sites, blogs, and ask recruiter questions) • Think about what you did well and what you can improve • Review your historical performance feedback • Review feedback you've provided in the past • Prepare anecdotes around leadership/mentorship (if you are gunning for senior roles) ## Routine • At least 1 LC a day • SD review ~ once a week (sometimes less) • I watch a lot of tech videos on YT (sometimes just have them as background noise) • I try to schedule and go through interviews at least once a week # Interviewing ## Before Interviewing • Get enough sleep (!!!) • Eat healthy • Don't cram (it doesn't help) • Try to relax and breath (you got this) ## Coding 1. Clarify problem scope and requirements 2. Run a test case by hand manually 3. Propose DS and A that can solve the problem 4. Use pseudocode to visualize approach 5. Get buy-in from interviewer (to see if they want better approaches) 6. Code out solution (*should be* straightforward with the above) 7. Test code and address edge cases • Really make an effort to write clean and compilable code in one pass. You DO NOT want to waste precious time trying to fix silly mistakes. • Correct (or nearly correct) solution in one pass leaves a great lasting impression! ## System Design 1. Clarify problem scope and requirements 2. Define API specs 3. Identify data storage types and schema 4. Draw out high level design 5. Get buy-in from interviewer (and see where they want to drill down further) 6. Draw out low level design 7. Discuss limitations, tradeoffs, and mitigations ## Post-interview • I recreate my system design interview with Google Docs and Drawings (if I didn't already have it from the interview). This goes into my collection of study material. • Feel proud and celebrate your efforts • DO NOT catch any feels before an offer • DO NOT slow down before the finish line # Thoughts I wish it is possible to just follow the above and get any job you want. But chances are if I had a different interviewer, or slept a little less, or ate too big of a lunch, or butterfly flapped its wings somewhere... I would've bombed a round. I've never felt TRULY prepared going into any interviews. I will always be a little bit nervous before each coding/SD round. And I think that's natural. Confronting your anxiety, being in the moment, and giving your all, will always be the only way to get through these interviews. IMO, it's ultimately a game of perseverance and timing.