What Makes A Smart Developer? (Is it Google?)

I was staring across my desk at a mop-haired young man who was interviewing for a Java software developer position on my team. He was responding to a question about memory management, but he wasn’t really answering the question.

He hemmed and hawed for a few seconds and that’s when he blurted his Google answer.

This young gun obviously didn’t know the answer to my question. Yet from his perspective there was a feeling of “who cares?” because the answer could always be Googled.

(Doesn’t “Googled” sound better than “Binged” – which is actually a real word with bad connotations? Something Microsoft overlooked in their focus groups! But I digress…)

Back to the young man sitting in my office. Actually, “young dude” would be more appropriate. He showed up to the interview in sandals, baggy pants, and a very colorful button-down shirt with a skinny tie.

(Is that even appropriate, even in the casual world of software development? Sure, our company had a casual dress culture, but I was always taught to dress conservatively for an interview because you can’t change a first impression. Sorry, I digressed again.)

My goal when interviewing a developer is not just to see how smart they are, but whether they’ll be a fit for our culture and work well within our team. Not that fitting is enough – they need real skills. If someone is a great guy (or gal), but can’t answer a moderately tough question – like “what ‘s the best algorithm to maintain a free list for heap-based dynamic memory allocation?” – then they won’t receive a job offer.

Is this unreasonable? Upon further reflection, maybe it is.

When I was first interviewing for jobs as an IBM mainframe developer, I took many written tests about COBOL, JCL and CICS. I knew going in that there would be a test, so I prepared for it.

And in one case, I had a headhunter provide me with a sample test. I simply memorized the answers. And, lo and behold, when I sat down to take the actual test I was pleasantly surprised: it was identical to the so-called “sample test” the recruiter had provided.

Well, I aced it and got the job offer. And I felt no guilt because in my mind I remember thinking “but I can just look it up anyway.” Hmmm, I think I had a good point.

Now, how different was that from this Johnny-developer sitting across from me with his Google answer? Why memorize anything when you can easily look it up?

He was actually being more honest about it, wasn’t he?

There was no World Wide Web when I was interviewing for those jobs back in age of “big iron.” But we did have manuals and books. So I could and did look up basic syntax or solutions to tricky problems.

But my situation isn’t really comparing apples to apples. Here’s why.

Back in the day, if I came across a challenging problem during my design of a COBOL application, I’d get out my COBOL II manual and check the index. Let’s say, looking for examples of using reference modification (i.e. string manipulation).

I’d likely find it under “R” and see a bunch of page numbers that may or may not have what I’m looking for. I’d flip through those pages. If I didn’t find what I was looking for, I’d get out another book written by some COBOL expert and go through the same index search.

And if I didn’t find the answer there, I’d get in my car and go to the library or bookstore to continue my search.

One thing we did have was email, so I could also email a bunch of my colleagues to see if they had recommendations. But I had to wait on their responses and in those days people weren’t constantly checking email.

My point is that this process could take a very long time, taking a big chunk out of my productivity.

Today, Johnny-developer can simply Google “reference modification examples” – and presto! I did this for kicks and found The University of Limerick computer science department provided a few good examples. That’s fitting, given that Saint Patrick’s Day is right around the corner. But I needed no Irish luck to find this answer. I needed only Google.

So maybe Johnny-developer’s Googling answer was the right one. Perhaps asking direct questions about syntax or other such things that can be easily referenced online is not the best approach to determine how smart a developer is.

What I really needed to know is: can Johnny-developer use logic to solve problems on his own and as part of a team, while showing true understanding of the platform he’ll be working on?