In my mind there’s one single key to interviewing successfully. Most job seekers are not only ignorant of the importance of this idea but they actually have it exactly backwards.

Most job seekers think they need to come to an interview prepared with answers. That’s true to an extent but it’s actually far more important to come prepared with questions. I’ll explain why.

Why It’s Smart to Ask Questions

Whoever is asking the questions in a conversation is the one who has the power in that conversation. If you’re controlling the conversation, you can steer it toward your strengths and the reasons why you’d be a good fit. If you let the interviewer control the conversation, you’re leaving it to chance.

Some companies really have their interview process down but from what I’ve seen, most companies don’t. It’s super common for an interviewer to sit down with an interviewee and not even have a single question prepared. They just ask whatever questions come to mind. Or even worse, they ask dumb questions like “What’s your proudest accomplishment?” because they presumably heard somebody else ask that question before and so figured it was a standard interview question. In my mind there’s no good reason to roll the dice by letting the other person ask all the questions when it’s totally possible to for you to take control.

Doing the Interviewer a Favor

By taking control, you’re actually doing your interviewer a favor. Often, the person interviewing you is a developer who sees your interview as a distraction from his or her regular priorities and for that reason has underprepared or not prepared at all. By taking control of the conversation, you’re lifting the burden of thinking of things to talk about from that person and putting it on yourself. You’re making the other person’s job easier. For this reason I pretty much never encounter resistance when I attempt to take control of the conversation.

How to Show Interest

There’s another reason it’s good to ask questions. Employers want to hire candidates who appear interested in the job. You might think “duh”, but you’d be surprised how many interview candidates don’t actually express strong interest in the job they’re being interviewed for. One way of showing interest is to actually say, “I’m really interested in working together.” I think that’s a good thing to say but I think asking thoughtful, intelligent questions is an even stronger way to express interest.

You might wonder what kinds of questions are good to ask.

Personal Questions

The best kinds of questions to ask in an interview are personal questions. This is because you don’t get interviewed by a company, you get interviewed by a person. It’s an individual person (or group of people) you have to win over in order to get hired.

Before the interview you should find out who will be interviewing you. (It’s totally normal to ask who will be interviewing you when you’re in the process of setting it up.) At best you’ll get a list of first and last names. At worst you’ll get nothing. Either way, there’s something you can do.

If you’re able to get the names of the people with whom you’re interviewing, google their names and see what comes up. You’ll also definitely want to check out their LinkedIn profiles. What are their roles? What are their work backgrounds? Where did they go to school? See if you can find anything interesting to comment on. See if you can find any commonalities. Take notes of all this stuff as you go.

If you can’t get actual names, you can make some guesses. You can try to go to the “About” page on the company’s website and see if there’s information listed there about their team. These links are often buried on the footer of the site. If you see some people there who might possibly be the people who are interviewing you, go through the research steps listed above.

How to be Interesting

I attended the Windy City Rails conference in, I believe, 2012. I was bored and antsy during one of the talks so I stepped out in the hall and started talking with the sponsors.

I met a guy named Mark who seemed pretty cool. I asked him question after question about himself and the company he worked for. After about 30 minutes into our conversation I had said almost nothing. I had only asked questions. Then Mark said, “You know, this is the most interesting conversation I’ve had at this conference.” The conversation was interesting to him because I allowed him to talk about the topic that interests him most: himself.

There’s a quote in How to Win Friends and Influence People that’s pretty relevant here: “To be interesting, be interested.”

There’s another relevant quote I’ll share here as well. Olivia Fox Cabane said in The Charisma Myth, “Don’t try to impress people. Let them impress you and they’ll love you for it.”

This is something else I think most interviewees have backwards. They go in thinking their goal should be to impress the people interviewing them. In reality your goal should be to make your interviewers like you, and one of the most effective ways I know of to get someone to like you is to show genuine interest in them.

So the takeaway here is to ask thoughtful, intelligent personal questions about the people interviewing you.

General Questions

Sometimes it’s too hard to come up with personal questions or the timing in the conversation isn’t right. In this case you can fall back on more general questions. Below are some of my go-tos.

Why do you want to hire a developer right now? What triggered this? This question is a good one not because it necessarily reveals some mind-blowing answer but it’s just a good question to lead with. It sounds natural to ask. “So, why are we talking right now?”

Can you tell me about your development team? Every company that hires developers of course has a development team. Or you’re their first developer. Either way, the question is relevant.

If you could wave a magic wand and make one thing happen right now, what would it be? This question reveals the biggest perceived problems and challenges in the organization right now.

Action Items

Make a list of questions you could ask at your next interview. And next time you have an interview actually scheduled, come up with a list of questions specifically for that interview.

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.