There's no "correct" interview because each company is filling a different role for a different culture. In the past I've done the following and it's worked, an

There's no "correct" interview because each company is filling a different role for a different culture. In the past I've done the following and it's worked, and is working, pretty well for the types of roles and cultures I was filling for. 1a. Optional coding test at home (no time limit) 1b. Optional coding test in front of me (1hr time limit) 2. Very simple fizzbuzz-level problem. Essentially can you break down a problem with an if statement and while loop. This has the least bearing on the process. 3. System architecture/design "whiteboard". We ask a question that's essentially an entirely different problem space from out company but who's end system design, and lifecycle, looks almost exactly as the design our company took. Essentially if you `s/A/B/g` you'll have a 1:1 idea of what our company's infrastructure looks like by the end of the problem. There are absolutely no wrong answers, just answer how you would if you were given this ticket ("design X") and I'll ask from time to time "how many QPS can this handle", "any bottlenecks you can identify", "how much bandwidth/cpu/memory will this take", etc to see if they understand the implications of their decisions. Surprising facts: 1. Most people can do the take home coding test "enough" but do horribly on the on the phone coding test. This has been shocking to me because I'm not someone who struggles with this aspect of the interview process (I'm horrible at explaining myself). 2. When we get into the system arch/design session 99% of people have no idea how to proceed. They've never sketched out the design for something in front of someone else and have often never thought about latency, memory, CPU, disk, etc. We had one engineer take it who couldn't even come up with a way to estimate how many QPS a service might receive in the worst case. Another engineer settled on a design that was going to cost >$1mill/month in AWS DB costs and could not imagine any way to reduce this bill and thought this was reasonable (just needed to put a cache node at an edge location). 3. People use buzz words. They use them a lot. If I had a working feature for every time I've heard someone just say "autoscale it" whenever they hit a bottleneck during the arch/design section I wouldn't need to hire an engineers. It shows a core lack of understanding of where the bottlenecks in our interview question are coming from. 4. We see some (small) percentage give up on doing the coding test. I'd say it's less than 10% of inbound leads. Obviously a significant portion of people don't want to code in front of someone and don't want to code at home. Unfortunately I can't advocate for hiring someone until I see code that they've written. We've had horrible experiences hiring "senior" engineers who actually don't know how to program. 5. I've had people freak out, and start cursing at me, when we get to an interview question they get stuck on. It's something I'd never have imagined happening in a professional setting but, at least, they've been filtered and won't be working with me in the future! 6. Resumes and pedigree have the worst correlation to quality of the engineer I've ever seen. I've seen undergrads working part time in the summer output 10x value to full time engineers with 5+ years of experience. "10 years of experience or 1 year 10 times" is the most accurate pattern to describe this.