I'm a developer with 5 years of experience, looking for another employer. One company I'm going to apply for the full-time job wants me to mention and summarize 3 helpful books on programming I read as part of their application process. But I almost never read a book after graduation. I honed my skill from googling, documentation, blogs, videos, or Q&As.
I'm afraid the application might go expired(no specific date was stated) while I'm reading. I can write about some fundamental books I read during my university period. But those were about 5 years ago and might not make a good impression by mentioning those.
Can I compromise by mentioning dev blogs instead after I apologize because I cannot answer the question directly? Or should I write about books I read 5 years ago? I'm also open to other options.
It is unrelated to this question, but I decided to read a book or two. Even if I miss the application while I'm reading, I think I can use the books for other applications.
I have read many books over the 20 years of my career. Some because I had a specific problem, but those have been mainly replaced by online resources. Most to develop myself professionally. Even if the industry is fast-moving, those books are almost timeless.
If I had to name the three most important books any programmer should read, none of them are recent. None of them are even about a programming language I use. Some are decades old–yet I think still more people need to read them!
So, I'd say talk about the books you read five years ago, but not about "C# for Dummies", but rather about things like "Design Patterns", "Peopleware", "Refactoring", "Enterprise Application Architecture", "The Clean coder", ...
In other words, books that teach you generalized concepts or have an impact on your profession as a programmer rather than a specific tech skill. Exception, if you have a book you consider a "standard" for a specific field you are applying for, e.g. "The Data Warehouse toolkit"
Oh, and pick up a book some time soon. May I suggest "Joy inc."
Can I compromise by mentioning dev blogs instead after I apologize
because I cannot answer the question directly? Or should I write about
books I read 5 years ago?
I suspect writing only about blogs will indicate to the employer that you haven't read any books. And since the employer asked specifically about books, that's a clue that they feel books are important.
Instead, write about the books you read 5 years ago. Try to choose books that are still relevant. There doesn't seem to be any requirement to indicate when you read them, so no need to mention that.
It's also possible they are probing to see if you are familiar with "standard" (significant air quotes) texts in development right now:
Robert Martin ('Clean Code', 'Clean Architecture, etc..)
'Code Complete' from Microsoft
'The Pragmatic Programmer'
the gang of 4 'Design Patterns' book, etc..
or even Google's Engineering Practices documentation
This is not to say that everyone agrees that 'Uncle Bob' is the standard or that DevOps is rightly named and executed, but knowing who Robert Martin is and at least having a passing familiarity with the existence of those titles may be valuable to a given manager.
Assuming you think they're genuinely interested in the answer, rather than this just being a tick-box exercise, I'd say good high quality Dev Blogs should be an acceptable substitute. Probably with a brief summary of what's great about them / the best things you've learnt.
For instance, if I were asked that question, I would talk about https://www.joelonsoftware.com/ and how it taught me about the business of software development, and how to think about software in the context of a company's goals and priorities.
When I talk about this maybe being a tick-box exercise I mean:
Is this a genuine question that the hiring people ask because they want to hear what potential employees say? That's going to be read by an actual software developer who can appreciate the answers.
Or is it some question they read about somewhere and decided to copy? The same way that it was fashionable for a while for companies to copy's google's famous brainteasers? That's going to be read by some recruiter or Admin who's only looking to tick a box that says "reads programming books".
I note that in the time this question has been up, you've had time to read 3 books :) That is a brute-force solution, but it is the simplest one :)
Assuming, of course, that you're trying to get hired and not get into a debate about the merit of reading books. I can say this.
Books serve as a well-rounded primer on a subject.
As compared to Googling, blog-reading or hanging out on StackExchange, which gives you what I call "Swiss Cheese" knowledge.
For instance, blogs and StackExchange only present to you the kinds of issues that lexically fit on blogs and StackExchange. And Google, that only answers questions. It does not cue you as to which questions to ask. And so you get little bits and pieces and parts of knowledge, but you don't get anything like a "view from 30,000 feet".
This is most comical on diy.stackexchange I think. Say someone's running an electric line out to a shed. They'll have arrived having researched wire sizes, and we'll go in dervishes on the merits of conduit vs cables, AL vs CU, voltage drop etc. until we've honed it down to exactly the correct, gold-standard wires to use. And then, they'll bury them 3 inches deep and not run a ground wire /facepalm.
They just freestyled that stuff because they didn't know they had to do a particular thing. Because they didn't ask, and it never came up.
Now if that same person had started with a book on the subject, the book definitely would've covered the subject matter. They may not have recalled the correct burial depth, but they would've remembered that burial depth, grounding, bonding, disconnects, and bus sizing are indeed things you have to think about.
With programming, this is more acute, because books will introduce you to the author's coding style, and the author will use language features and combine language features in ways you would never do on your own. It's far too easy to sit "inside your bubble coding your way", but that leaves you ill-prepared to interact with other people's code. They are likely using programming methods which are popular (not least because they are in popular books), but that are simply unfamiliar to you. Take my word for it - I code Perl.
I agree it's unfair as people have different learning styles. The idea, which I don't really buy, is that the very best engineers read books.
So I wouldn't hesitate to find and read 3 books about things you know really well. This will highlight your areas of technical depth, and should be quick reads. EG if you know git well, read a 150 page intro to git. And be sure to mention how the books help you understand the important foundations that you never can grasp from reading blogs and cribbing from SO. :)
You need to have read books. It's a huge red flag that you haven't. It's honestly a great interview question.
Anyone can read a blog about how to solve x, it's not really setting you aside. Similarly, I don't think they'd be impressed if you wrote about how you read the Python book, or the Hibernate book, for example. They can just ask you technical questions to find that out.
I would hope they are looking for someone who has read about the philosophy of programming. So, for example, books about software craftsmanship, "uncle bobs" book on... well pick one. (I like clean code, but half of it is useless with today's auto complete in ides.) Oh effective Java should just be there if you're a Java dev. Any book on programming management (agile).
I wish there were more books on programming and business /making money. That would be far more useful to far more programmers, so Kaz suggestion about Joel's blog - and much was published as a book a while back - is good too.
I would suggest you read these books - and these types of books - to develop your career. For now just buy three of them, and spend a weekend skimming them and write down things you learnt.
To do this, break your answer into three sections, not by book but by topic.
I learnt about agile management, here's what I learnt.
I learnt about writing code that is really understandable, here's what I learnt.
I learnt about the importance of testing code, here's what I learnt.
Then use then as lynch pins , and as you skim a book note down anything in it relevant to those points. Then just reference the three books in each of the sections.
This will help you skim the book, shows you learnt at a high level, and gives you credit for knowing three concrete and useful areas.
Well this got a lot of attention. it's weird that programmers, in a career that's defined as "always learning" would find anything controversial about the need to read books. You need to read books in whatever career you have. I'm branching into venture capital now, and the list of books to read there is long.
I have friends in PE, sales, bond management, business development, management consulting and even coffee. They all read books relevant to their careers. None of them have not read a relevant book in five years.
I don't know what to say to anyone who thinks that never reading a whole book in five years relevant to your career is not a red flag.
Ok maybe I do, here goes. Blogs will only get you so far. blogs are, by their nature, self contained, unrelated ideas. A book, generally, is a collection of smaller ideas in service to a larger point. This is a huge difference - you don't get interrelated ideas in blogs, because the author cannot assume you've read their corpus of work. As such, there is a limit to the depth of thought a blog can expose you too. depth of thought is essential in any career, tech is no exception.
Next, yes, code moves fast. But to be anything more than a code monkey - to be earning top dollar - you need to provide services beyond executing tasks. You need to be philosophical about what you're doing, to understand what clean code, or agile management, or testing, or any number of other things is. You won't get a deeper knowledge easily from blogs. Also, these higher levelconcepts
move much slower than languages in tech. And these things are really really key as you develop your career. They're key whether you are an individual contributor or a manager.
Finally, blogs have their place - but only for discrete thought, for discussing a self contained item. They're much better than books as they're faster to publish. It would be an equally huge red flag if someone had never read any blogs in five years either.
The interview question is useful because when you hire people, you're not just trying to find the best developer. You might need someone who can engage with the client side, or who has management potential to lead a growing team later, our who has strategic thought to help a team that tends to focus on the here and now.
With that in mind, when I note that blogs aren't adding value in my second paragraph it is because I suspect they are looking for someone with skills beyond sheer technical ability. And as such, noting you read blogs will not add any value to your candidacy.
There are some employers out there who have strange ideas about what makes a good employee. They are usually full of themselves and you will spend a lot of time listening to them blow their own trumpet about themselves. The one experience I had with such an individual didn't go well, these people tend to work well with passive people who absorb all of their bullshit as gospel. By and large he was good at what he did, with one fatal flaw, he thought he could run his entire business and his dev team on a single server. This was back in the day when virtualisation didn't exist and mail servers were always hosted internally, so we had domain controller, file server, mail server, source control and test servers all running on a single two grand clone machine that had to be rebooted multiple times a day. In other words, he was a clueless idiot. The good news with these people is you can bullshit them really easily, whatever he likes, you like, whatever he thinks you agree, but just disagree enough to make yourself believable
Let's take a step back from the question and rephrase it a bit to try to capture a decent guess at the employer's intent:
What kinds of programming knowledge that has historically been delivered in book format have you found useful?
In other words, I don't think they're interested in asking where you learned specific practical knowledge like "how do I iterate over an array in LANGUAGE?" and insisting that needed to come from a book. What they're really after is not whether you possess the knowledge to program, but whether you've been exposed to conceptual thinking in some depth about the why behind the profession and its subfields and thought about how you can put it into practice in your work.
While there are many technical books covering all sorts of topics, the ones that tend to come up in interviews and conversations are usually those that involve higher-level concepts and the craft of programming. The examples in NKCampbell's answer all fall into this category; they are books that advocate opinionated theories of how to think and organize and work covering everything from design patterns to coding practices. There are also books that go into significant detail on important topics like usability, accessibility, testing, DevOps, site reliability engineering, etc...
Since this employer has asked the question, it stands to reason they consider knowledge of this kind important for candidates. So your answer should demonstrate, if you have gained equivalent in-depth knowledge relevant to the position from non-book sources, what you've learned and where you learned it.
I'm a developer with 5 years of experience, looking for another employer. One company I've applied with wants me to mention and summarize 3 helpful books on programming I read as part of their application process. But I almost never read a book after graduation.
You really should read books, or academic papers and maintain a bibliographical database.
The question I would ask when applying for programming job is: what budget do you allocate for books I'll need on the work. And budget means both time (give you time to learn more) and money (buy you books, or buy you some training, or attending some conference).
Can I compromise by mentioning dev blogs instead after I apologize because I cannot answer the question directly?
Indeed you could, but by telling you don't read any programming related books you are not giving -as a software developer- to potential employers (or clients) your best professional image.
A software developer also write technical reports (or software documentation) -and read other ones- e.g. about software architecture -, and these should have a bibliography. But a code monkey just write code, and that is the reason he/she could be easily replaced and might be paid less.
For examples, look into large open source projects such as the Linux kernel or the GCC compiler. Both have not only code, but also documentation (and perhaps even books about them) and a significant amount of the work happens to be done by writing (English text, not C++).
Look also into proceedings of ACM conferences. All of them are related to programming.
So, at least mention in your resume the title of technical reports you did write.
(of course, if they are very confidential - e.g. military secrets, don't)