Job interviewing in general is a nerve wracking affair, but I think there’s a special terror reserved for technical job interviews.
If you work in information technology, you will most likely have endured grueling technical interviews during your professional career.
Having been around the IT block, I’m honestly surprised that companies and organizations are able to attract quality candidates with the dismal way so many companies interview job candidates.
Maybe DESPITE the sad state of technical job interviewing, quality candidates still somehow manage to navigate through the painful process of bad technical interviews.
Yet companies are not doing themselves any favors with these kinds of technical interview strategies that I continue to see (and experience) to this day:
“The SAT interview” – Almost like the old fashioned computer cards I had to fill out as a kid. You know, the ones with the multi choice answer bubbles you had to fill out with your #2 pencil?
You fill out a set of multiple choice questions and you answer them as best as you can.
And hopefully by the end of the test, your interviewers will somehow …. glean that you’re a perfect fit for their job opening??
I really don’t see the logic here. The only possible benefit I see out of this type of interview is perhaps weeding out the truly unqualified candidates. But even that is questionable, when we all know googling for even the trickiest of questions, is only a few keystrokes away!
“The Trivial Pursuit interview” – I’ve been in quite a few of these kinds of interviews.
I’m guessing the way the interviewers prepare for what I like to call “trivial pursuit” interviews, is to grab the nearest technical reference book off their bookshelf.
If it’s a Java developer gig, they’re going pull the Java reference library book off their shelf. If it’s a .NET C# developer job, they’ll get the .NET reference library book off the shelf.
I’m guessing next, they’ll flip through the table of contents for each chapter, and start jotting down key sections they think would make great interview questions.
Like how big can a unsigned integer data type value can be? How about a long data type value?
Or the difference between value type and reference type?
Sure, it’s better to know these things that not know these trivial pursuit questions. But are they that crucial to your day to day job requirements? Could they be answered with a quick google search?
What skills does knowing these trivial pursuit technical questions prove, beyond rote memorization skills?
Yet a lot of interviewers seem to LOVE doing these types of interviewers, almost to the point of RELISHING asking these types of questions to interviewees. Power tripping maybe?
“The Whiteboard interview” – One of my technical interviews, consisted primarily of coding up a solution on a whiteboard. Coding a solution to the classic Fibonacci sequence, to be exact.
Here’s where I believe we finally make some traction on our ideal interview.
If you’re interviewing for a software developer position, it’s only logical you prove you can code. Period.
What’s the first thing contestants who get chosen to audition for American Idol are asked to do?
They’re asked to SING in front of a panel of judges, and get judged on the quality of their singing.
In a technical job interview, your interviewers want to know if you can actually code.
“The Algorithm Interview” – These kind of interviews test your knowledge of computer science curriculums. Many times, they want to know if you can prove you underwent a classic computer science curriculum … for example, can you code up an implementation of a linked list? A double linked list? How about demonstrating you can show how to implement a binary search tree?
The Flaw Behind These Kinds of Interviews
What I believe is the primary flaw behind these kinds of interviews is twofold.
- Multiple choice and trivial pursuit interviews only prove you can memorize things.
- Whiteboard and algorithm type interviews may demonstrate you can think on the fly. But you’re under time pressure. And you’re under the stress of trying to remember how to code when you don’t have the resources of google and other developers at your fingertips.
The Ideal Interview
My ideal interview is a homework assignment.
The homework assignment should be very open ended. Let the interviewee choose any programming language of her choosing … ruby, javascript, c++, swift, java, anything.
The homework assignment should be very straightforward and easy to understand.
Say, something like “Your homework assignment is to code a solution to a simple problem. Open up a text file and display it on the screen.”
I can already hear many of you out there shout, “Hey, if you let the interviewee work on it overnight, all they have to do is google up the answer!”
And that’s true, you will likely find a technical solution to the problem, if you spend enough time at a search engine.
But that’s not what the homework assignment is testing.
What I want to know is if a developer knows how to go beyond coding up a quick and dirty coding solution to the problem.
Is the code clean and easy to understand? Are the functions and method names straightforward and convey the intention of the code behind those functions?
Is the code testable? Did the developer write any unit tests that demonstrate the code works as designed?
Is the code loosely coupled? Did the developer write logical classes that benefit the application? Did the developer show and demonstrate the concept of dependency injection and inversion of control?
There’s even a term called SOLID principles, which are guiding principles that help any software application to be well designed.
It’s pretty easy, as an interviewer, to spot the fakers and those who SOUND like they can code … just keep hounding the interviewee about what they coded and why they coded something a certain way. Only the truly technical folks will be able to elaborate and explain what’s going on in the homework assignment.
Conclusion
This is what technical interviews SHOULD be gauging. Not the code per se. But the concepts behind PROPER software design.
Anybody can eventually learn how to code, given enough time and resources.
But the software developer I personally want on my team, is the person who doesn’t just slap code on the screen. It’s the person who CARES about proper software design.
SOFTWARE CRAFTMANSHIP.
