The following is the current version of the preface to my book on interviewing for technical roles. As mentioned below, it was one of the first things I wrote. I’ve reworked it many times for just 2+ pages of writing, but it is almost certainly not “finished” yet.
I’m planning on including bits and pieces of the book I’m writing as blog posts for several reasons. Specifically, I’m trying to help out with any advice I can while I’m putting all of this together. As part of that, I’m looking for constructive criticism and feedback alongside it. My experiences as an engineer are also not universal and so my own biases will creep up in my writing. With your input, I’m hoping to refine my own writing to help other folks out. If you’d be so kind to offer your advice in response, I would love to hear it.
When I write more posts with content from the book, I’ll paste an abridged form of this request at the top as well, tagging the post appropriately.
There are already books on the market about “solving” interviews. They’ll make promises about how reading this book will unlock the secrets that the industry clutches tightly, hidden gems squirreled away in vaults shared only with a hidden cabal of engineers. I’ve been 15 years in web development and I know nothing of such. I don’t have the answers to every question your interviewer will ask. What I do have are core techniques that have helped me in my everyday career that I believe are vital to being a solid, well-rounded engineer. In my time, I’ve been fortunate enough for many folks to take me under their wing and share their knowledge. I desperately want you for your part to grow as an engineer, where you’re confident in your skills enough to walk into an interview. Getting hired is a beneficial side effect of that.
I’m writing this, the preface, first. I’m not sure if that’s what writers do, as I’m not a writer by trade. I’ve made attempts at writing posts for a comedic blog in a past life. If the goal was to be popular and make people laugh, it wasn’t particularly successful. Originally, I wrote here “poor attempts at writing posts”, but that wouldn’t be accurate. Execution may have been poor, but I was never lacking for effort. I cared and I tried – that’s still a win for me. As part of this writing process, I’ve delved back into blogging to engage with folks at large on many topics surrounding interviewing. That’s a fun part in all of this too, to stumble and then double efforts in a different direction with experience guiding. That’s quite like engineering.
So, how does this relate to interviewing? Very few people I know are naturally “good” at interviews, the definition of which will almost certainly be subjective. As interviewees, we often don’t get helpful feedback from companies beyond a format letter from HR. “Candidate wasn’t technical enough”, “They failed to meet our standards”, etc. That doesn’t give you a place to improve, though. So you’re left thinking “What did I do wrong?” a lot of the time. Sometimes it’s knowing exactly what you did wrong without any path forward towards resolution that also trips us, caught in an infinite cycle of “what if I had just said/done this instead..”.
There are still fewer engineers who are good at giving interviews. We’re never taught what core topics are necessary to ask, which to avoid, and, possibly the most important, how to ask them. It’s the difference between “What’s your philosophy on Object Oriented patterns in large codebases?” versus “Explain the core tenets of Object Oriented Programming”. The first is a discussion where you can explore developers’ experiences in their career. Depending upon their background, they’ll be able to give you an idea of where they fall on a gradient of growing knowledge. The latter is rote memorization of an academic textbook or a wikipedia article. Does that reference make them a better engineer or did they just cram the night before?
As interviewers, we often mislead with statements or mumble through questions. We send all sorts of verbal and nonverbal cues. We often attempt “trick” questions to appear clever. A classic example is the “Why are manhole covers round?” question Google used to give. Hardly useful in day to day software development. But even beyond that, we give esoteric ones – name your favorite Apache config, write out this sorting algorithm, etc.. Because of course we all have one. All of these and more have inherent biases in them. We’re looking for “someone like us” which is vague and fraught with peril.
On both ends of the interview, we will sometimes fail. But there’s learning to be done even when we come up short, even if it’s not readily obvious.
My career has centered on web development. It has stretched over 15 years, starting at university getting a Bachelor’s in Computer Science and a minor in Mathematics, in internships at companies large and small, in junior dev roles at idealistic start ups, and now in senior roles at a well established company. I’ve worked on app development on the desktop, CSS and javascript on the frontend, and more recently on backend infrastructure like building a photo storage stack and migrating petabytes of data between MySQL datastores in a production environment without planned downtime. With that in mind, there is no “correct” career path and everyone has their own progression. I’ve seen junior devs starting in their 40’s and senior engineers in their early 20’s. Some folks like the constantly changing field, moving between different parts of the stack or wearing many hats at once. Others choose to hone their career on a particular skillset, mastering the eccentricities of a particular technology. They’re all valid and anyone who tells you otherwise is only exposing their own fear of missing out.
My hope with this book is to shine a light on these dark corners of the interviewing process, the core of which should be determining what kind of engineer you are. If you’re a junior engineer getting involved with development for the first time, I’ll share some foundational knowledge that many companies use when vetting potential employees. If you’re a mid-level engineer or perhaps it’s been awhile since you’ve interviewed anywhere, this can be used as a refresher course for all of the things you’ve forgotten. And if you’re a senior engineer, there are a few tricks to pick up when giving interviews, or maybe just a reminder of how hard it was when you first started which you can channel into more empathy with your coworkers. Remember that you too were given a chance once. Make sure you’re giving someone else the opportunity to grow and to learn as well.
I’ve had mentors throughout my career who have been gracious with their free time and sharing of experiential knowledge. I’ve been given opportunities at companies that eventually ran out of money, that veered into obsolescence, some that have been fully acquired, and sizable companies that have large user bases and include a prominent portfolio of projects and senior engineers well known in the industry. In all cases, I’ve been fortunate to continue growing.
In short, I’ve made a good career thanks to the generosity of folks I’ve had the good fortune of crossing paths with. I want to extend that same generosity to others. I hope I can help.