I leetcode until my eyes bleed and I can't think anymore. I forget almost everything I know about building software and instead focus on memorizing tricks and optimizations and processes for solving leetcode algorithm questions. In my last interview, in an automated screener, they had 7 leetcode easy+mediums in 10 minutes each, with zero partial credit, only final tests passing. That's what companies want now, so that's what I have to deliver - I don't have a fucking choice.

I look over system designs, try to understand what the core aspect is. For the most part I tend to pass those without as much of a problem.

Nothing works best, but doing this has gotten me further than actually practicing and writing code. I have 8 YoE, took a career break on short term disability for burnout/early childhood horrors that I needed to deal with. Its 2 years later, I'm able to code again and am picking up things much faster than ever, but I'm about to lose my apartment and move into a friends basement because a career break is, apparently, career suicide right now, and even contract companies won't even interview me because of the career break. I was getting cold recruited by FAANG before. I just want the opportunity to work so I can have stable housing, and I'm doing everything I can. It gets harder and harder to practice. I consider whether my career was a sham all along often. I don't really care that this is venting, there's nobody to talk to about it.

yes, I prep. For me the biggest thing was writing code quickly. I went from taking ten to fifteen minutes for solving the easier leetcode problems to five minutes.

The confidence to bang out code that fast means I have more time to think. I definitely can't memorize questions, so it's much easier for me to just practice the problem solving aspect along with the very very fast coding aspect.

For system design, I did no prep other than mock interviews to just verify I was on track. Prepping for system design by reading about systems other people have designed to me just comes off as shallow.

I also did lots of practice/mock interviews to just get used to explaining things as I coded. That was very helpful. Sometimes the questions are easy but they are looking for thoughtful people, not just memorizers.

Isn’t this leetcode system and multiple interviews limited to mostly the US?

I don’t see it that much in other parts of the world (many of which with more job security).

I actually had Grok throw a bunch of practice interview questions at me.

Always. Every interview exists to narrow down the applicant pool. Unless it's an automated interview, I would rather stay unemployed than take one of those.

The prep depends on the interview type. Most fall into 3 categories.

1. Algorithms - I remember a better time in life when I had the luxury to wait until I had an interview scheduled and only then would I have the motivation to grind. I'm now grinding everyday since it takes time to make meaningful improvements. Although a part of me enjoys these type of questions, it does make me question my career choice. I guess the one silver lining is that I'm getting much better at solving these questions than when I was employed.

2. System design - For this type of interview I've found that it's all about your ability to guess what type of system they'll want you to build and what parts they'll be interested in focusing on.

3. Behavioural - This actually requires the most company specific preparation. Refining your behavioural stories to match what the company is looking for and with who you're interviewing with (i.e Recruiter or C-suite level). Thinking of meaningful questions to ask. Practicing mock interviews. It all takes time.

I have a list of technical questions I tend to stumble over. Things like SSL pinning, cache management, CI/CD, github stuff, and DI. Often things that colleagues have set up 3 years ago and are now just a function call on Slack.

Every interview will ask the same questions: "Tell me something about yourself. Why would you leave such an awesome job? Are you willing to take a pay cut for equity? Why do we need you instead of paying a junior and giving them AI? How do you practice Agile in your workplace? How would you train a junior? How much are you being paid now? How do you feel about trans people and dogs?"

Some of these are traps. The only wrong answer is sounding defensive or evasive. So it's important to practice taking these head on.

I find that if you nail the first interview with the decision maker(s), you will get the job. You can fail the interview but they'll even give you another one because they see it as some kind of error. If you excel at the technical interview and don't pass the vibe check, they'll find a reason to reject you. Then they'll pick at the number of past jobs you held (too many or too few), resume gaps, 'culture fit', etc. And if they absolutely find nothing to reject you for, you'll get rejected for being overqualified.

Also it's important to interview for the role you're applying for, not the one you hold. For me, it's a shift – founding engineer/staff+/TL/EM/CTO at this point. The IC roles aren't being evaluated from an IC angle. They're being evaluated from an angle of whether I can lead product next year once the company has raised $100m.

They don't know anything about you. They don't know that I used to spend my teenage years as a kind of PM making games with strangers over the internet. The unwritten question I have to answer by the end of the interviews is, "Can this engineering degree nerd from a developing Muslim majority country lead a team of white people who went to MIT?"

Since I'm not participating in leet code style interviews, no not really. Most interviews just develop into a conversation and I'm comfortable having conversations about technology and systems and methodology without prep. Any prep I do would be to learn more about the folks in the interview loop rather than brushing up on any particular topics. I don't think this is good general advice, especially for positions where you're still primarily hands on code, but has worked quite well for me.

It's also very helpful to not be applying via public HR processes. Warm intros to specific teams / leadership makes everything so much easier. Pay attention to where former teammates / leaders are moving to. They can make excellent leads to new opportunities assuming they would be happy to work with you again.

Usually for screenings i will do a notion page i can glance over in the interview that contains the following

- who are you (introduction)

- how i fit the role (experience, projects, etc)

- occasionally some moments when I showed x,y,z (STAR) if they ask something behavioral or to add to the conversation if things go quiet

- questions. Make 2-3 sharp questions that make them uncomfortable (ej. Why engineers leave this company, how do i compare with other candidates and the one you are looking for, if a client had infinite budget, would they choose your competitor instead of you?) Or elses. If they respond honestly good, if not, redflag.

The more interested in the job, the most time I'll devote here. If it's meh job I will take 30 minutes to do all this before the meeting.

Hope this helps.