By: Elias Cobb, National Recruiting Manager
Never memorize what you can look up…one of my best consultants said that to me one day. We were discussing interviews, and the questions that come up in many of them. His basic point, as I took it, was that as a software developer, one cannot truly memorize everything one would ever utilize. There are going to be things to look up, and the important part of development is in problem solving, and basically using one’s brain power on tackling difficult issues, not rote memorization of something that could be looked up in three seconds. And that software development has as much artistry to it as it does rigid rules, which means there is often more than one right way to solve a coding problem.
It also took me back to my teaching days, when, on one of my first days, my chemistry students asked if I was going to make them memorize the periodic table, as teachers in the past had done. I turned around and looked at the gigantic periodic table hanging behind me, then turned back around to the class. “Why would you have to memorize it? It’s right here!” I then made the point – someone doing actual chemistry is not going to rely on their memory of the periodic table for the atomic weight of an element for a calculation; they’re going to look it up to make sure they have it correct. They will, however, know why the periodic table is organized the way it is, and how to use it in doing chemistry.
So, to get the point…why would one ask “book” questions, things that can be easily looked up, in a job interview? Is memorizing something like that truly indicative of one’s overall skill as a developer? I would argue that it isn’t. I suspect it has more to do with having an “objective” interview process, but I can tell you, you’re missing out on great candidates if you rely on these types of questions.
Here’s another quick, real-life example for you. I had a consultant several years ago, a COBOL developer, about whom our client raved. They said they would assign him tasks that took other developers two weeks, and he would finish them in three days. He had a couple of other clients who loved him as well, and would basically go back and forth between these employers on contract because of the outstanding work he did. Well, we submitted him to a different client as he had some downtime. This client gave him a technical test, and let us know that he failed. He got back to us and said “I could have aced that test right after I graduated, but it mostly covered things out of a book that I never use in actually coding.” I’ve never forgotten that example, as that client likely missed out on a consultant who could have helped them greatly.
I want to be clear; I’m not advocating not asking technical questions in an interview. I am, however, advocating making it more of a discussion than a “right or wrong” proposition. And don’t base your entire decision about a candidate on a technical test. Perhaps some of the factors mentioned above are in play, or maybe the person is a terrible test taker, but a crack developer. That’s certainly something I’ve seen as well, and again, you don’t want to miss out on someone who could be a great asset to your team.