16 ms·

As much as people like to deride #1 (here and elsewhere) it's one of the most useful filters (in terms of filter value for effort spent). It's not a positive fi

by cletus 15y ago

As much as people like to deride #1 (here and elsewhere) it's one of the most useful filters (in terms of filter value for effort spent). It's not a positive filter (in that a candidate who passes won't necessarily be a great programmer) but it is a great negative filter (a candidate who fails almost certainly isn't). #2 I have mixed feelings about. A lot of people work on things where the source code (even the product) isn't visible. Having an SO profile is semi-useful but lack of one doesn't really mean anything. Github only makes sense if you work on open source (and frankly I'm tired of the incredibly naive "Github is the new CV" postings that pop up every few weeks). #5 is what I really object to. At least in this case you've gone through the initial filters. Some companies use an audition project as an initial filter before you've ever spoken to anyone (you know, to see if you'd be a cultural fit and so on). I have zero time for this. The problem with an audition project is that anyone truly good won't have to jump through those kinds of hoops. They'll have their pick of offers as is. Job seeking through a traditional (non-network) route is relatively low percentage such that there's only so much time worth investing in any particular position. I'm happy to prove to you know I have a solid enough foundation in data structures and algorithms, I can program my way out of a paper bag and I can problem solve and communicate effectively but as soon as you ask me to spend a week--even a day--on some audition project, forget it. Honestly, hiring isn't that hard. You just need people who are good at hiring to do it. I've done 10 or so "lunch interviews" at Google this year. This isn't an interview per se. It's simply taking someone to lunch in between their onsite interviews. It's a chance for the candidate to unwind, ask some questions, etc. But there is no feedback element to the process. Of the 10 after 10 minutes I predicted 8 wouldn't get hired, 1 would and 1 I wasn't sure about. Turns out the "yes" declined an offer and the "maybe" didn't get one and I was otherwise right. And this is simply from going to lunch with them. My formula is: 1. Filter early. "Hello world" and other simple programming tests; 2. Establish technical foundation and problem-solving ability (with one algorithm-related question that should be coded); and 3. Otherwise ascertaining personality/cultural fit. This you should get just from talking to someone for 10-15 minutes. It's really not that hard. You just need someone who can actually do it to do it.

deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
georgieporgie 15y ago
Of the 10 after 10 minutes I predicted... Having visited the Google SF campus once (and knowing a number of Googlers), I picked up on a certain monoculture. This makes me question whether you were objectively picking out good and bad candidates, versus intuitively deciding whether someone will fit in the Google clique.
- xtracto 15y ago
  >versus intuitively deciding whether someone will fit in the Google clique. Which I thing is also very important. Imagine making your current colleagues work with someone that just does not fit! everybody might become miserable. Also, one point I did not see mentioned, and have not seen in any interview I have taken is code reading. If I were looking for a colleague to work in my project, I would give him two or three pages of code from my system which I think are "interesting" and ask him to tell me what it does and some other stuff he observes. It is most likely that reading the current code is something he/she will be doing at least in the beginning, I would like to make shure she knows how to read code (extra points if it is a language she does not write in, but can grasp the idea of what happens).
- Estragon 15y ago
  > a certain monoculture I'm curious about the common characteristics you saw in people there.
- larsberg 15y ago
  > deciding whether someone will fit in the Google clique That can be shockingly important. You can be a great developer, but still not a good fit for a company. As an example, I saw several employees top-out at relatively low points at MSFT but then go to Google and have heard back that they have done shockingly well. I would bet that the reverse is also true. Some of the best interviewers I've had on my loops were people who had a great grasp of whether a person was not only smart, but whether they would be successful long-term (e.g. if this entire division got killed, would they still do great work elsewhere in the company?). While I can't characterize hire/no-hire decisions for old legal reasons, I can certainly say that many of the people who struggled at MSFT but excelled at Google favored closed-door remote-work style hacking over personal interaction code-design. One style is not necessarily better than the other, but for people who can only work in one mode or the other, they will find themselves career-limited in the long term if they go someplace that does not fit with their work style.

by cletus 15y ago

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

georgieporgie 15y ago

Of the 10 after 10 minutes I predicted... Having visited the Google SF campus once (and knowing a number of Googlers), I picked up on a certain monoculture. This makes me question whether you were objectively picking out good and bad candidates, versus intuitively deciding whether someone will fit in the Google clique.

xtracto 15y ago
>versus intuitively deciding whether someone will fit in the Google clique. Which I thing is also very important. Imagine making your current colleagues work with someone that just does not fit! everybody might become miserable. Also, one point I did not see mentioned, and have not seen in any interview I have taken is code reading. If I were looking for a colleague to work in my project, I would give him two or three pages of code from my system which I think are "interesting" and ask him to tell me what it does and some other stuff he observes. It is most likely that reading the current code is something he/she will be doing at least in the beginning, I would like to make shure she knows how to read code (extra points if it is a language she does not write in, but can grasp the idea of what happens).
Estragon 15y ago
> a certain monoculture I'm curious about the common characteristics you saw in people there.
larsberg 15y ago
> deciding whether someone will fit in the Google clique That can be shockingly important. You can be a great developer, but still not a good fit for a company. As an example, I saw several employees top-out at relatively low points at MSFT but then go to Google and have heard back that they have done shockingly well. I would bet that the reverse is also true. Some of the best interviewers I've had on my loops were people who had a great grasp of whether a person was not only smart, but whether they would be successful long-term (e.g. if this entire division got killed, would they still do great work elsewhere in the company?). While I can't characterize hire/no-hire decisions for old legal reasons, I can certainly say that many of the people who struggled at MSFT but excelled at Google favored closed-door remote-work style hacking over personal interaction code-design. One style is not necessarily better than the other, but for people who can only work in one mode or the other, they will find themselves career-limited in the long term if they go someplace that does not fit with their work style.