Ask HN: Afraid of interviewing

It seems like you feel that you're afraid of getting rejected, but if you're turning down in person interviews, that seems like you're worried about the interview itself and not what happens after.

It's important to clarify because they're two very different problems. Turning down offers to interview is silly; if you get rejected from the job, you haven't lost anything (because you don't have the job now anyways) and you get the experience of interviewing. Based on how it went, you can then start pinpointing where your weak points are and start trying to shore them up.

Don't be so concerned about nailing the first interview out of the gate; interviewing is a skill like any other, and it's okay to need some practice.

This will ease your rejection fear, and train you to handle it.

You are doing absolutely the right things to succeed at it -- you just need practice at doing it live.

I've been rattled by every job interview I've had. That includes interviews for roles that I'd been courted for. It includes interviews for jobs I didn't even want, where I was interviewing mostly because a friend had asked me to. One of those interviews was for a company I actively disliked and would under no circumstance work for. I didn't sleep the night before! I did a multicast streaming media company in the late 90s and owned the router; later, I interviewed at a friend's company, got asked how to implement Towers of Hanoi without recursion, and for the rest of the day forgot everything I knew about routing protocols --- despite having spent the preceding two years doing nothing but implementing them.

Job interviews suck. They're hostile processes that involve complete strangers not just sitting in judgement of you, but also working under the delusion that their job is to break you so they can avoid hiring "B players".

I basically interview people for a living now and pay pretty close attention to this, and have come to the following conclusion: there is zero correlation between how people comport themselves in job interviews and their ability to do a job.

My best advice is, know the stuff you know. If you want to bone up on algorithms and data structures, don't cram. Implement them in your most comfortable language and watch them work, and go to the interview knowing not that you can recite them from memory, but that push-to-shove you can in fact throw down and get them working. Then just answer questions honestly.

The hardest interviews you take might be for the worst, most dysfunctional teams; a mean (or even just wicked) streak in interviewing candidates is a sign of broken teams, not weak candidates.

Good luck!

If you get stumped by a question, look it up when you get home.

There's a good talk on the subject from PyCon (https://www.youtube.com/watch?v=1i8ylq4j_EY).

Look at it this way, if you've really been developing that long, you're a fricken veteran. Unless you've been writing up TPS reports in Excel for 13 years, you've seen and used a wide variety of tools to build projects, and get things done. New grads may know the difference between a tree and a trie and how to optimally traverse each, but you know how to define a project, what to expect as you scope it, what types of tools tend to work best for different approaches, how to develop with an eye to scaling and maintaining, how to test things, how to deliver them to end users, and so on.

There are probably dozens of types of projects that I could ask you about in a social setting, and you could immediately deliver a 5-minute sketch of how to design and build them from scratch, pros and cons of various approaches, likely problem areas, etc. That comes from the experience of having lived it for a decade, and the confidence to recognize that you can do these types of things, because you have done them, and because you're smart and resourceful.

This sort of confidence in one's abilities is such an asset when interviewing. Just assess your skills, know what you can do, and talk like you know what you can do. Sure you don't know everything about these skills, but who does?

The thing about CS fundamentals and interviews focusing on them is just a lame facet of the industry. It's hard to assess complicated skills in a standardized way, so instead people ask about data structures and language syntax. It's like interviewing an architect by asking him minutia about specialty hammers, but it's just the way it is. Look at it as a flavor of FizzBuzz, read through some books on the topic. If you're asked such a question, try to get behind the question, see what the interviewer is really assessing, and speak to that out of your skill toolbox.

If you want some CS theory book recommendations, here are my favorites:

- "Cracking the Coding Interview" by Gayle Laakmann

- "The Algorithm Design Manual" by Steven Skiena

3 weeks ago, I had an interview at the big G. I wanted the job sooooo badly that I was insanely nervous during the interview. The interviewer asked me to write a piece of recursive code and I fell flat on my face. In my nervous state, I couldn't keep the problem and variables in my head. I had no concentration/focus whatsoever.

When the call was over, I did the task in about 20 minutes. No problem.

I DO NOT UNDERSTAND why coding under pressure, while someone is watching and judging, should be a part of coding interviews. Some people may be highly affected by the pressure. Others may have no problem with it at all. This means that people who are naturally more nervous are going to underperform lesser engineers who don't get nervous.

Now, if coding under pressure is part of the job, great. Then this method is appropriate. But it never is. Coding is a solitary, concentrated, focused effort. To test someone outside that natural environment is to not test them at all.

I honestly don't get it.