4 ms·

Sometimes the company has a good reason for wanting an NDA. In that case, it doesn't indicate a company you wouldn't want to work for. Google has NDAs on inte

by dspeyer 15y ago

Sometimes the company has a good reason for wanting an NDA. In that case, it doesn't indicate a company you wouldn't want to work for. Google has NDAs on interviews mainly because we want the questions to be surprises. Coming up with good questions is hard, and we don't have a enormous pool of them. If every interviewee went home and blogged them, soon anyone who wanted to ace a Google interview would just need to read a bunch of relevant blogs.

trevelyan 15y ago
I wasn't aware Google had such asinine interview policies. Assuming the questions reflected things people needed to know for the job, having them publicly available would surely only increase the caliber of applicants and make it easier to weed out unprepared candidates. Being consciously protective of interview questions in order to stuff people into a one-size-fits-all interview process? No wonder search quality is degrading.
- jrockway 15y ago
  We want people to know all computer science (etc.) topics, not the exact four-hours-worth we happen to ask in an arbitrary interview. The idea is to randomly sample your knowledge, not to have you study and recite the answers to a few questions. It's an imperfect process, yes, but I'm not sure how this is one-size-fits-all. Giving you the questions beforehand would be a one-size-fits-all interview; we would see how well you study for tests. By asking practical questions that apply your knowledge of programming, we can see how you'll actually do your work. And, interviewers are not robots; if it's clear you don't know something about obscure category X, we'll move the discussion in the direction of something that you know about. I know nothing about document classification, but I know a lot about "code health". So my interviewers asked refactoring questions instead of document classification questions. It's a pretty flexible process, and most of the people I've talked to about it seem to like it. It seems scary at first because you don't do many graph traversals in your day-to-day work. But once you get up to the whiteboard and start thinking, you realize, "wait, I do know this stuff". And that's what the interviews are designed to do: skip the easy stuff that we know you know and see how you answer questions that are just out of reach. (I learned a lot from my Google interviews, and was actually slightly surprised that I had been hired. At the interview, I had a lot of new questions to think about, and I learned a lot in the form of hints from the interviewers. All in all, a great experience. Better once I knew I'd been hired, though :)
  - deleted 15y ago
    [deleted]

by dspeyer 15y ago

trevelyan 15y ago

I wasn't aware Google had such asinine interview policies. Assuming the questions reflected things people needed to know for the job, having them publicly available would surely only increase the caliber of applicants and make it easier to weed out unprepared candidates. Being consciously protective of interview questions in order to stuff people into a one-size-fits-all interview process? No wonder search quality is degrading.

jrockway 15y ago
We want people to know all computer science (etc.) topics, not the exact four-hours-worth we happen to ask in an arbitrary interview. The idea is to randomly sample your knowledge, not to have you study and recite the answers to a few questions. It's an imperfect process, yes, but I'm not sure how this is one-size-fits-all. Giving you the questions beforehand would be a one-size-fits-all interview; we would see how well you study for tests. By asking practical questions that apply your knowledge of programming, we can see how you'll actually do your work. And, interviewers are not robots; if it's clear you don't know something about obscure category X, we'll move the discussion in the direction of something that you know about. I know nothing about document classification, but I know a lot about "code health". So my interviewers asked refactoring questions instead of document classification questions. It's a pretty flexible process, and most of the people I've talked to about it seem to like it. It seems scary at first because you don't do many graph traversals in your day-to-day work. But once you get up to the whiteboard and start thinking, you realize, "wait, I do know this stuff". And that's what the interviews are designed to do: skip the easy stuff that we know you know and see how you answer questions that are just out of reach. (I learned a lot from my Google interviews, and was actually slightly surprised that I had been hired. At the interview, I had a lot of new questions to think about, and I learned a lot in the form of hints from the interviewers. All in all, a great experience. Better once I knew I'd been hired, though :)
- deleted 15y ago
  [deleted]