I just finished a job search. Some of my own notes: Preparing a resume: I just updated my linkedin profile and exported that into a pdf using the tool they pro

I just finished a job search. Some of my own notes: Preparing a resume: I just updated my linkedin profile and exported that into a pdf using the tool they provide. I think this is perfectly fine. I only ended up sending the actual pdf to one company (Stripe) and I get the sense it was just a formality. Scheduling: This really tripped me up actually. I didn't plan it very well and I ended up asking a company where I had already completed the interviews to slow roll making an offer because I had other interviews scheduled and didn't want to turn down their offer just because I hadn't finished all the interviews I wanted to do yet. This kind of sucks because it's super stressful, but I think it really is best to try to schedule it so that you do all the final interviews you want to do all in the same week or maybe two. I think this is really the main reason to narrow down the search to a small number of companies (like less than 5). There are only so many interviews you can do in this time frame. Algorithm interview: I did not get any hard questions in these this time around; they were all of the screening question variety, like Leetcode's "easy" (or perhaps easier), where if you know how to write basic code, they really don't require any preparation. Design interview: I didn't prepare for these because I actually do architectural design at work fairly often (as opposed to the weird little bottle coding problems in interviews, which I don't ever do). I was a little disappointed at how I did in these; it turns out that talking through this under time pressure is not the same as doing it for real, and I often wasn't actually quite sure what to draw in the boxes they want you to draw, because that isn't really part of my real process at work. But I guess these went fine because I didn't get turned down for anything because of this. But I may prepare more next time. Something not covered in the article, but which I want to mention: The styles of interviews listed here are not the only possible ones! My new all-time favorite interview I have done was at Stripe. Using my own language of choice and my own tools (ie. my IDE), they dropped me into a fairly large codebase (which looked like it was adapted from an open source project for the purpose of this interview) with a failing test case and asked me to figure out the bug and fix it. This was really really fun and very illustrative of the kind of thing I do at work pretty much every day. I had another interview with a similar sort of question except it was in the realm of operations. It wasn't quite as great because it was a bit more contrived, but I still really enjoyed it. The contrivance was: you are new and our sysadmin is on vacation with phone service but no internet, we start getting reports that people aren't seeing anything when they go to our website, you are on the phone with the sys admin and your job is to ask questions to get to the bottom of what's going on. This seemed like a hard kind of interview for the interviewer to do, but it was really fun for me. Stripe also did a "system integration" interview, which was like one of the take-homes mentioned in the article, but was live-coding on screen share. I had to use an unfamiliar json library and an unfamiliar http library and interact with a couple unfamiliar API endpoints and get it all to work together. This went ok, but it was a lot of moving pieces for a one hour live interview, and I think it would have been better as a take-home with a two-hour or so time box. I will say that I was pleasantly surprised that a lot of people seem to have started moving somewhat away from the esoteric CS-y data structure and algorithm interviews that I think most of us despise.