This blog post is the result of a combination of the original post here (February 2016), a very similar post on Linked-In, and the comments and conversation resulting from them.
For those of you who don’t know me personally, I’m a development manager. The most important part of my job is to interview and hire software developers. With mediocre software developers, you get mediocre software. No one wants mediocre software.
I like to believe I’ve become pretty good at identifying talent and weeding out less-than-desirable candidates. During my career I’ve interviewed many candidates, possibly in the hundreds, and built successful development teams from scratch more than a few times.
Last week I received an email from our HR recruiting manager about a young, fresh out-of-college candidate that we really didn’t have a position available for, but had an internal referral and really wanted the opportunity to talk to us.
Our resulting conversation, or rather, the fact that I’ve had this conversation at least 3 times in the past year, is why I decided to write this post.
Here was my feedback to the recruiting manager:
This was a nice conversation, he’s a pretty smart kid. As I expected, his answers were wordy and rehearsed, pretty standard for someone fresh out of school with only scholastic experience.
That being said, after a few softball tech questions I drilled into his knowledge a little bit and really uncovered how junior he is. When I asked him about Agile, he recited a Wikipedia definition that most likely would get him a “B” on a test, but he couldn’t give me any specific examples of how he and his team used it or why it was “better than waterfall for modern projects” (his words).
We spoke only briefly about his PHP experience (it was on his resume), but after he couldn’t tell me how to concatenate a string or name any of the methods for dealing with databases I assumed he’d fall short on design patterns and implementation standards outside of what was written in a book.
Education is important, but more important than what you know is how you’ve taken what you learned and used it. I don’t care if you got an ‘A’.
When I talk to programmers, especially young ones, I’m looking for eager curiosity and self-taught experience. You can’t get this in a college classroom, it’s a personality. You either have it or you don’t.
As I interview more and more of our millennial generation I am finding that interviews like this are becoming more common. And that concerns me greatly. Somewhere along the line, our formal educational system evolved into a series of rewards for memorization and regurgitation of facts and definitions. Practical application and self-paced (self-motivated) curiosity have been replaced with the promise of
“Good grades = Good career”
To add complexity to the issue, the interview process itself is flawed. I could write a book (probably not a very good one) on interview questions and techniques and still not scratch the surface of every candidate’s true potential or knowledge. The sad fact is, I have 60 minutes (at best) to try and extract the complex answer to a simple question: “Should I hire this person?” I’m judging talent and aptitude, while trying to avoid knowledge and vocabulary.
As a software engineering student you are exposed to projects and deliverables, just like you will be in the working world. You were educated, ad nauseam, about waterfall, agile, branching and merging, and continuous integration. How did you use them in your project? Which of them worked for you, which didn’t, and why? How will you change your approach for your next project?
Everyone knows what a stone is. We can describe a stone and draw one, but only the great minds saw it as a building material and constructed great castles and cities. This is the skill I’m looking for, and it often hides itself well.
What I really wanted to say during the interview was “An interview and an exam do not share the same purpose, therefore they do not have the same answer. I’m not asking you about agile SDLC because I want to know if you know the definition. Frankly, I don’t care if you know the definition.” But I did not. Maybe I should have.
Many of the best programmers I’ve worked with have no formal college education, and many of them have no certifications of any kind, but they are still brilliant developers. Getting a degree in Computer Science does not make you a programmer any more than wearing feathers makes you a chicken.
Walk into your kitchen, unplug the toaster, take it apart and find out what makes it work. If this activity doesn’t interest you, maybe you should pick a field outside of engineering.