I spent about 3-4 months preparing, and I kept prep and applying separate instead of doing both at once. In the end I interviewed with 13 companies and got offers from 5 of them. Most were startups, with a few big multinationals in the mix.
What worked best for me was starting with the problems that come up most often, for both DSA and design. For DSA I went through a popular 150-problem list, and for the topics where I felt shaky I used some topic-by-topic video playlists. I never sat through a whole video. I would watch just long enough to understand the problem, try it on my own, and only if I got stuck keep watching and then code the solution myself. When I did solve something alone, I still watched the rest to see how the best solution was reached and whether there was a different approach from mine.
Most of my system design interviews were about building a product and digging into internals, but one of them completely flattened me. It was an infra design question, asked by LinkedIn (I wrote about it on LeetCode): design a distributed denylist. It was a real challenge. I knew the concepts, yet none of them came to mind during the interview. Afterwards I read up on how infra components are designed, like HDFS, Chubby, Kafka and DynamoDB. Just studying Dynamo and Kafka taught me a lot about how distributed systems are built.
I also found a senior on my team to hold design discussions with. We picked a system, broke it down and built it up from scratch with scale in mind. Later the same week we ran a discussion set up like a real system design interview. We only agreed on the topic beforehand, not on any reading material. It turned out to be very fruitful, and since he was an SDE 3, he helped me get to even leaner and simpler designs.
For Nielsen, the machine coding round was the most intense one. We went into real detail on the framework I used (SpringBoot) and on Java 21 features.
My takeaway is that so much depends on the interviewer, and I can't count on getting a good one. All I can do is practice, so that is what I did. I met all kinds of interviewers. Some paid real attention as I worked through a problem. Some pasted a LeetCode Hard statement, went on mute, and came back 20 minutes later to ask me to "run the code on all tests" and look at the result. Others handed me nothing but a sample input and output and wanted me to "guess" what the question was. There is nothing I can do about that. The only thing in my hands is what I can actually control.
One more thing worth mentioning: grinding lots of frequently asked problems really paid off, because in most interviews I got those same problems exactly as they are, with no tweaks. Maybe you can try the same.
I also leaned heavily on Claude and Codex (through my company's subscription) for learning, both for problem solving and for system design. I built skills for each and tuned them for a very interview-specific mode. I was interviewing for mid-level roles, but in the system design skill I told it to treat the session as a staff-level interview. For DSA, the instruction was that I had to describe the problem to an interviewer pretending not to understand anything, and without mentioning code. That helped me a lot.
Discussion
Loading comments…