“But I can just Google it.”
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?
Identifying their “core developer smarts” is the first step to see how well they’ll execute on a software development task.
I won’t just ask “What’s a hash?” Instead, I want job candidates to describe how a hashed collection works and how they’d design and implement a simple hashing algorithm.
I’ll ask why garbage collection is important. I’ll ask about their garbage collection strategies.
I believe their “core developer smarts” are reflected in their understanding of data structures and memory management.
This is because I have come to realize that developers need to understand the implications of their design choices.
They shouldn’t just robotically mimic what they find online or learned in the classroom. How smart they are with the design is a much better reflection of their overall software development skills.
My next step to uncovering the smartness of Johnny-developer is to see how well he works with others. I’ll have him perform a coding task jointly with another developer from our team.
The act of pair programming with the interviewer on a task allows me to see how the interviewee responds to suggestions and critiques from a peer.
Seeing whether they’re quiet or outgoing helps show how well they’ll work with a team – what I refer to as “collaborative developer smarts.”
And the final step in measuring Johnny-developer’s smartness is checking out their “worldly developer smarts.”
I use the term “worldly” because they must show a passion for software development, and also because there’s no use in reinventing the wheel.
There are snippets of code all over the Internet. If Johnny-D has proven his core and collaborative development smarts, now I need to know he has experience in finding pieces of the puzzle and has a natural curiosity for technology.
I want him to explain his approach to finding solutions and resolving errors.
Does he just Google a phrase or are there specific sites like Stackoverflow.com where he can more quickly find answers?
I’m even more impressed with developers who regularly contribute to these sites and forums, because they’re more likely to receive fast answers if they’re respected members of the community. To this end, I’ll ask to see threads where they contributed in the past.
In the end, I’ve come to realize that Googling has its place in software development.
Although it doesn’t exactly define how smart a developer is, if you dig deeper into their core, collaborative and worldly smarts, you may find that their Googling capabilities are a far better indicator than how they dress.
But flip flops in an interview? Really?