3 types of Programming Interviews that get you nowhere 

A clown with ideas

As a veteran programmer who has worked on not so remarkable number of technologies, I have quite some range of experience on the technical programming interviews I faced in my career.

Those were the interviews I lost out — literally failed to nail the offer or proceed to the next round. But that was acceptable outcome. What was worse was the fact that:

  • On the technical expertise scale, they taught me nothing. Off course there were things I screwed up during problem resolution but none of that was unsolvable within hours past the interview time.
  • On the experience scale, what they gave me fell on the negative integers range. In other words, whatever I learned from those interviews impacted me negatively during my forthcoming interviews. I became part of vicious cycle of interview failures.

Here the list goes. I hope you can relate (although there is little you can do about them):

Checklist Programming Interviews

They have a list of one-liners to ask, and you must simply check their boxes, in order to proceed to the next round.

They are strongly opinionated. They are not interested in knowing your reasoning about why you don’t follow Agile, why you don’t write tests (before you have written a single line of code) or why you don’t attend bi-weekly office party. They simply record your Yes or No and push you towards the next round, or throw you out of the glass window.

I have at least failed 6 interviews for my candid acceptance of not writing tests in my professional projects before I started coding, even though I demonstrated how to write them on my Github. (and they deliberately chose not to look at it.) I wanted to tell them that sometimes it was beyond the scope of my timelines defined by someone else, just to observe their denial on face.

I could have simply slipped through those iron gates by lying my way through, by making a list of all formal yes-nos. But upon hindsight I considered the possibility that they anyway would have shortlisted someone else, and they simply needed a reason to strike me out.

It wasn’t advisable to fall into the booby-trap of lies to satisfy those opinionated judgemental crooks — I decided.

Which brings me to the next category of crooks.

Wikipedia Programming Interviews:

This is another variation of the Checkbox, but this time it’s about tools, instead of processes.

They expect you to know every tiny details about the tools you use, language versions, IDE versions, OS patches, plugins, IETF standards and so on. And they recite it like head priests as their teammates watch you fidgeting.

I have attended interviews wherein those have been the only technical questions I get asked. No algorithm, nothing about SDK APIs, nothing architectural! The moment you face such a question, you know you are going to lose out.

Sometimes there is not-so-fair rational behind these questions: The version in question has some interesting and well talked-about feature / issue that are being discussed in online forums. So how could I not know about them while the interviewer had a chance to read them fully the previous night?

On the contrary, sometimes it is just a recollection problem. Those very tiny details that you fail to recollect are demonstrated by yourself — in your Github or blog. And it maybe completely possible to miss out, given the enormity of your own work.

But they simply choose to see what you remember in front of them, without researching you beforehand. There is rarely any communication from interviewers’ side past interviews, even if you intend to follow up about any details you missed out.

You keep rolling out your websites and apps while effectively tackling those version compatibility issues, but not knowing about them during the interview time costs you — not only that opportunity, but some serious motivation for the next interview (you will end up spending your nights recollecting those versions instead of practicing programming exercises)

TextBook Programming Interviews

Just another variation of Wikipedia type, but here it tries to test vocabulary of the technology / programming.

  • Why destructor is virtual in C++
  • How polymorphism works in C++
  • How to search an element within a sorted array
  • What is diamond problem
  • Compare Big O complexity of each data structure for search

While it is reasonable to ask those questions at entry level, the expected answers simply involve uttering certain words by the candidate, without fully conveying the meaning.

Somewhat experienced and ivy league school interviewers want to flaunt how knowledgeable they are during programming interviews. So they rely on brain teasers that are often quite far from the average programming tasks being performed in the company:

Even with exceptional problem solving ability, you can only solve it comfortably if you have been through puzzle’s solution. For #3, those who have seen Die Hard with Vengeance have an unfair advantage!

Off course, they keep telling you that they are trying to measure how you solve it, not what you get at the end. But observing how you solve it leaves a lot to interviewers’ subjective discretion, and is easier said than done.

Exceptionally creative programmers maybe able to drive the interviewers with their unique storytelling. For the rest, someone who just stumbled across the puzzle and solution beforehand can easily fake it until successful solution.

Conclusion:

They say it a lot:

Every failure teaches you a lesson.

However, interviews trying to stereotype candidates as avid internet junkies, textbook worms or puzzle solvers only teach one thing:

Learn to ignore such failures, and keep going without learning wrong lessons.

There are no right or wrong answers in the interview. But there is very little, universally agreed material for interviewers on how to measure a candidate’s approach.

In the process of weeding out false positives, short-sighted interview judgements end up ignoring true positives who have successfully built and shipped products, but simply missed to do their bit of interview research.

Successful interviewees who cracked it are often hailed for their hard work (of coming across the right sort of problems)

The end result is that more and more job aspirants contribute enormous interview data to forums to help their fellow aspirants, while the interviewers are pacing ahead at snail’s pace, letting in all the lucky positives.

It will continue as long as it’s a buyers’ market, but that is changing, and will be visible during the next decade.