I really enjoyed this article. It's probably one of the most fair, unbiased, and insightful articles written on tech interviews and may be the best one I've rea

I really enjoyed this article. It's probably one of the most fair, unbiased, and insightful articles written on tech interviews and may be the best one I've read. Over the past 15 years, I have interviewed with many different companies. I once read that when you're a good fit for the company, the interview will feel suspiciously easy. This has been the case for all the times I've gotten offers. Reading this article, a lot of the good points remind me of a particular interview I had though. It was at relatively large tier-2 tech firm a few years ago (not the FAANG tier); one where I didn't get an offer, but the interview process and experience was memorably good. I remember specifically telling the recruiter even after the rejection that I really enjoyed the interview there. One of the rounds was with the principal engineer at the company, who was the most senior engineer at the company at the time if I recall correctly. It was the system architecture interview. I was asked to prepare by thinking of a system I had designed and architected in my past experience, and present it as if the principal engineer was my coworker and we would hold tech discussions. It's the closest thing I've ever gotten to the "Present code they wrote" idea that Andrew mentions here. For the coding round of this interview, I was asked to bring my own laptop (another point that Andrew mentioned here; this was also the only company of all the interviews I've had in 15 years that asked me to do this.). I was then given a problem at the beginning of that interview, and given 45 minutes or so to write code on my own (the interviewer actually walked out of the room and left me alone while I did). It was a reasonable problem to code for the allotted time, and had reasonable complexity but not overly difficult. When time's up, the interview came back and we discussed my code. Both of those rounds were something that was so well done that I think it was the most fair way a company could have assessed me correctly. I did well on the coding round, but my experience in system architecture was not a good match for the type of work they did, and in retrospect I could tell. Since I was interviewing at the Staff Engineer level, I think they correctly evaluated me and turned me down for the role. (Although I would point out that after that day of interview, they ended up being undecided, and asked me to come back one more time to have one more interview round, with one of the first engineers of the company there. I did poorly in that round for a variety of reasons, and that was ultimately what got me the rejection.)