TECH CAREERS
Interviewing
Look up the companies you’re interviewing for and see if there are blog posts on the process. Recruiters also have good information. I do not make money from these links. Some of these resources (courses, mock interviews) are expensive. I felt the return on investment was worth it for the chance to >2x my compensation from the military but I recognize not everyone is in a financial situation to pay for those. I try to share free and lower cost resources as well.
Miscellaneous tips:
Have a crisp 1-2 minute elevator pitch. It really sets the tone!
Interview with companies you care about less first, to get familiar with the process
Resources:
Coding (writing good code from scratch)
Codecademy → refamiliarize yourself with basics and structuring code
Do a personal project starting from a blank IDE to ensure you can build.
Coding (data structures and algorithms)
Leetcode, Blind 75 → pay for premium to get access to analysis and answers
TryExponent good courses with mock SWE and PM interviews
Cracking the Coding Interview is a classic book; similar Python book
Use whatever language you’re comfortable in
Data analysis data science
I’ve heard good things about Ace the Data Science Interview for SQL
Introduction to Algorithms (popular, haven’t read)
System design books I liked
Volume 1 is also excellent but doesn’t cover as much (e.g., geospatial)
System design course (recommended by SWE), $60-$82
Domain specific:
ML: Designing Machine Learning Systems by Chip Huyen is a good place to start, but not enough in my opinion
From an ML hiring manager: voraciously consume open source material (Twitter, newsletters, papers, talks, etc) in the area you want to work in
Behavioral Questions
Look up common interview questions, draft answers for each of them based on your work experiences
Have a 30 second, 1 minute, 3 minute version for each. Sometimes its hard to gauge if the interviewer wants a quick answer or a detailed one. Focus more on the Action than the Situation.
Learn to signpost, to frame your story so it’s easy to follow, and then offer to go deeper if desired
Don’t under-value how hard cross-functional coordination can be. You probably have unique experience working across teams/orgs/influencing senior people. Share that!
Use the STAR format
If interviewing for Amazon, have stories for each leadership principle
Rehearse these stories, be passionate. STAR format is table stakes but passionately sharing a relevant work story is what separates great candidates from the rest of the interviewees
Product:
I found the Product Alliance courses to be very good. They offer company-specific courses and a bundle for multiple companies for $750
Lewis Lin’s books are a great start for understanding PM interviews
Mock interviews
For PMs: I used Prepfully and had a good experience. ~$140 / hr. They support other tracks (DS, SWE, TPM, etc). Another friend used for SWEs
Consulting case interviews:
Look Over My Shoulder by Victor Cheng ($111-$291), I liked this for McKinsey
Books (haven’t tried, but BCG offers these recommendations)
Case in Point, by Marc P. Cosentino.
Crack the Case, by David Ohrvall (especially graphs interpretation)
Ace Your Case!, by WetFeet.
The Vault Guide to Case Interview, by Mark Ashe
Prep by Role
Read books; take courses if you want; do mock interviews with friends/peers/paid experts.
Technical Program Managers: System design; domain expertise (if applicable); behavioral questions
Product Managers: Product design, craft, execution, strategy; behavioral
I’ve heard Amazon requires PM-Ts to do system design
Google Cloud will do domain-specific (e.g. Cyber, ML, big data) interviews
Software Engineers: Here are some tips from someone who’s gone through some SWE interviews:
Research the style of coding interviews at each company. e.g. at Meta they restrict you from running code and focus on explaining your thought process and writing good code without running it. You can have a fantastic performance and never even run code. Other companies have more of what you might expect where there are a set of test cases you need to pass.
More senior roles will require you to perform systems design. Junior roles do not do this. Read some of the prep books above
This collection of posts is targeted at staff engineer level, but is generally applicable and one of the best walkthroughs of the full process from prep through the actual interview.
Data Integrations & Engineers/Solutions Architect
Take-homes: Compared to traditional SWEs, jobs for data/analytics engineering or integrations as well as solutions architect require technical skills that are less algorithmic in nature, but learn more into problem-solving skills. The interviewers care less about seeing you code on the spot, but more about how you can solve complex problems when given a few hours. Because of this, there is a higher likelihood you may be given a take-home exercise to work on for this job role. These take-homes aren’t chatgpt-able or an easy stack overflow answer away because they’re not straightforward. However, syntax and documentation can be found on the internet. The trick here is to be able to think through the problem, find the necessary resources online, and then piece together your solution.
Besides coding in Python/Java/Scala, you’d also be expected to be pretty good at SQL in this role, or at least capable of figuring it out given some time (take-home). It’s also important to do well in system design for big data systems. These are the people working to enable the data scientists. Knowledge of at least one common data stack is important as well.
Data Scientists
Requires a strong foundation in statistics, ML algorithms, big data tools/frameworks (e.g. Spark), and visualization methods.
Coding: Varies by company and role.
Some amount of SWE principles, how do you deploy a model you’ve trained?
Mock Interviews
I was skeptical of mock interviews at first but found them to be really helpful. Performing in a realistic scenario is better than saying answers out loud, is better than thinking about how you would answer.
Some companies will offer mock interviews as part of their process. Always take them.
Some groups (like Lewis Lin’s PM peer interview community) offer free PM mock interviews. You can also ask veterans in tech that you know to interview you and give detailed feedback.
Paid interviews are also an option. I felt like they were a good return on investment but they can get expensive. (~$140 per). Better for those targeting higher levels who need skilled interviewers and granular feedback.
SWEs — I’ve heard of interviewing.io; and pramp but have not used them. There may be interesting AI tools now as well.
Coding Interview Detailed Guide
There are many online guides and with a bias toward solving “hard” leetcode style problems. Understanding data structures and algorithms and being able to solve leetcode problems is necessary but not sufficient to pass coding interviews because other skills are tested as well. Other common tasks include: code a simulation (e.g. write code to play a simple card game) and fixing bugs in an example codebase.
Flow for a Coding Interview
Showing you can think in a structured way is as important (if not more important) than getting the right answer. Share your thoughts out loud, guide the interviewer (e.g., say “here’s my pseudocode solution, if you’re ready I can implement this in code” instead of merely “here’s my pseudocode”), through the problem, and use these steps.
Consider writing these high-level steps on a note card and having it by your computer during an interview to use as an aid in structuring the discussion. In a high-pressure interview it’s easy to get hyper-focused on the problem and forget to add this structure.
If you’ve seen the problem before, admit it. Solving a problem immediately will be obvious to the interviewer that you have it memorized and won’t be good for you.
Restate the problem to clarify its scope and align on understanding w/interviewer
Define types for the inputs and outputs if not provided. E.g. “The problem says we’ll receive a name, can we assume that names are just strings?”
If you don’t know exactly what form your input data will come in as, you’re not ready to move on.
You can sometimes simplify a problem by proposing a specific input format to your interviewer.
Identify edge cases. E.g. “Could there be multiples of the value we’re searching for”
Ask if you should handle them, if it doesn’t look trivial to do so. For example, you might say “should we handle NaN or Inf values in our code” The interviewer will probably say no in that case, but it will be good that you’ve identified it.
Identify a general type of problem/approach, whether that’s graph, array, or dynamic programming. Identifying those immensely narrows down your range of potential solutions to consider, and should make the problem less intimidating. I kept a notecard of all the approaches I have, with “DP, memoization” at the bottom as a final hail mary if I hadn’t identified anything so far. It saved me once.
Identify multiple relevant solution paths, and their tradeoffs
This is more for algorithm questions, less for coding a card game
At least one of those should probably be a brute force approach.
A common example is if you’ve identified your problem as an undirected graph, two solutions probably use breadth first and depth first search.
Leetcode prep / cracking the coding interview type resources will help you practice this skill.
Start with only talking out the solution (don’t jump into code!)
If you’re stuck, ask the interviewer if they have any hints or advice. Good interviewers won’t care much if you can’t figure out some clever leap of logic, if all you need is a nudge in the right direction and you’re solid everywhere else then it probably won’t even count against you.
Comparing potential solutions and making a reasonable choice sends an incredibly strong positive signal to your interviewer, and is expected at higher levels.
Write out your solution in pseudocode/english.
E.g., comments with what will happen, indenting comments the way you would real code in a loop or if statement.
State the big O of your solution for time and space.
Turn your pseudocode into code
Code quality matters, choose clear variable names, don’t try to write clever dense code that the interviewer won’t be able to follow. If they can’t follow it they can’t offer you hints or help.
Double check those edge cases from earlier
You don’t want to be hasty and overlook something that is obvious
Run the tests/ walkthrough running it conceptually.
The conceptual run through is pretty popular lately. Basically, you verbally walkthrough how it would handle an input. So you would say “at this point we increment the counter by one, and then we move to this else statement” and then you should have a comment somewhere where you’re keeping track of the counter variable. This makes sure you know what your code’s doing. The interviewer will probably let you know if they want you to walk through it like that.
Bonus round: How would you scale your solution? This comes up for more senior positions. Basically, how would you make it faster or work as a distributed system.
At a minimum, you should know how to apply the following techniques: Breadth first search, depth first search, binary search of a sorted array, sliding window, two pointers, heaps for keeping track of the top-k elements, topological sort of a directed acyclic graph, dynamic programing, memoization, binary tree traversal (in-order, preorder, postorder), using a queue, using a stack.
Other Interview Considerations
Throughout interviews, look to see if the company is a fit for you.
You may meet future team members or your manager. Do you like how they present themselves?
Ask questions at the end of interviews. What’s the culture like? Has anyone left? Why are they hiring for this role? Is the team growing?
Every company, from startups to big tech, will say they move fast through interviews and offers. Few actually do. If you have multiple interview loops at different companies you need to manage the timing (and push companies) and ensure the offers come the same time so you have more leverage as a candidate