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 wasnt really answering the question.
He hemmed and hawed for a few seconds and thats when he blurted his Google answer.
This young gun obviously didnt know the answer to my question. Yet from his perspective there was a feeling of who cares? because the answer could always be Googled.
(Doesnt 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 cant 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 theyll 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 cant answer a moderately tough question like what s the best algorithm to maintain a free list for heap-based dynamic memory allocation? then they wont 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, wasnt 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 isnt really comparing apples to apples. Heres why.
Back in the day, if I came across a challenging problem during my design of a COBOL application, Id get out my COBOL II manual and check the index. Lets say, looking for examples of using reference modification (i.e. string manipulation).
Id likely find it under R and see a bunch of page numbers that may or may not have what Im looking for. Id flip through those pages. If I didnt find what I was looking for, Id get out another book written by some COBOL expert and go through the same index search.
And if I didnt find the answer there, Id 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 werent 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. Thats fitting, given that Saint Patricks Day is right around the corner. But I needed no Irish luck to find this answer. I needed only Google.
So maybe Johnny-developers 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 hell be working on?