Don’t Ace the Technical Interview, Circumvent It

by Jason Swett,

I’m a fairly lazy person. I also value my time dearly. For these two reasons, I’m always looking for how I can get the biggest possible results for the lowest amount of time and effort.

Below I’ll share how I’ve applied this philosophy to technical interviews.

The One Answer That Interviewers Are After

Why do employers interview prospective employees before hiring them? It might seem like a silly question because the answer is so obvious but I think the question is worth putting a precise answer on.

If you want to get really good at interviewing, it seems worthwhile to me to try to gain a deep understanding of everything to do with interviews, right down to the reason interviews exist. Here’s what I think the answer is.

Employers interview prospective employees because they’re looking for an answer to the question: Can we trust this person to do the job?

Just to making things extra clear, let’s take a quick second to define “trust”. Let’s say my car needs a brake job and a friend of mine offers to do it for me because he needs some extra cash. In order to let my friend do my brake job, I’d need to trust him in two different ways. First, I’d need to trust him not to just steal my car. Second, I’d need to trust that my friend actually knows what he’s doing so he doesn’t fuck up my car.

A job interview is mostly concerned with the “do you actually know what you’re doing?” kind of trust as opposed to the “are you going to steal my car?” kind of trust.

The way I see it, there are at least three ways to get an employer to trust you enough to hire you. One way is to get rigorously interviewed and answer a whole bunch of technical questions. The other two I’ll describe below.

“Anybody Dave Likes Must Be Good”

One way to get “auto-trusted” is to get referred to an employer by somebody who already works there.

Let’s say you have a friend named Dave who works at a company called CodeFuckers. Dave’s boss says, “Hey guys, if you know of any good engineers could you let me know? We really need some help around here.” Later that week, you and Dave talk as you occasionally do, and Dave says, “Oh hey, CodeFuckers is looking for more developers. Do you think you might be interested?” You say yes, and Dave passes your contact info along to his boss along with his endorsement of you.

Trust has an interesting way of being extensible. Because Dave’s boss trusts Dave and Dave trusts you, Dave’s boss automatically trusts you to a certain extent. Dave’s boss calls you in for an interview and, when you meet him, he says, “Hey [your name here], nice to meet you. Dave has said some great things about you. We think Dave is awesome and anybody Dave likes must be good.”

So without talking to you or asking you a single question, Dave’s boss already has a positive opinion of you.

How to Meet People Who Can Refer You

You might say, “That’s great, Jason, but I don’t know a lot of people who could refer me.” That’s a fixable problem. The solution is what some people might call “networking”. Don’t be put off by that word, though. I think you’ll find my form of networking to be fairly palatable.

Whole books have been written about networking, and a thorough discussion is outside the scope of this article, but I’ll give you a few quick tips.

One of the easiest and most effective ways to meet developers who could refer you is to attend local user groups. You’re probably aware that such user groups can be found on meetup.com.

In order to form relationships out of these user groups, you’ll have to actually talk to people. If that’s not your strong suit, I’d recommend picking up the book How to Win Friends and Influence People by Dale Carnegie. Don’t just show up at the start of the talks and leave immediately after. Show up a little early and stay late. Get to know the organizer.

The most effective way to take advantage of local user groups is to give presentations. If you give presentations, you’ll be seen as an expert. You’ll go from being an anonymous face in the crowd to a trusted member of the community. Important tip: don’t put off presenting until you feel ready. Just start now. You don’t have to be an expert before you can teach the group something they don’t know.

One time I found myself having a conversation with a prospective freelancing client. He told me he didn’t plan to give me a technical drilling since all his employees knew me from technical meetups and gave me the thumbs up. If you do the same thing, you can have the same experience.

“Obviously You Know What You’re Doing. You Wrote the Book.”

The other way I know of to “grease the chute” on trust is to build an Authority Piece.

The absolute best type of Authority Piece is a technical book published by an actual publisher (as opposed to, e.g., a self-published e-book).

It’s actually not as hard to get a book deal as you might imagine, but it’s definitely still a lot of work to write a technical book. If you don’t feel quite ready to go down that path right now, I completely understand. I personally have no plans to ever write a published technical book.

One of the next best types of Authority Piece is a self-published e-book. I’ve done this myself. I wrote an e-book called Angular for Rails Developers.

Being the author of an e-book hasn’t attracted a lot of prospective employers or freelancing clients to me but it has certainly helped in the situations where I found myself already having a conversion with a prospective freelancing client. (You can replace “freelancing client” with “prospective employer” and all the principles are still the same.)

Once I was having a phone call with a prospective client. He told me he wasn’t going to ask me a bunch of questions. He said, “Obviously you know your shit on Angular. You wrote a whole book about it.” I never had to claim I was an expert or sell myself in any way. My prospect just assumed that I was an expert because I had written an e-book.

An e-book can be relatively easy to produce compared to a published book. People expect a published book to be hundreds of pages but an e-book can be pretty short. I think the first version of Angular for Rails Developers was something like 50 pages. No one complained about the length.

But maybe even an e-book seems a little too big an undertaking to consider right now. That’s okay. You have more options.

Probably the next best thing after an e-book is a focused technical blog. Notice that I say focused technical blog. A lot of developers maintain blogs that are all over the map technology-wise, thus not capable of seizing the interest of any particular person.

The content on AngularOnRails.com is almost 100% Angular + Rails. (A very small portion of it is just Angular or just Rails. None of it is, for example, Java.) For that reason, if someone is working on an Angular + Rails project, everything on the site has a shot at being interesting to them. That’s what you should be shooting for.

The last Authority Piece I’ll mention is speaking. Speaking is of course not a “thing” but an activity. Each individual talk you give is its own authority piece. Some talks are more valuable Authority Pieces than others, and some talks’ value is longer-lasting than others.

For example, an off-the-cuff tech talk at a local meetup has a relatively small amount of value and its value is fairly fleeting. It won’t be remembered two years from now. But if you give a talk at a national conference that seriously strikes a chord with people and ends up being widely shared, then that talk is going to be a hugely valuable Authority Piece for years to come.

A Final Note About Technical Competence

I feel compelled to say a certain something to pre-empt the dumbass Hacker News commenters. (Important side note: I’m not saying that all Hacker News commenters are dumbasses, just a large number of them.)

I’m not advocating these tactics as a substitute to actual technical competence. Yes, you should know what you’re doing.

My perception is that technical interviews are often a test at how good you are at technical interviews, not a test of how good you actually are as a developer. So if employers are trying to make you play a dumb game that doesn’t make any sense, my opinion is that it’s totally okay to try to bypass that game.

Leave a Reply

Your email address will not be published.