After 3 months and tons of rejections, I finally received some offers
Posted by FrickinSilly@reddit | ExperiencedDevs | View on Reddit | 69 comments
Hey all!
Senior (now Staff!) Developer of 11 years here. I just went through a grueling three months of interviews. The first 2 months were filled with rejections, and yet once I realized how to interview in these dark times, I turned it around and just had 4 offers to choose from.
There's soooo much good content out there but it's spread out and there's so many little practical details throughout the process that aren't captured anywhere that to me were the difference makers. I decided to compile all these tips into a semi-organized format and share them with others.
It's definitely rough around the edges, but I want to be clear that I'm not selling anything. There's no ads, no affiliate links, and not even a buy me a coffee button. I just want to help others if I can. Industry hiring is fucked right now.
I'm simply hosting it on vercel for free right now: https://sys-design-interview-website.vercel.app/
If you don't want to click on that, here's my best tips right now (and they may sound dumb or straightforward, but they are seriously the most impactful once you're comfortable with system design and coding):
- If you have the luxury of choosing a language, go with python. Seriously. Every single interview is ready for python developers. I had some exp with python, but was way more comfortable with Java. Not only is Java more verbose, but I'd say more than half of all coding rounds had me manually transpiling code and sample test data from python to java wasting anywhere from 5-15 minutes. Most companies use Python now and even ones that say "any language will do" usually prep their coderpad in Python. If you're just starting out on your interview prep journey, USE PYTHON.
- For System Design, get drawing as soon as possible. Yes, you need to cover your bases, ask a few clarifying questions and narrow down the top 2-4 functional reqs and questions about scaling. Just don't spend forever on it, and modeling data, and API design. They want a fully working system that handles all functional requirements first, and a drawing is how you illustrate that. If you're not getting to drawing until the halfway mark of the interview, you're already way behind.
- On that note: "We'll come back to that if there's time" is a godsend. By all means verbalize the API endoints and DB choices, but don't write them all down. If you think there's somtehing to deep dive there, mention that you'll come back to that and move on! Get your full workflow solution out first.
- Last tip I'll leave you with is to make sure you're hitting some advanced concept (preferably somethign covered in DDIA like Isolation levels, idempotency/deduping, consistency, sync/async) when discussing a past project. I can't tell you enough how many nods and notes I saw written as soon as I mentioned how "one challenge was ensuring the client had response feedback sooner, so I made the processing step asynchronous using a kafka feed with idempotency key for essentially once semantics".
Hope this guide helps, and please add suggestions if you have any!
Sfpkt@reddit
Thank you so much for putting this together. As someone who finds themself on the job market yet again I will definitely be using this resource.
sleeplessinbayarea@reddit
I have interestingly heard the opposite. I tend to converge on a design really fast assuming high scale and other resource constraints but have been told that the assumptions were not thought out clearly. As if they almost want me to just state the right answer after discussing a few wrong ones.
This is separate from pros and cons balancing for choosing one design over the other.
FrickinSilly@reddit (OP)
Yes, my advice directly relates to hellointerview's approach which suggests a lengthy prep workflow before getting to drawing. It is NOT intended to suggest drawing right away. I usually don't get to drawing until about 10 minutes in (whereas with all of the reqs, models, api design, etc. that hello interview suggests, I was only getting to drawing at the 25-30 minute mark of the interview).
You still need to clarify assumptions! In the guide I make a few suggestions on questions to ask. Since they typically ask about a system that is well known, you want to verify what features we care about and don't. For instance, designing twitter? They likely want posting a tweet, reading a tweet, and getting a feed. I would clarify that the following are below the line (note that they aren't always!): auth/identity, likes, retweets, fancy feed sorting algorithms, ads, etc.
Typically, I just mention that I assume those are below the line, and explicitly ask if those assumptions are correct.
For non-func reqs, the biggest questions you MUST ask are:
This should ALL take less than 4-6 minutes.
martabakTelor6250@reddit
Thank you!
tndrthrowy@reddit
“We'll come back to that if there's time" is what I finally realized I needed after several failed interview loops where the interviewer wanted to go deep into some minor topic during the system design question. You really have to take control of the discussion rather than act like you’re collaborating with a peer, which is how I naturally approach system design. Think of it as giving a presentation and being interrupted by an eager junior dev.
bizcs@reddit
That to me indicates that you're dealing with inexperienced interviewers, and possibly earlier-career people more generally. Disrupting the candidate to go on some side-quest about mundane implementation details is at least rude, bordering on incompetent as an interviewer. You can't say "you're gonna do this thing in this time-boxed environment and it's pass/fail!" and then turn around and disrupt someone performing the task. Take a note, and ask about it when they're done with the core thing.
That to me sounds amateurish.
GlobalCurry@reddit
Perhaps they're doing on purpose to test how the interviewee handles it.
bizcs@reddit
Perhaps, though I would maintain my assertion that this is a bad practice on the part of the hiring panel. At the end of the day, they're disrupting the flow of the interview and potentially losing out on information that would help them make an informed decision about hiring. Many people self-proclaim that they do poorly at test-taking, and interviewing is at least similar if not equivalent to taking a test. I posed the following question to Google Gemini:
It came back "confirming" (to the extent that a model with a web search tool can truly do that) that I've got the range approximately correct. Let's just suppose it's 33% and that test anxiety is distributed perfectly randomly. If that's true, then interrupting people in is going to disrupt one in three candidates that are unlikely to handle it well. I would personally estimate that it's closer to 3/5 than it is 1/3.
It's entirely possible that people are intentional about this, and have well-reasoned answers for what they're expecting to see, but I'm skeptical about how frequently that's true. I'm open to the fact that I could be wrong, but I'd like to be convinced (with evidence) that interrupting candidates yields anything useful. I could be mistaken about the number, but I would expect at least 75–95% of people experience performance anxiety over interviewing (for a multitude of reasons), and injecting a side-quest into the process seems like a mistake to me.
FrickinSilly@reddit (OP)
In my experience (and as someone who was an interviewer at both big and medium tech), most of the interviewers I encountered were not good. Especially for system design. Sometimes you would go into a whole explanation about why you would choose a certain technology (like CDC for ensuring no dropping of messages after DB writes and before kafka writes, being sure to mention how CDC solves that). Only for interviewers to ask you a few minutes later "how do you solve for faults between writing to the db and sending a message?
It felt very "but why male models"?
I also encountered a lot of interviewers that couldn't think outside the confines of the textbook solution they followed as an answer key. Like, I would bring up using a warehouse store like BQ or Snowflake and how it could solve certain aspects of the problem, and they didn't know a thing about warehouse stores (I would confirm later on after the interview through online solutions that those were indeed valid solutions).
brick_is_red@reddit
This is one of the weird things about system design interviews. They seem to come in two flavors:
a. A real problem the business has solved, or
b. A problem out of a textbook that has nothing to do with the business.
In the case of A, the expectation is that you’ll arrive to the same conclusions as the business did. If you don’t, that’s a black mark. This is hard to do, because the business usually spent many dev hours thinking about the problem, possibly trying and failing with different things.
In the case of B, the person only knows “the answer” because they read a Notion doc before the interview about what to look for.
I’d choose A over B every day, but it still requires an interviewer who can collaborate with the candidate.
GlobalCurry@reddit
Something I like to do if there is time is flip the script and ask the interviewer if there is anything they would differently. A few times they've come back shocked I asked without an answer or just told me they would do it how I did it.
tndrthrowy@reddit
This is my experience with senior and staff engineers at multiple FAANGs. They’re just doing a fairly natural conversational approach which they might do when talking to a colleague. They don’t realize is distracting from the task at hand, which is really a presentation, not a brain storm.
And yes it’s amateurish, but that’s because even at high levels, most engineers are amateur interviewers at best.
SansSariph@reddit
I found myself confused reading this. Totally on board with your first comment, but it's not at odds with a collaborative or conversational approach.
I have zero interest in being given a presentation by an interviewee, and I am watching the clock as we go. If we don't complete a full design because I was asking questions, it's not like I'm writing "no hire - did not complete assignment", because getting to the end isn't the point if that's my approach.
Did you receive feedback in those other loops that the time was a deciding factor?
commonsearchterm@reddit
Are you new to being interviewed?
All the interviewers suck
bizcs@reddit
I have, at this point, spent much more time interviewing than being interviewed. I have considered going through a couple loops just to see what it's like in 2026, but it's been a very hot minute for me.
karmaboy20@reddit
[ Removed by Reddit ]
FrickinSilly@reddit (OP)
10000000%
And it's so annoying that you can dive super deep into a topic that the interviewer asked about. Like so deep that even many seniors i know would learn something new, and then you're docked for doing so.
The whole process is frustrating. That's why I stress to finish the main functionality and come back to deep dives later. One thing I differ on with hellointerview is to not leave the naive solution as is until deep dives. Definitely discuss it, but I go straight to the more optimal choice (as long as that was discussed as a func/non-functional requirement!!!)
LateGameMachines@reddit
It feels every posting is completely saturated more than ever. Some of the design prep tips are helpful. Though even with the LLM rotation tip and a custom resume builder per role, I’ve only got 2 screenings in 5 months, including director referrals. LLMs say the resume is in top percentile as well. It’s not looking great, so I might just have to call it soon if nothing’s getting through.
FrickinSilly@reddit (OP)
What's your experience? Are you sure you are applying for the right roles at the right level? Are you prompting the LLMs to be hypercritical? I'm not sure I would trust an LLM's judgment of percentiles. Also, resumes are judged relative to the role and level.
LateGameMachines@reddit
5 YOE, so on that cusp of the paradoxical 3 year or 5 year minimum. I have a central organized stashed pages of notes, metrics, and bulleted facts that I get multiple LLMs to use and review critically multiple times while constrained on a specific role's description, and so most are narrowly targeted for high performance, not just generic FE/BE/Full Stack work. I won't stop applying, but on a sustainment level, I'm having more luck building businesses or a hedge fund than the classic SWE career route. It seems hiring pressure at this level seems to coincide with the added layoffs + bond yields pushing corporate direction for AI workable teams or principles for stronger stakeholder insurance. I honestly don't know what more leverage would be needed in the technical aspect except years + connections.
PhaseStreet9860@reddit
Which country is this ?
FrickinSilly@reddit (OP)
Canada, but mostly American companies that have satellite offices here or are fully remote. I interviewed with a few European companies too and I didn't see much difference.
ubccompscistudent@reddit
Canada, but a lot of American companies with remote or satellite offices in my city.
superide@reddit
One critique on the STAR guide: the Result section begins with an assumption. It assumes that all jobs track metrics. But that's probably more of a quality of STAR itself rather than your guide. In most jobs the only thing I can count is the number of tickets I closed. I think this part of STAR is a headache for the people who only needed to care about shipping feature work with zero follow-up, as getting numbers is almost like pulling teeth in those cases.
FrickinSilly@reddit (OP)
This is a HUGE problem. I worked on a lot of internal tooling teams where there's no "dollar" impact. What was the result? I built the feature. It worked.
And interviewers prefer two things: metrics that you measured, and dollar amounts. If you can find a way to twist would you made into one of those (or both) results, you will edge out those that can't or don't.
Fortunately, you can come up with metrics. It just takes some creative brainstorming. While we should be doing this for the projects themselves, sometimes out team doesn't. I think it's fine to talk about the metrics that "could have been" in your interviews as metrics you used. It's a bit in the grey-zone, but I would still think it's the mark of a good engineer to reflect on metrics they could have added and would add to future projects.
For example, I talked about a metric for a greenfield tool that I built, which was "number of voluntary adoptions" that we measured. Honestly, this is where an LLM shines in helping you uncover some of these hidden metrics you could talk about.
superide@reddit
Thanks for the feedback. No big knock on your guide, for my needs I find it bookmark-worthy. The metrics thing just always bothered me because it seems just cargo culty being passed down without much pushback.
It's also got the feeling of, if everyone took this advice, it becomes mostly worthless, because I don't think interviewers are actually comparing it against some controlled baseline. Because you can't. It's not apples to apples if metrics are used as a possible tiebreaker on who will move ahead to an interview and who doesn't. It might be useful for a follow-up topic on a tech round though.
Some metrics I have done with benchmarking, but none of it is really any dollar impact as you surmised. Best I usually get that hits closer to the bottom line is that customer experience might be improved because I made the UI more snappy, though we don't really measure retention based on that.
FrickinSilly@reddit (OP)
Honestly, I'd be VERY happy as an interviewer if you were to answer something like:
"We were a scrappy team with limited development resources and headcount. We often built things that had lots of qualitative user feedback, or because decisions were top down at the company. As a result, we didn't have the capacity to create metrics to measure outcomes.
That being said, if I were to have the capacity, here are the metrics I would have measured:
grimsleeper@reddit
Twisting is an important part. Nobody is calling your old boss to see if they have a chart of ops/sec on your kafka topic. Its all on if you as the person being interviewed can convince them that what you did had a meaningful result and you sound like you know what are talking about. Don't lie, but do spend time to look at what you can turn from "Made 2x faster" to "Cut pipeline latency in half which unblocked the data ops team delivery of live metrics"
TraditionalClick992@reddit
I hate to say it but just make up the numbers, they can't check.
johndoe1942@reddit
Congrats OP, good to see a positive story and appreciate the tips shared! Can you share some details about your background and companies you aimed for?
Also some comments on prep plan, how you balanced time between FT job and prep, how you balanced time between prep and job application, it would be super helpful.
Thanks!
FrickinSilly@reddit (OP)
I'd say for the first week or two, I was fully prepping. two hours a day on neetcode (where I was rustiest) and 1 hour on system design. I started to get interviews (recruiter calls) fairly soon after switching linkedin to "open to work" (but not with the banner, as I have some negative thoughts on that).
At the 3-4 week mark I was doing ~3-4 interviews a day, so I barely practiced coding anymore and kept trying to study my gaps in system design interviews.
I should also mention:
I feel like if I can do it with that limited amount of time, anyone who is dedicated can find a way.
johndoe1942@reddit
Thanks, as a someone with young kids myself, I completely understand the limitations which is why I was curious. Happy to know you were able to turn around from layoff to new job fairly quickly in this market.
LinkedIn tip is useful thanks, and all the best in your new job!
MrGuam@reddit
Hi, not exactly the same situation, but if anyone’s looking to hire a backend engineer, I’ll be happy to fill that role. Currently in a constant rejection run that it’s starting to get to my spirits lol. Please hit me up!
FrickinSilly@reddit (OP)
I was pretty low in spirits two months ago. Keep learning from the failures and know that a lot of the time, you ARE good enough, but there's just 5 other individuals who are as well and the company has to choose 1 of them.
grimsleeper@reddit
100%.
1000 people applying for all 1000 jobs is 99.9% rejections. Its a marathon not a sprint.
Any_Sense_2263@reddit
I wouldn't say that every interview is in Python. I'm interviewed in JS/TS. My friend in Java, my other friend in ABAP.
You will be interviewed on the language you specialize in.
FrickinSilly@reddit (OP)
JS/TS is fine as well because it has a lot of shared properties with Python. Java is horrendous. I did the entire process in Java and I assure you it is a disadvantage to do so.
Any_Sense_2263@reddit
People who master Java prefer it.
cooking-chef-2000@reddit
This is awesome! What motivated you to continue to staff level? My terminal is senior, and I'm looking for that motivation to push to staff, but from all the stories I hear, it's more work as staff, and some times, the payout just isn't worth it for the additional stress.
Can you offer some thoughts to this?
FrickinSilly@reddit (OP)
I was like you, but after 3-5 years at senior you might start to get bored. Hoping it's not a crazy amount of stress more, but I wanted to keep growing.
Iz4e@reddit
I need to get past resume screening. Recruiters use to just come to me and it was never an issue. Now it’s a desert
FrickinSilly@reddit (OP)
Just added a new section/tab on that.
malln1nja@reddit
The good old early 2020s when I was able to get away with a plaintext resume.
friendlytotbot@reddit
Do you have any tips on getting more interviews? Most of mine are getting rejected or no response after applying. Moving to even a screening round is low for me at the moment.
FrickinSilly@reddit (OP)
Just added a new tab about ways to increase your chances of getting interviews!
FrickinSilly@reddit (OP)
Primary source should be network referrals. Reach out to old coworkers on linkedin if you can.
If you're cold applying, (sadly) enter your resume and the entire job description into an LLM and ask it to rewrite your resume for that posting.
I hate that this works to some degree. It's an AI arms race out there. Just don't lie about what you've done unless you truly believe you can fake til you make it (stretching truth is less unethical)
superide@reddit
I would agree on the network and it's something I failed on a lot. Looking back on my career, the only jobs I could get were the ones that don't get hundreds of replies in the first day that job was posted.
That rules me out for probably 90% of all jobs. Word of mouth has been the only way I got around it, but that only worked for a while so I need to go back to the hard cold approach. Using AI to tailor your resume for every job sounds interesting. I used to look at 1 unique resume for every single job application as tedious and unnecessary, but with AI it could actually be more doable.
bizcs@reddit
Using AI to get to the stage where you talk to a human is both a blessing and a curse. It's great that it's cheaper than ever to tailor your background to the posting. That truly is better for the candidate and the hiring team, because it's aligning what the candidate is communicating about themself with what the hiring team is ostensibly looking for (assuming they were thoughtful enough to communicate that via the job description).
The flip side is that every document that supports human communication is now contaminated by AI, in conjunction with the fact that AI has a clear preference-bias for AI-generated content over human-generated content, in conjunction with the fact that humans are now using AI to help sort and filter candidates.
I wish there was a way for us to ban AI from human systems. People using it as a personal assistant and productivity tool is great, and building systems faster (and potentially cheaper -- we'll see where token costs go over time). I have no interest in reading AI-generated emails, ad campaigns, social media post, or any of the rest of it.
_Tauseef@reddit
I read through almost all of your tips on the website. You really covered a lot of practical tips. Thank you for this.
How do you find an entry level job with just internship experience? I have been looking for remote FullStack (Backend focused) roles for weeks now. For most of them I never got a response back. Just a single AI interview which I failed due to anxiety.
Any advice for me and others at my stage would be much appreciated. Thanks a lot for the effort you put btw.
FrickinSilly@reddit (OP)
Unfortunately, I am so far removed from the Junior interview experience, and with the recent changes in the industry, I don't feel confident giving practical advice. Are you still in college/university? If you are, go to all the career fairs you can. Make sure to sign up for any practice session with companies that come visit the campus (Msft and facebook did that at my university and I got interviews that way).
Run your resume through an LLM and make sure its hitting all the right keywords that will likely get you filtered out if your missing. Prompt it like this "What are the biggest red flags on my resume, and what are the 10 keywords its missing?". Then get it to update your resume with those items fixed.
Also, read through a bunch of entry level role descriptions and see if there are commonalities that you're missing. At your stage of your career, lean heavily into personal projects. Build something using a skill you see coming up on every job description and publish it to github. A bit of AI assisted coding on it is fine, but make sure you understand what you're building and can talk about it in an interview!
Best of luck out there :)
Nikeshot@reddit
Do you recommend HelloInterview for coding as well besides system design? Im because I own “Beyond Cracking the coding interview”, which comes with an online platform as well.
FrickinSilly@reddit (OP)
HelloIntervew has some great LLD problems like design an elevator, parking lot, and inventory system, but if they have more DSA/leetcode style coding prep stuff, I did not touch it. Not to say I didn't have trust in it, but mainly because Neetcode was pretty complete in that regard.
I'm not familiar with the "Beyond" follow up to the original book, but I'm sure it's great. Unfortunately, I can't give advice about how it stacks up to other sources.
StephTheBot@reddit
Is DSA always a given?
FrickinSilly@reddit (OP)
Could you be more specific? Every coding problem I did required knowing how to use your typical DSs adeptly, and PQs come up a lot. They still ask about big O for space and time, so make sure you are comfortable with that.
Most coding problems weren't leetcode hards, but rather longer multipart coding questions that required you to put several smaller solutions together to solve. For example, create a map keyed by X (maybe a frequency/counts map), use that map to create a PQ to get top k elements, etc.
StephTheBot@reddit
Thank you. That’s the answer I was asking for.
Ok-Shower6174@reddit
The "no buy me a coffee button" is the real hero here. Congrats on surviving the gauntlet, this market is brutal.
vincit_omnia_verita@reddit
Nice
zck@reddit
I also like "do you want me to dig into this more?". That way, if they have any concerns about the solution, they'll probably let you know. If they're happy with handwaiving this part of the design, they'll tell you and you can move on. As you said, some people want deep dives on API endpoints and some don't. You can ask the interviewer what they do and don't care about.
TheLeoAnderson@reddit
Thank you for sharing that website for us for free. I am reading through it right now.
Zapurdead@reddit
Can you provide some more tips about when is "enough" to say "we'll come back to it"?
And do you get pushback from the interviewer?
Staff is obviously a higher level but I wonder if it's better to optimize for "delegating" the finer details until you hear otherwise.
bizcs@reddit
I've never sat on a panel a Staff Engineer specifically, so take what I'm going to say with a grain of salt, but I have sat on panels for similar levels.
As a rule of thumb, you should think of questions being altitude problems. Don't answer a system design question in terms of ultra-specific implementation details. Instead, frame what the constituent components of the system are (a database, a stateless API service that also serves the front-end, a messaging back-plane that can scale independently, etc.) and what your technology choices could or would be (e.g., PostgreSQL and RabbitMQ or some other choices). "At altitude", I know what all the high-level things are in your design, and we can dive into details on anything I wish to (or none of it if that's my preference). It leaves me room to ask questions about things like scaling, hosting, deployment strategy, testing, etc., and gives you time to prove why you're a great fit for the job.
Before you start trying to come up with a system design, you'll want to ask questions about scope and scale. You should be intentional about the true requirements are and making sure you're right-sizing both the build and operating cost for a system. Good examples are:
From there, you can start to answer the question. Once you have all those things in place, you can make real choices about whether something should be running in an EC2 instance with SQS or if you should be building on top of EKS/AKS or whatever. Those first questions would also be the ones required to ask follow-up questions about things like latency ("how fast does this response need to be?"), and you can incorporate into your answer how you will achieve it.
Ideally, you wrap painting the picture up within 20 minutes so we can spend the balance on any questions I have (behavioral or technical). When done well, you the candidate will have 10-20 minutes to ask me questions. For my loops, I generally aim for 75-90 minutes with a candidate. The general flow is something along the lines of:
If I get everything I'm looking for in the middle phase, I usually give the candidate the balance of the time. Sometimes I'll show them some of the things I think the team does well at so they'll have an idea of what kind of org they would be joining. If an interviewer ever does that, then congratulations: you almost certainly passed the interview.
Zapurdead@reddit
And also, in your opinion, what are the critical signals do you think interviewers are looking for? Is there a time in these high level interviews when you go "aha" I've probably passed
FrickinSilly@reddit (OP)
Honestly, the best signals you get are when the interviewer explicitly states you did well and covered all their questions. I was surprised how often that occurred (again, once I was actually executing at that level).
When I was facing rejections, I was seeing more confused faces and interviewers that were repeating questions. When they repeat questions, it usually means there is some signal they want and aren't getting.
more than half the time, the answer is likely that they're looking for a redis cache or a kafka feed.
Zapurdead@reddit
🤣thanks for the tips, that's gold
FrickinSilly@reddit (OP)
It's always a balance that you have to gauge by reading your interview a little bit. They'll usually either say "can we cover that now?" or "that's fine" when you say we can come back to that.
For a specific example, one thing I mention in my longer set of tips is to, at the bare minimum, cover the first few hellointerview system design problems. They not only cover a wide number of useful concepts in practice, but also are the most asked questions in real interviews. One of those is google docs/dropbox. It uses S3 and there's a part in there about how to upload files to S3 using a presigned URL. You could get into chunking, but I have been successful but simply drawing the basic presigned URL workflow and then mentioning about how we can chunk the file for better fault tolerance/pausing/resuming etc. but saying, I'll dig in deeper later if we need to.
Basically, cover the basics in detail, mention the deep dive, and then move on. It let's the interviewer know you know your stuff and can revisit to go deeper if needed, but doesn't have you over index on it at that point of the interview.
it_happened_lol@reddit
What was the TC for each of the offers? How many were hybrid vs. remote?
Candid-Cup4159@reddit
Congratulations 😑 Happy for you 😒
FrickinSilly@reddit (OP)
Thank you!
-Shush-@reddit
Congratz!