A big part of the world of programming is understanding concepts. Learning to learn is something every programmer has done. How do you learn new concepts? What are your methods for improving efficiency and elevating your craft? You would think these would be the biggest questions in the hiring process. However sadly they aren’t.

This concept can be proven by seeing how a lot of programming interviews go. Asking a programmer to interview in the most alien way possible. No intellisense, no Google foo, no man pages. The worst interview tech question I ever had, “How would I learn to use a tool without the man page or Internet?” I don’t know, how would I compile a program without a compiler. We can all do great things with constraints but by taking away the tools that make doing what we do efficient what are we really learning about a candidate.

My last gig I was running a small team of Python programmers. I was in charge of interviewing and acquiring new talent for the tech side of our business. What were the things I interviewed for? I mostly looked for how the candidate worked and perceptually understood things. Problems would be presented to them as an expected input and expected output and a broken algorithm that needed to be repaired. Most of the company’s time was spent visiting problems like these. The algorithm had no unit tests. Did the candidate ask about unit tests? Did the candidate poke at the code to brute-force their way to a solution? A surprisingly high amount did. The process was unconstrained, they could search the internet all they wanted. The reason why? Because they wouldn’t find some quick Fizz Buzz solution by doing so.

The broken algorithm I wrote for the interview was a small one, all it did was look up a phone number by name and the data was just stored in a dictionary. The code was just a little 6 line Javascript file. No frameworks were utilized. If the candidate knew some how to conceptualize what the code was trying to do they should have no issue debugging and fixing it. In the time the candidate spent debugging that code, I learned everything I needed to know about the them. Even if they had never wrote a line of Javascript, did the candidate look up JS and learn what they needed? Frankly JS syntax was the least important aspect of the interview to me. Runtime errors can help you resolve many of those issues. The time spent working on the code was also not that important. However, if they spent 15 minutes and not really talking it out, not really searching for anything or explaining where they felt the problem was. Then they were probably not that great of a candidate. While you might know answers to interview questions by heart, if you can’t produce that skill in the real world, you aren’t likely to be successful.

Sadly, the interview world for tech isn’t getting any of this. Qualifications are based on knowing specific syntax or languages that is the company’s current flavor of the month. What happens when that language is out of vogue or a new concept comes around that is better then what they currently use? Will they keep requiring their tech talent to hold this outdated syntactical knowledge or will they hope that their talent would re-conceptualize the problem in the new language or new toolset?

Hire for concepts not for syntax.