Great developers are not made, they are born. I’m not one of those degree snobs. Though I hold both a bachelor’s and a master’s degree in computer science, my experience has revealed a truth — the ability to write great software is a gift.
It’s not something you can really learn. In music, anyone can be taught the notes but great musicians are born. No amount of practice can change this. Similarly, having a degree in computer science doesn’t necessarily mean you are gifted.
It means that you have managed to meet the current requirements for a CS degree in today’s world. I believe that someone with a natural gift will benefit tremendously from formal training, but the contrary is not always the case.
Maybe It’s Gotten Too Easy
And there’s a bigger problem. Many universities are turning out graduates who can’t write working code. It’s alarming. In my day, computer science had weed-out classes. At my alma mater, the Intro to Computer Science course had a drop/fail rate of sixty-six percent.
The first day of class the professor would say “look to your left, look to your right, at the end of the semester those two people won’t be here.” And it was true. The course was tough. Every week we had to write software. The problems involved recursion, pointers, linked lists, sorting algorithms. It was a boot-camp for developers. But if you endured you knew you had the right stuff — you had the gift to be a software developer.
Today it seems like things have changed. Many of the students I see are familiar with theory but don’t have any real practical problem solving skills. They are quick to turn to Google to solve problems, often copying and pasting code that they don’t even understand. When asked to build something from scratch, they’re lost. I’ve seen people ace every class but they can’t program their way out of a wet paper bag. It’s sad.
What Happened?
In my view this all started during the dot com bubble. Everyone was trying to create a start-up and they needed developers. Enrollment in CS departments swelled. Budgets grew. Careers were made. Professors got tenure. Life was good. Then the bubble burst.
There was a glut of developers in the market. Suddenly these degree programs needed students but no one wanted to enter a career path with so much competition. The universities responded by lowering the bar. I think this happened on both the faculty and student side. Programs became easier. More students could graduate with computer science degrees. Life was good again — at least for the universities.
For those of us who actually employ developers the story was much different. We were, for the first time, faced with lots of “developers” who didn’t know how to program. In the past I could assume that if someone managed to graduate from a university with a degree in CS they were at least a decent, if not experienced, developer. Today it’s hit or miss. So I’ve developed a system for separating the wheat from the chaff.
A New Game Plan
I pride myself on my ability to spot talent. Often I need to squint my eyes a little, but it’s fun to find a diamond in the rough — someone I can help develop into a superstar. These days, it’s really a necessity.
When screening applicants, I look for three things — talent, passion, and most importantly, aptitude. Noticeexperience is suspiciously missing. That one only matters if you have the first three.
Interviews are casual by some measures and terrifying by others. We do group interviews with our most senior staff. We ask interviewees to write code — pseudo code is fine. What I’m looking for is how they approach the problem. This is key.
I’ve found that you can spot a gifted developer from a mile away, if you take the time to see how they solve problems. What questions do they ask? How much time do they take to think about what you are asking them to solve? Ultimately there is no correct answer to the question posed, just the approach in solving it.
Using this method I’ve managed to find some incredibly gifted developers, many without CS degrees, who would probably have been passed over by traditional interviewing techniques.
Ultimately my goal is to build a great team. Using this technique saves me from turnover in our team down the road. After all, the least productive time for a developer is when he first joins a team. Generally there’s lots of ramp-up time while a new person gathers the domain knowledge needed to really contribute. For me, this cost is too high to spend on the wrong candidate.
Leave a Reply