Applied Hunter’s Law: Interviewing for a Job in Tech

For better or worse, I tend to field a lot of questions around how to perform a technical interview. It is a rough life out there for people looking for work. Especially without a college degree, or relevant experience in the field.

Getting to that point is a daunting personal excavation of pride. Plus a willingness to put on appearances, all while managing stress.

I always tend to binge eat.

The most common question always comes down to: Do you think it would look bad if: [something they did]?

The technical interview is a deranged bog of interpersonal, cultural ritual. A hall-of-mirrors waits for each candidate, for intellectual warfare waged in engineering cultures.

Strategies at important sounding brands become myth. They get posted to webpages of startups, designed to share the information. These convoluted traps are purpose built: to force the prospect into mental circles or wild speculation.

Worse still are the whiteboard sessions. Horror stories abound: reversing list entries, red-black trees, serialization routines, and linked lists.

This is an abattoir of confidence. The design of it is to churn through candidates. With little to no preparation or relevance to the expectations of the work or area of study.

Imagine you’re a medical doctor, seeing patients at a clinic. Each one files in and tells you they’re ailing from a problem with their elbow.

After a few hours of diagnosing the symptoms, the patient brings up their fear of balloons. Once you’ve assured the patient that helium is an inert gas, a wave of relief washes over their face. They thank you, say they’ve been cured, and leave.

Interviews are suffering through someone else’s deductive logic puzzle, and you can only figure it out by asking about the dynamics of helium, and you must write your solution in braille. Sometimes, you have to power through the absurdity.

Hyperbole aside, my advice usually falls into the application of Hunter’s Law, a thing I have said before.

Technical interviews are more about understanding the perspective behind a pointed query, making some honest assumptions, and figuring it out.

If you’re asked to figure out a system that allows you to predict when the bread needs to be ordered from the baker at a supermarket, you have to rely on empathy, more than some preconceived notion that there is a technical solution to every problem.

I’ve heard the phrase “the world is math” many times before, but interviewing is an exercise in empathetic skill, than memorized algorithms.

Even to the programmers, system designers, and all of us partaking in this absurdist illuminati parody.

First of all, forget the idea that you cannot state that you don’t know the answer to a question. I’ve been in this industry for — dear lord — two decades now. Doing any technical job at a high level hypothesizes about information, validates it, and communicates their ideas.

The problem here is not that you don’t know the answer, it’s that you haven’t got it memorized. Being honest about that, and talking about your methods is now your goal. If you’re asked how to work out a system, you should talk about (and make assumptions about!) about how that system might work. This is not failure, as you’re able to prove proficiency. This is a useful a judge of capability rather than a memorized sorting algorithm. This is, for lack of a better term, the “or relevant experience” bit of your resume. You should expect it to happen.

And besides, you would end up googling; for correctness. On any complex algorithm. Trusting our puny little dumb lizard brains for correctness is foolish.

Further still, you’d need to test your solutions for correctness anyhow.

A butcher relies on a good scale more than a sharp blade, for business to be efficient. The sharp blade is only a method of making the scale more effective and consistent. Hunter’s Law applies here too; How do you make a steak? Start cutting.

Second, keep a discussion going during your routine. Any technical leader I’ve seen work their magic is comfortable leading discussion. Practice the concept of inclusive knowledge. Share ideas about system design, decision making, and institutional knowledge. Don’t ever be afraid of asking a question of your interviewer. This sort of skill in exceptional demand.

Leading a discussion is one of the most difficult things to do well in our industry. We don’t emphasize this in training or in usual practice. It is more of an assumed skill of what you must do if you are to become a “leader”. This is a serious industry cultural problem. In any team, where everyone is doing a little bit of everything all at the same time, this can be fatal.

Pulling the expectations out of your interviewer should be the first thing you think about during an interview. Remember — the subconscious expectations on you boil down to: How resilient are you in a chaotic situation? Is the thing they’re asking you to design, or to talk about, or to diagram mission critical, in your mind? If not, I’d suggest a change in perspective. It’s likely they are looking to see if you’re comfortable or not with that chaos.

Finally, it’s important in any discussion about empathy and discussion to mention honesty. You can grenade your chances when you assume you can deceive an interviewer. Having been an interviewer, this is more often than not a death sentence. Any attempt at being clever will come across as a parent hearing a knock knock joke for the 10th time over dinner. Outright deception is rarely, if ever, called out.

Honesty in this context, is matching expectations. Don’t have a resume with four pages of job history. Don’t list every single application or tool you’ve ever read about on your resume. My resume is a one page, two column design.

I stole it back in 2003 from a flash designer. The flexibility of two columns has adapted time and again. I want to get across two things people want to know: What have you done and how did you do it?

Please, feel free to rip off my resume. Talk about what you do and who you did it with, and find out what your accomplishments were_. This is why you have a resume._ Think of it this way: If you end up getting asked about your job history in your interview, you resume didn’t tell a story.

I don’t even look at myself as a “programmer” anymore. I’m a writer. All programmers are writers. I am fluent in several languages, but whichever one I use to communicate with other human beings? That one should be my primary one. I should expect to use that more than any other, and with the most skill.

We all would do well to remember that computers are dumb little human creations. They’re designed by humans, for humans.

Good luck out there, it’s a real thicket.

If you’d like some advice on how to become a better interviewer, or a quick and dirty critique of your resume, send me a note on twitter — I’ll do my best to help.