Around 2014 the number of programmers was doubling about every five years. On average, therefore, half of all programmers has five or fewer years of experience. Yet some companies would promote them to senior positions, because on some teams the rest of the programmers had even less experience. It’s understandable, then, that the technical interview shifted from discovering how much a candidate knew to simply trying to find out if given programmer could even write code and use basic algorithms and data structures.
Have you ever heard of candidates for a software engineering post being selected for their ability to document their code?
Why am I reading and working my way through this book, when I find no evidence that these kinds of tests are effective ways to screen candidates? I’ve concluded that while my ideal is to refuse them and avoid interviewing at employers that require them, I believe that doing well on one is not difficult, just time-consuming.
My goal is to improve my performance in the coding interview, not necessarily to learn the stuff in the book for use on the job. My next step in my career would be Staff Engineer, so if I can progress through this, I’m pretty sure I can get there.
As a Staff+, I expect to be able continue as an individual contributor, but do more interesting work that is suitable to my experience and ability. I have no illusions that reading or working through this book will improve my actual job performance, because ability to clear the coding interview hurdle has not been shown to correlate with working skills. Relevant work samples are the best indicators of skill; new skills learned just to pass an interview step do not represent relevant work.
The Wild Fox Den 