My view is that you can't have competence at a certain level without confidence - unless you're just an easily outsourced code slinger. I'm often at a whiteboard explaining architecture, ideas, etc. How do you do that without confidence and some semblance of emotional intelligence.

There is really no comparison. Explaining architecture, ideas etc to your colleagues has pretty much no resemblance to a whiteboard interview, where you have several people staring at you and judging you. One is a discussion the other is a test, they compare like having a beer with a colleague is like holding a speech in front of a bunch of stranger.

When I'm the only developer talking to managers, directors, etc. I'm constantly being judged by whether I have good ideas and whether I can be trusted to architect a solution.

May be I am a little overconfident, but I always go into an interview and treat it as a formality to getting the job. By the time I'm in front of the whiteboard, I've already spoken to the recruiter and know what they are looking for, seen the job req to know what technologies they care about, and I've had a phone screen. Why wouldn't I be confident?

One thing I've always been curious about is why folks are so afraid of being judged. Most people are judging you all the time, yet recognizing this fact causes a lot of people intense anxiety. I'd rather look at it as a selection filter: if someone doesn't like you or doesn't want to work with you, that's a strong signal that you'd be better off not spending any more energy on them, and instead focusing on the folks who do like you & want to work with you.

When an interview is not a discussion, but rather a test, it is a bad interview.

Now that I think about it, I wasn't asked a single programming question when I was interviewed for the job I have now. I was asked architectural, process improvement, soft skill questions. That's probably why I chose the job I have over other offers. It was more of a discussion and by the end of the interview, I was joking around with the hiring manager and said something to the effect of "I'm already assuming I'm going to get the job. When am I going to hear back from you?" He started laughing and said soon.

Another interviewer told me at the end of the interview to submit an application and they can get an offer emailed to me by the end of the day. We did a collaborative white board design session and spent a lot of time just talking.

Either all of the job offers I've gotten have been mostly just discussions or I talk tech so much I can't tell the difference between an interview and a typical day at the office.

Most interviews I've been to have been the same. I was talking about the ones where you have to solve some tricky algorithm questions at a whiteboard while someone is staring at you. I have no problem doing that in front of my colleagues, but find it difficult to do at a job interview.

We've had similar experiences. For the vast majority of jobs across all industries, the last deciding common denominator question that seals the deal is "Can I see myself having a beer with this person?"

Well, for a random employee of a random company there is no motivation to not haze people on the whiteboard, it's mostly a power play for them and oversupply of candidates permits it. They really don't care how good of an engineer they hire and how much value he can bring to the team or to the company.

I don't think that's true, actually. I've been both interviewer and interviewee, almost all my friends do interviews, and in every case I've seen, the interviewer is earnestly trying to make her best determination of whether you can succeed at the company. Most interviewers - both ones I know as friends and ones that have interviewed me - get very, very happy when they find a candidate that they know will meet the hiring bar, because it's such a rare occurrence.

I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective. Most people know that they're good programmers (whether it's true or not...), and so they're like "This is bullshit...why do I need to prove my worth at the whiteboard when I know that I'm a good programmer." But the cost of a bad hire is really, really high (both for the company and for the employee), and the applicant pool is skewed through adverse selection, and a company knows nothing about you when you come in to the interview. Many people with stellar resumes can't actually code; some that can code don't actually want to work with you and would be bad cultural fits; and some outright lie on their resume. They're trying to figure out, in a 50-minute hour, whether you'll be productive on the particular problems that that employer faces.

"I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective."

Actually, speaking of looking at it from the companies perspective, in 2010 google and several other big name silicon valley companies were successfully sued because they all agreed with each other not to cold call each others employees to try to recruit them. They actively worked to try to make it harder to switch jobs from one company to another.

Right after that, they started doing whiteboard interviews, which serve the same purpose of making it painful to switch companies, but without the risk of being sued.

Sometimes it's worth taking action to diminish a perception, even if that perception isn't actually true. Has Google considered the impact of the perception that their interviews are hazing?

Especially in the context of Google's public commitment to increase diversity among their engineers, it strikes me that revamping their interviewing process to eschew whiteboarding ought to at least be considered - it would be amazing PR for Google if they swallowed their pride and innovated in this area. And it would have a real effect outside Google, since so many companies' interview processes mimic Google's.

I'm not certain that an interview process without whiteboarding - or at least some other form of coding test - would actually be able to detect the skills Google needs in their interviews.

I see comments on HN time to the effect of "Why do I need to know how to traverse a tree or sort a trillion 32-bit integers? Why should I care about big-O notation? When will I ever use those skills on the job, when I could just Google for a standard library function?" I used those skills all the time when I worked at Google. When your data set is measure in petabytes, you can't just reach for a stdlib function, you have to actually know how the algorithm works, in depth, so you can implement it across thousands of machines. And any algorithm slower than O(N log N) is not going to work. Even in frontend work, I used tree traversals all the time because JQuery's byte cost was too high to use on Google services.

They have been taking other steps to increase diversity, though, like redacting names & genders on resumes, ensuring that every female candidate has at least one female interviewer, and trying to source candidates from non-traditional (i.e. non-Ivy-league, non-brand-name-tech-company) places.

Oh yes, they absolutely need a coding test!

Has Google innovated much in the interviews themselves in the last, say, 10 years? My perception is No. I get the impression that Google's old-fashioned process is a point of pride that they hang on to because it works (at least, the business is succeeding) and they are afraid of change. But it's a missed opportunity for a technical leader to advance the status quo in our industry.

For example, onsite, Google interviewers will still ask you to write code or pseudocode on the whiteboard. That's something they could re-examine (perhaps by giving an option of whiteboard or computer, and ensuring a level playing field between the options). They could get some good publicity from re-examining this, I think.

Posting a reply for @tsion, who seems to not be able to post at the moment:

I interviewed on-site successfully at Google Seattle about a year ago, and I was given the option between writing code on a whiteboard or in a text editor on a Chromebook, being projected onto the screen in the room, so the interviewers could easily follow without awkwardly looking over my shoulder.

Of course, I picked the text editor. I can't imagine wanting to write code on a whiteboard. However, I did use the whiteboard voluntarily as a thinking and planning aid.

Unfortunately, I also heard that the text editor option was only available at certain offices at that point. I really hope coding in a text editor becomes a universally available option because it's just so much more natural. It essentially put my mind at ease and helped me think more clearly.

On a more general note, my strategy, which seemed to work well for me, was to treat the whole situation like a pair programming task. Even though the interviewer won't directly tell you what to do, they will often comment on things if you question yourself out loud enough.