So I was kicking around some ideas with partner-in-crime and work friend Chris James of Learn Go With Tests fame, on the subject of "what even is a 'senior' software developer?". This wasn't an entirely abstract conversation; we were once again trying to work out what the best questions to ask at an interview were - interviews where we were doing the interviewing.
Chris was thinking about what skills and knowledge a "mid level" (again, whatever that is) needs to become a senior developer. I was (once again) bemoaning the number of developers who can spit out a few buzzwords and parrot some fashionable ideas they've seen on Twitter, but then never apply those ideas to their work.
And somehow these two threads turned into the ultimate non-technical interview question:
Which three books have most influenced the way you work?
What, Gatekeeping Much?
We instantly wondered whether we'd be excluding people. And the answer is: yes. It's an interview, the whole point ultimately is to exclude some people - the people who you don't want to get the job. So the better question is: is this question excluding the right people?
And I think it is. This is a question for a senior software developer. I would genuinely expect a senior developer to have read at least three books. Three books that were worth reading, and which were influential on the way they work. This is a knowledege industry (or at least it ought to be and not the fashion industry it feels like half of the time), it's really not too much that we expect the senior developers in our discipline to have read three - more than three - actual books.
Not blog posts - not that I've got anything against blog posts. I've learned a lot through blog posts. But the attribute I'm looking for in a senior is somebody who can think "big" and think "slow", who can pay attention to a long form piece of writing which has ideas in it that won't fit into a five-hundred word explanation. I'd probably accept a journal paper at a pinch. But not a blog post. And definitely not a tweet.
Lol Yes I've Read ...
Of course, this still doesn't weed out the people who try to fake it. Yes, they will say, I've read The Structure and Interpretation of Computer Programs. It was wonderful. Job please.
Well, no - no job yet. Because the next question is:
Please explain how those books have influenced the way you work. Frame your answer as though you were talking to a junior developer.
One of the most important skills of a senior developer is the ability to pass knowledge and skills along to the "next generation". I want a senior developer to make all the developers in an organization better, and especially the
"junior" developers on their team. I don't want them to sit on their mighty tower of 1337 h4xx0r skillz - I need them to be educators and explainers, raising their game by raising everyone else's game. And if they can't explain why these important ideas are important to them, hopefully in a way that will inspire other developers to read the same book, then I really don't understand how they'll fit in with my idea of seniority. Maybe they should go and interview at a place that wants you to invert binary trees on a whiteboard or whatever.
I'll go further: I don't even care that much if it's not a "tech" book. Maybe they learned something from a book about management. Or a book about chess. Or a book about sixteenth century Italian opera fans. It doesn't matter. As long as they can explain what they got from that book in a way that someone with little context in software development can understand, it'll indicate the sort of skills I would be looking for.
So now what do you do?
I'm a Junior / Mid-level Developer...
- Ask all of those senior developers you know to name their three books.
- ... and of course explain why those books to you.
- Put them all together in a big unordered list
- Think about what you want to be learning next, what's missing from your skill set and then...
- Read a book
- NOW!
Seriously - read a book. Don't doomscroll Twitter, don't read another blog post about the 27 new technologies you need to learn to be a DevTechOpsDataMonk. Don't learn yet another "Hello World" in the language du jour or the hot new JS framework. Read a book! Now is the time to step up, to move towards mastery of your discipline. Get that book, read that book, take notes about that book, bore your colleagues, friends and family by talking about that book, blog about that book. But read that book and read that book now.
And if not now, when?
I'm a Senior Developer...
Just write down your three books with a quick description and explanation of each, and now you're ready for all those juniors who are beating a path to your door. Let me know your list!
And, of course there's a bonus here - I'll hopefully get to hear about books I ought to read!
Audere Legere
So there it is - does this sound right to you? Are you a senior developer who couldn't answer this question, and thinks it's dumb? Tell me why. Can you think of a better interview question that would test the same areas? Or a better way of asking the same question? Do you think books are just for old people who still think posting reaction GIFs is a thing. Or are you just waiting for me to name my three books? I might do it in a follow-up post. In any case, feel free to hit me up on Twitter or the comments to start a conversation.
Top comments (10)
So, as an interview question, I would skip this one. Even as a voracious reader myself, I think it skirts too close to hiring someone who is like me, does things like me, approaches things like me. Even if I am a successful member of the team, modeling all new senior hires after myself is limiting!
But, also, being a voracious reader, I can't help but also answer this question. Moving more into management/leadership roles, my current list skews to that:
📕 Don't Make Me Think I read this later in my career, despite the fact that it's considered a pretty foundational book. I found it to be validating about my own ideas about UX and provide me with some clear ideas of things to look for, questions to ask when doing design review of comps. Krug's follow-up book about user testing is also very worthwhile, especially for small teams where you may need to wear many hats.
📙 Radical Candor Immensely helpful context for giving feedback to your colleagues and peers. The name originally turned me off (too close to brutal honesty, I suppose), but I'm glad I picked it up.
📘 The Manager's Path Great insights about the expectations, challenges and impact at various stages in your tech career. Compared to other books about management that may only be helpful in your first year of management or when leading a team of a certain size, this one has broad appeal.
✨ Bonus choice: In addition to learning and developing my craft and skills through books, I've also found it helpful to learn more about the domain of our product and the issues faced by our users. For me, that currently means understanding college professors and students better. To that end, I found Small Teaching to be a great summary of current learning science, including ways faculty might be looking to implement those strategies and findings in their courses.
I agree- the danger of all hiring - we want people who are different, but the same! On reflection, the idea implicit here is that senior developers should read books - should be "readers" who want to read books and to learn things from reading books.
Maybe this is both "too much to ask" and too biased towards people who are like me (not as voracious as I was in my teens I'm afraid to say).
In any case, thanks for sharing your books and pushing back!
(Is Radical Candour good? As a phrase it's always seemed like an excuse for nasty people to be nastier...)
That was exactly what put me off the book when it was recommended to me. It is far, far better than its title and really is much more grounded in wanting to deliver good feedback and doing so from a place rooted in caring about your team.
I for one really dislike books.
Am I a senior software engineer? I don't know. I consider the term to be meaningless dribble used by managers and recruiters to feign competence at the evaluation of candidates. Though if slow and big thought are what you're after I'm fairly certain I qualify.
I bought only a handful of books at university because they generally turned out to be a colossal waste of time. It was far more efficient (for me) to review slides and make exercises.
More than anything else, if you select by books read you will be selecting people based on how they learn, rather than what they know. There's some categorization of how people learn, but I'm not familiar enough with this branch of psychology to say something useful about it. Either way, a lot of developers learn by doing, the subject lends itself really well to it, you'd be needlessly excluding them.
Basically, you're trying to learn about stored data (domain knowledge and expert opinions) by measuring one particular input (read books), rather than querying the data directly (e.g. "tell me something interesting and deeply technical"). Admittedly, the later does require the interviewer to be rather knowledgeable about the subject matter as well.
Ah. Good - dissenting opinion!
And I can't dismiss this position out of hand - I really enjoy your writing, and I'd always assumed a writer was a reader.
Yes, the idea of "seniority" could be parked - more meaningless drivel. Although I always like a yardstick of "can make other developers better developers".
I would've put money on you picking Barendregt.
I agree. I'd say every developer learns by doing. It's a practical subject. Book learning ain't no good unless it gets applied to a real problem. But are you concerned that the inverse might also be true; if you're only ever learning by doing, aren't we limiting ourselves to repetition of the same pathways that we've seen before? (I find the idea of praxis useful here - theory applied in practice (and then generating more theory)). What's a sufficient input to break habit and start building new pathways. I say "book", but maybe I could take "lecture series", as well as "paper".
But, I suppose, I should throw this back to you. How do you learn something new? Something, as we've said, "big and slow"?
Yes, but that's an extreme. Generally I expect somebody hears about something, reads up a bit, then tries something out. There's reading in there of course, but a book takes that to the other extreme, taking exploration and the practice out of the loop. That's always seemed to passive to me.
Now if you include papers and lecture series then I have read quite a few things, but most were not all that important on my knowledge and beliefs. Certainly not individually.
Of the three most influential things, I would name 1 lecture series (Bartosz Milewski's series on CT), a conversion I had with a teacher once about why functional programming was interesting for concurrent programming, and a disagreement I had about orthogonality with a presenter at a meetup one time.
I was just thinking about the Milewski lectures/blog/book in relation to this. It's definitely a big "blob" of influential learning, whichever way it is consumed!
What a simple and powerful question! For myself, these are:
📕 Phoenix Project – taught me why short feedback loops are essential and why every successful organisation should foster a culture that endorses experimentation, learning from failures, repetition and practice as paths to mastery.
📕 Unicorn Project – taught me what developer experience means, why psychological safety is crucial, and how as a developer, I can improve the quality of work from inside the organisation.
📕 Continuous Delivery – taught me the most valuable lesson: "if it hurts, do it more often". Having embraced this idea, I've never left a project without improving the delivery process even slightly.
Great books - thanks for sharing!