[uberPhil]

Sometimes I feel like it's a total crap-shoot with getting interviews at some of these large companies. There were quite a few positions available in the DC Metro area that I was probably more then qualified for or at least qualified enough to get a phone interview. Needless to say, I was never contacted. It's good to know that some people actually get to a phone interview :)

[marcog1]

The big companies get so many candidates that they can't possibly do all applications justice. So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen.

[barik]

"So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen."

This is probably the best piece of advice you can give for starting the job application process. Having an internal person already working in the company recommend you to HR will immediately put you on the top of the queue. At the very least, you'll get an initial phone interview quickly. This is, in fact, the only way that I've able to have successfully get in the door, at both small companies and also larger companies like Google and Microsoft.

The other option is the "career fair", but that tends to only work if you're still a student or near-student status.

[thinkdevcode]

Do you really want to be subjected to coding on a whiteboard?

Edit: Instead of down-voting, why don't you explain to me why you would want to code on a whiteboard when it's completely pointless. Might as well throw in some of those pointless questions like why are manholes round?

[jrockway]

Yes. I like it.

Whiteboard coding is good because interview questions are not about specific 100% solutions to complex real-world problems like programming usually is. Interview questions are about general problems whose solutions will fit nicely onto a whiteboard. You lose the ability to get realtime syntax highlighting, but you gain the ability to have multiple trains of thought, the ability to draw diagrams and arbitrary symbols, and the ability to point at things as you explain your thoughts to the interviewer. Do you really enjoy it when someone comes over to your laptop to ask you a question about code? Now imagine that for four hours in a row. That's what a laptop interview would be like.

When I was interviewing at Google, someone asked me a question that required me to remember some math. I did not remember it, but I knew how to derive the answer I needed. So I went to another whiteboard, talked my way through the sub-problem while drawing some math symbols, and then transferred the answer back to the original problem, halfway completed on a different whiteboard. Try doing that while hunched over your laptop.

I agree that this process is nothing like the job you're interviewing for. That's because it's an interview, not the job. We try to get a picture of who you are and what you know in a few hours, and that's just not enough time to let you loose with a laptop to see how you approach real-world problems. Not to mention, real world problems don't often involve much "computer science" knowledge. But you still need to know that so you can confidently attack problems that venture into that area.

And largely, the process works. There are very few programmers at Google that can't program. If I have an idea, I can explain it to pretty much anyone, and get good feedback. At other jobs I've had, I've had to explain thing like arrays to coworkers. That means I'm not going to get any feedback on my complex idea, and that sucks. Google is not like that, because we filter those people out at the interview.

[rimantas]

  > Try doing that while hunched over your laptop.

I just take a pen and a piece of paper.

[csallen]

Not too long ago I would have agreed with you, but I've recently changed my mind. Coding on a whiteboard is not completely useless:

1. It's a good indicator of how much you know for simple problems.

A few weeks ago I started helping a friend with a particular language and framework. He claimed to know it, having read several books on it. So I said great, go to the board and write a function that adds two numbers together. And he couldn't do it. Who knows, maybe he could have done it on a computer? Maybe he would have Google'd it quickly, or relied on code autocompletion, or the muscle memory from his fingers typing it, etc. But that's not what I wanted to know. Anyone who's written thousands of functions in a particular language could write a simple one like this on a wall, using paint, while hanging upside down. His inability to do so told me: he is not well-versed in this language. PERIOD.

2. You can practice.

"So what", you protest. "Google isn't going to ask simple problems. They'll ask hard ones." And maybe they will. And maybe having to solve it in a foreign way really will fuck you up. But my question to you is: If you know you're interviewing at Google soon, why the hell would you allow whiteboard coding to remain foreign to you? If you suck with whiteboards and you care at all about getting the job, then buy one and practice solving problems on it. Why would Google want someone who doesn't care enough to prepare for their interview? It's not that hard of a skill to pick up. And I daresay it will make you a better, easier-to-communicate-with programmer.

[zellyn]

"You can practice."

This.

If there was one thing I could tell all applicants at Google, it's to read up on the process, and practice. There is a huge amount of information out there[1]. I feel sad interviewing really smart, capable people who could have breezed through with just a few hours of review and practice.

[1] eg. http://courses.csail.mit.edu/iap/interview/materials.php

[jarek]

I imagine it must feel horrible interviewing smart people who would do great at work but whom you are unable to hire due to arbitrary hoops set up by your own company.

[bishnu]

This is true. However, the alternative is worse (hiring someone unqualified)

[thinkdevcode]

> 1. It's a good indicator of how much you know for simple problems.

Google doesn't solve simple problems.

> 2. You can practice.

Maybe if the interviewee was still in college they could "practice" coding on a whiteboard, but considering they may have other obligations like family and work they probably won't have time to practice such a pointless skill.

Personally, I wouldn't need to practice in the first place as I interview extremely well and could easily code on a whiteboard, I just find it antiquated and pointless to do so which was the reason for my comment - not because I am bad at it.

[csallen]

  Google doesn't solve simple problems.

Yes, but that doesn't mean you don't need to know how to solve them. If you can't solve simple stuff, you won't be able to solve hard stuff that depends on knowing the simple stuff cold.

  they may have other obligations like family
  and work they probably won't have time to
  practice such a pointless skill.

Yes, that's a possibility. But once again, if you're Google, you're getting 10s of thousands of applications a week. You can afford to set the bar as high as possible. Every Google employee I know regularly works 10+ hour days there, and sometimes does work at home, too. If you have two applicants of similar skill, but one has more free time to devote to your company, it's obvious who you'll prefer.

[jemfinch]

I work at Google. We write (diagrams and code) on whiteboards on a regular basis. We don't ask you to do it during an interview because we're sadists, we ask you to do it during an interview because working here, you will be doing it in the course of your ordinary work.

Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.

[varelse]

I worked at google for four months. That wasn't my experience at all. I ended up on a team that despite working in the same office, barely spoke with each other, rarely ate lunch together, lost 1 member for each month I was there, and I didn't even have a 1 on 1 with my manager until 3 months in when I asked him why he was having 1 on 1s with everyone else, but not me. It was the singularly most soul-killing work environment I've ever encountered. What is this strange concept of whiteboard coding and collaboration of which you speak?

The relevant job skill here would have been the willingness to do anything for the great pay and food. I wasn't and I had other employment options I chose after it became clear I would not be allowed to jump to another project anytime soon.

[tissarah]

I love working at the whiteboard -- my best ideas come while working at the whiteboard. But writing code on a whiteboard during an interview bears little resemblance to the code/diagrams written on a board during day-to-day work.

Day-to-day work is necessarily collaborative and productive... Whereas when at the board in an interview one person knows the "answer" and is across the table testing the other. It's a completely different set of pressures and requires different skill.

Further, I must have one of those faces people pity because its often that when I end up at the whiteboard the interviewer wants to "help" me if I don't spout off the answer immediately (I've learned to at least start talking so they will give me a second to think). This sometimes entails them trying to lead me down a path which is not the way I would have approached the problem. I'm confused, they think I'm an idiot, now I'm flustered, could this interview go any worse?

I've learned to politely ask for a second to consider and usually that completely solves the problem. I've been successful in technical interviews -- but the idea that it's the same thing as when working out hard problems with team members seems a little silly?

[bad_user]

      ... will typically code better with a keyboard and 
      editor than someone who relies on the keyboard 
      and editor to be able to code

The whiteboard sucks for problems for which you either don't know the solution, or for which you know the solution intuitively, but can't reproduce it line by line in successive order. In such cases people go back and forth, adding new functionality or correcting the existing lines to fit a new condition ... and this happens a lot for recursive algorithms. For instance I cannot reproduce the in-place QuickSort line by line, but I can work it out by evolving it from the basic idea, a process that takes a couple of minutes and a lot of corrections.

So you're basically encouraging people that rote-learn solutions and that line above is bullshit.

[andrewflnr]

Leave room between the lines so you can add stuff. Mark it up as you evolve it. If you need to, you can rewrite the clean version on another part of the board. Better yet is if you can figure it out in your head before you start writing, becaus that will definitely make you a better coder.

[jarek]

> Leave room between the lines so you can add stuff.

Startup idea: a device on which you can write code which you can subsequently edit by inserting, changing, moving around, and erasing lines

[thinkdevcode]

> Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.

That is very subjective and I'd love to see some evidence of this.

[dblohm7]

Once upon a time I was working with a psychologist who wanted me to do a take-home exercise. Knowing that I was a software developer and an excellent typist, she insisted that I perform the exercise while writing by hand. She said that it was because I would be using a different part of my brain when handwriting than if I were typing.

Which brings us back to the whiteboard interview. I ask: If I am correctly interpreting what the psychologist said, why force interview candidates to use their brains differently than they normally would while coding?

[jimbobimbo]

I can't downvote, but I fail to see what's the problem with "coding" on a whiteboard and why people are stressing out over it. When I interview people I ask them to write code on the piece of paper. All I'm looking for is a presence of a half-decent idea and them not using things like strlen() when iterating through a C-string in their doodles. The rest we will talk over. I never expect polished code on the whiteboard, it's always a starting point for a conversation that follows.

[Nick_C]

> not using things like strlen() when iterating through a C-string

At the risk of making myself look stupid, is that because of O(n) vs O(n^2) (should be testing for \0), or is there another reason I'm not picking up?

[jimbobimbo]

Yeah, it's just to see if a person understands that some basic pointer operations and that regular strings in C are "special" because of their \0 at the end.

[knieveltech]

I'm with you on this one. I don't get the whole whiteboard code thing and I have no idea why you're getting downvoted. :/

[uberPhil]

do employers really expect candidates to right syntax accurate code on a whiteboard? I just always assumed that pseudo-code was appropriate. There are a lot of key strokes that my fingers know but my brain doesn't. It's very easy to get confused and thrown off your game.

[ChuckMcM]

do employers really expect candidates to right syntax accurate code on a whiteboard?

Yes they do. I've still got my Google 'Hire Squad' t-shirt somewhere (when you get trained on how to do interviews at Google you used to get a t-shirt) And they expect the interviewer to transcribe what you write on the white board into your feedback so that the hiring committee can read your notes and know what you're talking about.

You see the part you've missed here is that at Google, the person doing the interviewing has nothing at all with the person deciding if you should be hired. They interview you, using the techniques they were trained to use, they transcribe the whole thing like a court reporter, adding what color they can and a float between 0 and 4 (0 is 'run way', 4 is 'walks on water') And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.

Writing syntax accurate code on the white board is always a plus. Although one candidate on seeing the dozen different color markers, wrote both syntax accurate and colorized code. That was good for a chuckle (and strangely I think it got them points in the committee).

[gcp]

And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.

Doesn't most of the personality of the person get lost in this setup? I mean, hiring people purely on technical merits may sound fine, but I'm not sure if that makes for a very pleasant working environment.

[jrockway]

Compatibility with Google culture is something that the interviewers are trained to look for. You can't do an interview until you've worked at Google for more than 6 months, for this reason.

I think the whole hiring committee removes a lot of biases that people may have and the end result, in my opinion, is a workplace that's a lot more diverse than any other I've been at.

[steffan]

I don't necessarily expect candidates to have perfect syntax for a given language. (there's a presumption that they would be able to look up correct syntax in practice) At the same time, if you're unable to express your ideas in something close to real code, it is a signal that you're not sufficiently familiar with the language you chose.

[robrenaud]

Excepting declaring funky things like arrays of pointers to functions in C, what competent developer doesn't know the syntax to his or her own best 2 or 3 languages?

There is a difference between forgetting to put a semicolon at the end of a line (totally harmless on a whiteboard interview), and not knowing that semicolons end statements in C.

Of course, not knowing say, part of the standard library, say the semantics of rand(), without a man page or Google search is much more excusable.

[thinkdevcode]

OR you can hand the applicants a laptop and allow them to write code, which is what they are going to be doing on the job presumably. or does Google develop their applications on whiteboards now? I'm thinking a Minority Report-esque digital screen that programmers drag/drop with voice activation to "code".

In all seriousness, I really don't get whiteboarding in interviews.

[bstpierre]

For whiteboard coding, I've always given interviewees their choice of programming language and have said, "Don't worry about syntax." For me it's more about how you approach the problem than whether you can spell correctly.

[grecy]

This is the most sensible reply here.

I code in a variety of languages and every time I use .indexOf(), I can't remember if it's (needle, haystack) or (haystack, needle). Of course, my IDE shows me the correct way and I go with it in 0.3 seconds.

On a whiteboard, if I were marked down for getting that the "wrong", I don't think I'd like to work for those kind of people anyway. I have no interest in memorizing the exact syntax of every standard library call in every language. When I can look it up almost instantaneously, my mental efforts are best spent elsewhere.

[cadr]

I think there is a difference between if you know the API the language provides and if you know the syntax of the language.

I don't care if they can't remember order of parameters, or really even the name of the methods. But if you can't write syntactically correct code without an IDE, it seems like a problem.

[cadr]

Probably depends on the employer. I've always asked people to write actual code, rather than pseudo-code, because I've found that a lot of pseudo-code I've gotten doesn't make sense or majorly glosses over things. (Think "and then a miracle occurs".)

But I personally wouldn't dock a person if they screwed up the syntax on a whiteboard coding interview - I really use it more as a way to extend the conversation. I do have the bad habit of correcting syntax, though, because I find it too distracting once I see it.

[matwood]

Coding syntactically correct code on a whiteboard is a waste of time. Drawing pictures, diagrams, and pseudocode while trying to solve a problem with others is a great way to get collaborative work done.

[djb_hackernews]

DC office is funny. It's so small it doesn't have it's own recruiters. The recruiters in Denver handle recruiting in DC. So if you want to interview, talk to them.

Also, if you do interview, keep in mind you'll have to travel to MV for a full day interview and also a full day interview in DC. Which is actually nice if you have the time; the DC team is so small that they want to be selective with future team members.

The DC projects were cool too, one was google code I believe, and the other was a tool to allow the collection of data sets such as water well tests in developing Africa, etc.

[varelse]

Google only hires 1 in 1000 applicants or so (at least that's what they tell you on day 1). Try not to take it personally that you failed buzzword bingo with their recruiters.

Perhaps someone should take a look at your resume to find out why?