Things I Learned from a Job Hunt for a Senior Engineering Role
Just to add to this a couple days late..<p>All this focus on coding in interviews is actually completely misplaced. Early in my career I had no problem writing anything you asked, but reading other people's code, and having a deep understanding was something completely different.<p>Now 25 years later, I can still code, and given greenfield development, or just larger pieces of work that by itself is somewhat isolated, I can make features appear in a shocking short time. Similarly debugging my own code, even once its reached into the hundreds of thousands of lines is usually better done by thinking about what in the code base would case the given behavior.<p>OTOH, the skill that really matters is the ability to debug problems in a code base written by a team I wasn't originally part of. That is still really hard, I'm fairly reasonable at it, but it probably takes me longer to understand someone else's code that it would have taken me to write it.<p>This also means my bug fixes tend to take a few days if the bug is in an unfamiliar piece of code. But, it also means that I can usually come up with a fairly trivial fix (frequently just a couple lines of code). Vs a lot of code reviews i've been on (which is similarly hard piece of software engineering) where there is a ton of noise and some 1/2 fix that fixes a particular case but fails to solve the general problem.<p>All that was a long winded way of saying that I suspect that software engineering is in levels, there is the first level where you learn to code, and there is the second level where you learn to understand all the different ways other people code, and then there is the third, where you can analyze the latter alongside a problem to determine not only does the solution solve the problem, but is it covering all the edge cases. A 10x programmer is frequently someone who avoids the second case, and fakes the third case by only reviewing code which touches subsystems they wrote. Interviewing solely for coding skills rather than coding skills + ones ability to read analyze other people's code is missing the most important and hardest part of quality software engineering.