zyrosThis will be a work in progress for quite a long time! Anywhere between end of February 2025 all the way to June 2025!
Background
I’m an employee at a bigtech company in Australia, and I’m looking to move companies internationally. That means trading firms in Singapore, Hong Kong, and the US, or tech companies in the US. This document is going to outline the preparation I’m doing for this and my journey along it. There will be blocks of text that are redacted in here because they’re personal stories that I want to keep on the page for me, but not visible for people.
Disclaimer
You, the reader, probably should not treat this as a “how to get a job”, but rather just an anecdote of someone’s journey. If you want something to teach you how to get a job, you can read the tech interview handbook. Furthermore, this is not an end-to-end guide of how to get ready. I’m not going to talk about what projects you should do, but rather, after working how to prepare those reflections.
Also, interviews are opinionated. There will definitely be people that disagrees with what I’m saying here. Maybe I’m completely wrong on some things. Unfortunate.
Recommended content
Method
I break interviews into 5-6 topics. Data structures and algorithms, low level design, trivia, system design, behaviourals, then domain-level knowledge. Your domain-level knowledge probably sinks into behavioural stories and others, but you should also prep specifically for it. The way to dig into it is pretty simple: look at your resume (or hand it to an LLM and ask) and list 30-40 domain knowledge questions this person should know.
One comment is that some companies don’t ask any, or ask very little system design. In my personal case this is going to be the trading firms. I’m planning on applying to ~4 trading firms which will have a much lower bar for system design. So I will be breaking my own interviews into two phases. The first phase I won’t focus at all on system design, then the second I will target it much more heavily.
Once you’re ~reasonably confident in all of these, you can move towards mock interviews.
Data structures and algorithms
If you’re reading this here, you should already be bored of leetcode. Unfortunately, you should also already know that you need to know it. Go do grind75. You should at least know (according to hellointerview) two pointers, sliding window, intervals, stack, linked list, binary search, heap, dfs, bfs, backtracking, graphs, dynamic programming, greedy, trie, prefix sum, matrices. You can take a step further and do more advanced graph things like union find and segment trees.
For the interview itself, there are some high level things to learn. Here is a mental check list I track while I’m going:
- Listen to the problem, and respond by asking about edge cases or repeating your understanding back to them.
- Describe some solutions. If you know multiple, say “I can think of X approaches”, and make sure to explicitly say the algorithm, e.g. “topological sort”. Your interviewer is probably a mid+ SWE that also knows the algorithms!
- Ask if they’re happy with that solution and whether it makes sense to them
- Ask if they’re happy for you to start implementing it.
- Implement it and ask, “Does this make sense so far?”
- Ask if they want you to step through an example to clean out bugs, then do so.
- Write test cases
- Comment on time and space complexity
- Comment on concurrency → what if multiple things use your function, or how can you make the result more useful for callers (e.g. splitting a top sort into multiple lists).
The big thing is don’t pause for them to ask obvious questions, and be the person that initiates it instead. Those questions about “Does this make sense to you?”, “Are you happy with that?” are critical to keeping the interviewer engaged.
I’m not going to dive too much into the specifics here about algorithms themselves. You’ll know you’re confident when you can consistently finish 3/4 questions in leetcode contests from ~2023. If you go to recent contests, they’re significantly more difficult because LLMs broke the ELO system, so don’t do them. If you’re at this point and you want to take one step further, do not just start cycling more medium questions. Go do 50 leetcode hards from Neetcode All or do the starred hard/very hard questions on USACO.
My progress on DSA
Grind 75 is done! I did grind75 and DSA 1 - Syntax and Snippets is a recount of that.
However, I still need to do ~50 hards. I’m probably ~5 hards in.
Low level design
Alright. There are not many places online that let you practice low level design, or have large question banks for it. However, it’s getting increasingly common - especially around the high ranking companies. A small intro is something like Hello Interview’s LLD guide as a baseline, but you’ll see they have a whopping 6 questions. That isn’t enough. You’ll want to do more like ~40 of these. There isn’t really a platform around that walks you through these systematically and tells you whether your current design is good or not. If you ask an LLM this, there’s a good chance it will just agree with you and walk you through. You can hand it some custom prompt that encourages it in the direction you want, but then it might be too critical. So it’s tricky. Still, using Claude Code for this is quite good.
Goals
In my head, these interviews are scoping three skills. Clear communication, taking hints from the interviewer, and being ‘code-fluent’. All of this, and you need to be able to handle the passive pressure that’s going on. Especially if getting the offer is near life-changing for you (you need to move across the country etc), that passive pressure can be quite a lot.
A lot of these interviews will function in two stages. One very small question first that you should solve in under 5-10 minutes, then a larger question that’s more broad.
Each stage starts with, “Do you understand this base topic?” which can be very broad (time sync, garbage collectors, recursive descent parsing). If you don’t, it’s usually fine; just ask for an explanation. Do not try to pretend you know the topic. That’s part of the communication and taking hints from interviewers. It’s actually fine if you don’t know the topic and ask them to explain. The risks here are if you say yes you know the topic, then don’t explain, or if you don’t understand the topic after their explanation.
So, if you do know the topic, say something like “Yes, my understanding of garbage collectors is they’re either tracing or reference counting. For instance, Python maintains a counter for every variable in the program and when it hits zero it is immediately collected. It also has a tracing collector which scans through the entire graph, starting at threads, and if it finds an unconnected component or node it frees it. Does that make sense, and do I need to know more than that?“. Asking whether what you said makes sense and whether you need more than that is essential. It keeps your interviewer engaged, and understanding of what you know.
If you do not know the topic, it’s actually very similar. Listen to their explanation, then you have two choices. Repeat their explanation back to them and ask “am I understanding that correctly?” or more ideally, ask about edge cases like, “So is the purpose of the tracing component to detect cyclic components?“.
After that discussion of what the baseline concept is, they’ll have some question for you. If this is the first question, it’s fine to answer very quickly and the algorithm will probably be something like an easy-difficulty leetcode question. On the other hand, for the harder section there’s a very good chance they will say no to your first algorithmic proposal. Their goal is to throw you off, then give you a hint. Your idea is going to work though! Are you going to listen to their hint and be steered along their direction, or repeatedly push for your own idea? That’s part of the game. Are you friendly during conflict? Usually these questions are open ended so they can always push you in some direction.
Lastly, coding fluency. If you’ve done the 150-300 leetcode questions and you’re confident, and you figured out the core algorithm in the last interaction, this part is supposed to be quite easy. It depends though. You need to be fast. Doing assignments, projects, and work also makes you better at laying out this code.
Practicing
My personal question bank is a long-term built up one, so posting it probably breaks some NDAs or something if I publicly share it. Honestly, a very large chunk of these interviews is just interacting with the person. So what I recommend is doing a baseline of these on your own (maybe you have some company-specific question bank) then trying to do mock interviews.
Your solutions for these should only be 100-200 lines of code.
- Rate limiters
- Hash maps
- Tetris
- Spreadsheet engine
- Ring buffer
- Unique pointer
- Custom compression algorithm (just think about how to compress data!)
Many of these questions can be asked in a very open-ended way. For instance, the compression algorithm one you can just get asked for ideas about how you would do it. If you don’t have any, that can be a failed interview. Similarly, if you don’t know what a ring buffer is, that’s probably quite a bad sign.
You can look at people’s curated sets here or the official leetcode one here.
So, remember, the core goals are communication, following hints, and fluently turning ideas into code all while under pressure.
My progress here
Only about 5/40. Need to do more!
Trivia
Trivia is hard because it can be very very broad which can be daunting. You should look at it from your interviewer’s perspective and what they want out of this. Usually they’re checking that you have solid fundamentals and that you’ve gone deep into some topic and why. So this section of the document will be split into how to drive that conversation and what you should know.
Driving the conversation
They’ll ask you a question, and you’ll at first think, hey, that’s a very simple question. Such as where can the keyword synchronized be used in Java. If you get it right, they’ll chain to a higher difficulty. This will keep on chaining until you don’t know the answer to a question or two.
For those trivial questions you can just answer. That’s basically fine. When it gets harder, you can chain it into why you know the answer to that. Did you encounter it at work, was it important at some point? Now it’s a behavioural format. Your goal with the high-difficulty trivia questions is to turn it into a behavioural question. Obviously, don’t just start ranting. You should answer like, “That’s because it’s a sampling clock. I had to learn how hardware clocks work because of trading, do you want me to go into depth on that?“. They might disagree and just move to the next question. Otherwise you can continue, “When I started there one of my coworkers that started at a similar time used Instant to mark timestamps on messages, but that produces garbage so our trading system collapsed and we lost XXk dollars. So we read around and benchmarked the various methods. In the end, Aeron documentation mostly uses System.nanoTime() underneath which directly asks the hardware. We globally changed to that and looked out for it in pull requests”. They’ll probably continue on with more questions, but you made it a lot more interesting and showed real world experience.
Let’s say you hit a question that you don’t know the answer to. It’s okay, but not great, if you say “I’m not sure, but my best guess is DHCP is that thing where they dynamically allocate IPs to addresses. I haven’t had to look into that because it’s abstracted in our systems.” That “I’m not sure” sort-of protects you. It might be better to fully say that you don’t know, and try to push towards a relevant topic. “I don’t know much about DHCP, but for trading I had to think a lot about preventing message storms and when to use UDP”. As long as the original question isn’t something you’re supposed to know (i.e. it isn’t on your resume or computer science fundamentals), then this is fine.
The core thing to remember is that they’re digging that you know your fundamentals, and you’ve gone deep into some topic, maybe the specific topic you’re applying for, and you know the things on your resume.
Trivia you should know
You should obviously be able to answer about anything on your resume. Your interviewer should be able to pick up your resume, see in your skills section that you wrote “C++”, right at the end of the line like you’re trying to hide it. They can ask you, “so what’s a weak pointer?”, “what’s a spaceship operator?”, or “what’s the value category of std::move(value)?” (it’s an xvalue). If you write a skill on your resume, you are exposing yourself to risk. Someone can ask you questions and they can expect that you have a stronger understanding of it than they do. So, you need to be careful of what you actually put on your resume. I won’t be able to talk about everything there, so you’ll have to figure it out.
For more baseline trivia, think back to your computer science classes. Anything in your first and second years can get asked. The core things are data structures (what’s the time complexity of XYZ?), compilers (“where in memory is the program usually allocated?”), operating systems, networking, databases. If you’re mid+, they can also ask about system knowledge (“when would you use Redis, or why would you use Kafka over 0mq?”). You can read through System design primer for that.
Data structure trivia
This is quite easy. If you’ve done enough leetcode, you should be able to say these front-to-back in your sleep. A good resource is bigocheatsheet.
Operating Systems trivia
You should understand virtual memory, CPU scheduling, and have a low-level understanding of locks. Basically, you should be able to look at ostep’s contents and be able to talk about every column.
This is a diagram of demand paging.
You should be able to make a similar graph from memory.
TODO:
- Write about CPU scheduling, locks, syscalls, user level vs kernel level, persisting to disk, allocating data
Compilers Trivia
TODO
- Path of a compiler
- C++, Java and Python compilers + ecosystems
- Optimisations
- CFGs and code generation
- Where programs get allocated in memory and the representation of executables
- Language ‘correctness’
Networks trivia
TODO
- UDP vs TCP…
- What happens when you type ‘Google.com’ into your browser?
Database trivia
TODO
- SQL vs No-sql
- B-tree vs LSM-tree
Concurrency trivia
TODO
- Semaphore vs guard vs … all the concurrency structures
- CAS and lock-free systems
[Mid+] Systems trivia
TODO
- Bugs with reader-replicated systems and how to avoid them
- Consistency, RAFT, 2PC
- Batching vs streaming
- Metric collection and dashboarding (OLTP → warehouse → OLAP)
- Time series databases
- Trace logging
My own specific trivia
This is a redacted section. Sorry!
Redacted: I've chosen to make this section private. There is no way to access this part. 15 words.
Behaviourals
Behaviourals. Those parts of interviews where you get asked uncomfortable questions for half an hour, and the only answer you can think of is the time you told a passenger in a car to put on their seatbelt or else you aren’t driving, and you don’t really want to talk about it. For these, I break my stories into four major categories. Questions directly about you, team interactions, projects, and your knowledge of the company. I will explain broadly how to answer them, what these are, then write a large redacted section about my answers to them.
There’s an astounding amount of content based around “How do you answer a behavioural question?” and all types of acronyms to match it. STAR, STARR, STORY, TEEL, TEEK, NFLA (Nice Four Letter Acronym!). They’ll probably have some marking criteria for STAR and each section will have some grade. STAR - Situation, Task, Action, Result. What was the situation or problem and why was it important, what planning did you do and what were your options, what was the action you took, and what was the result? Alternatively, I also like STORY - Situation, Task, Obstacle, Resolution, You. What was the situation, what task did you decide to take, what obstacle did you encounter, how did you fix it, what was the impact on you or the company’s metrics? This type of storytelling mostly applies when you’re reflecting back on something.
Firstly, questions about you such as “Tell me about yourself”, “What was the last thing you worked on?”, “Why are you applying to this job?”, “What are your strengths and weaknesses?“. There aren’t that many interesting ones, so you have to become very good at them. The core one is introducing yourself. You need to give a history of the last 5 years or so, and also talk about what your responsibilities were. I won’t fully write mine here since it’s too specific to me, but it has something like this format: “My most recent role I worked at XYZ which is an ABC company, and I worked on IJK in the team. My role there is important because ASDF can happen if it goes wrong”. You should include what your role is, where it is (specify what they do if it isn’t a well-known company), what you specifically do (this needs me to know about…), and why what you do is important (if my system breaks it…). Again, because there aren’t that many questions specifically about you, you should become very good at saying your answers to all of them.
For team interactions, if you go open some Youtuber’s guide to behaviourals Dan Croitor, you’ll see an outstanding amount of information about following leadership principles and just quite a lot of content. If you look at most companies’ questions, they’re very similar to Amazon’s, so you can just prep for that. However, that’s a lot. Really what you need is a toolkit of answers that you can twist into any question. I break this into four categories. Crises, disagreements, innovations, mistakes.
In a crisis, you have some unexpected event, why it’s important, how you reacted to it, how that went, what changed in the team because of it, and how you wish it went or what you learned. For disagreements, it’s a conversation about something that matters with coworkers. This can both be you having a problem with them, or them having a problem with you. You need to talk about why the problem is important, how you tried to get them on your side, and the eventual resolution. For innovations, it needs to be something the company would not have if you were not there. You have to be the one who suggested doing it, and you have to be able to say why it was impactful in the end or at least what you learned about it. For mistakes, you need a time when you blatantly made some large mistake and either you learned from it, or a process changed.
I recommend having in the range of 4 - 6 stories for each topic of team interaction stories. You should have a story for almost every outcome direction. One where you ‘won’ an argument, one where you ‘lost’, one where it turns out it didn’t really matter at all.
For projects, it can be a bit tricky for what they want. The table I usually refer to is from Cracking the Coding Interview for the idea of it.
However, it depends. That table above is really just for brainstorming ideas about stories. Sometimes an interviewer asks you to go into depth on the last thing you worked on or did, and they want to talk about it for the full hour. You should clarify that’s what they want early on, then start from the very beginning. It’s basically just STAR repeatedly, but you need to intermittently pause and ask, “Does that make sense?”, or ask if they have any questions between sections. Think about delivering a feature end-to-end. Finding the problem alone is a story, then writing out the technical design is another, implementing it is another, the initial deployment is another, convincing teams to use it is another, the first phase of maintenance is a few, and the long term maturing of the project is another.
You should know these project stories end-to-end for everything on your resume. It would be quite weird if you didn’t know. At the same time, you wouldn’t really expect an intern to have a deep trove of experiences to pull from. But you should have at least 1-2 projects that you can talk about for 15 minutes or so if you are one.
Knowledge of the company isn’t that hard, but it’s easy to get caught out on. You should know these for recruiter screening questions. Memorise their “values”, read any news about the company in the last two weeks, and read the job listing. You should practice answering questions about their values, and practice saying your understanding of the job listing. For your job-listing answer, you need to link it back to your skills. “This is a mid-level job for a Kubernetes team, and I saw on the senior-level job listing that you’re looking for XYZ, which I worked on at ABC”. Bonus points here if you go read ALL job listings for the team, not just the one you’re applying for. It can give more hints about what they want.
So, in summary, I recommend writing then retelling all your stories several times. These stories are:
- Have thorough, deep answers for “about you questions”. You should practice saying each one at least 5 times. These are, “Tell me about yourself”, “Why are you applying to this job?”, “What are your strengths and weaknesses?”, “Why did you get XYZ grade?” (i.e. a conflict-generating question).
- For team interactions, answer with STAR or STORY (situation, task, obstacle, resolution, you). Have 5 - 6 stories for each of crises, disagreements, innovations, and mistakes.
- For projects, practice recounting them ~3 times or so. You should know every stage of the project and be able to answer any obvious questions along the way. If you’re a mid-level, you should be able to fill a full hour with one of these stories.
- In job-specific questions, memorise their values, read recent news, and read the job listings.
Yes, you already know these stories. Can you tell them confidently to a room of five people, without stuttering, and being easy to understand? Can you then answer questions you haven’t heard before about those stories, without pausing and thinking? Can you repeat the same story multiple times without any inconsistencies - if you can’t, that would be lying! Behavioural interviews are important, and are very dependent on repetitive practice of talking or writing.
My behavioural answers
Redacted: I've chosen to make this section private. There is no way to access this part. 4 words.
System design Lite
I still need a surface level understanding of system design, and need to walk through components I’ve worked on. A large chunk of this is just going to be in the trivia section. However, I’ll practice drawing the diagrams for my previous systems and the key facts about things I’ve work on before on here.
Redacted: I've chosen to make this section private. There is no way to access this part. 0 words.
My first round of applications
I haven’t done this yet, but there are ~5 companies I’m quite interested in within our region. I suspect I don’t need that much system design for these, and most of them don’t really negotiate! If I fail all of these, I need to go dive into system design.
Redacted: I've chosen to make this section private. There is no way to access this part. 4 words.
System design Dive
Go read https://www.hellointerview.com/ ! Even when I do get down to this section, there’s going to be too much content for me to write about it here.
Conclusion
This article isn’t done yet!