5 ms·

> " And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex que

> " And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test." And yet, I'd be surprised if almost all of those who didn't pass his "basic test" went on to be gainfully employed, and successful, building X app at X company instead of at Google.

wutbrodo 10y ago
That may be true, but I've never been at a company that was desperate enough to hire cargo cult programmers. Interview jitters aside (that's an unfortunate artifact of the coding interview), not having a grasp of loops, iteration, and the most basic of data structures is a low, low, low bar for "knows how to program". I'm not even being particularly picky here. Big companies can be notorious for hiring CS grads from great programs and never having them do any actual computer science, and I agree that that bar is unnecessary for good engineering. But this filter isn't _unrelated_ to the job of being an engineer (or even a code monkey!), it's basic, basic programming. I'd imagine it does a great job of removing the kind of candidates who are capable of trivially avoidable bugs that become time bombs down the road.
- uola 10y ago
  Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. Many of Googles products implode shortly after getting released making software quality irrelevant. Also many successful Google products were originally made by other companies, presumably with different hiring processes, that joined Google. That said, from what I've heard it isn't the questions themselves so much as the overall interview process that puts people off.
  - GrumpyYoungMan 10y ago
    >Hiring people based on things they won't use seems an awful lot like a cargo cult. Yes, but in this case, it's a cargo cult of over-qualification. Hardly a bad thing. >Many of Googles products implode shortly after getting released making software quality irrelevant. That is a function of leadership and poor product planning and has nothing to do with the quality of the engineers there.
  - wutbrodo 10y ago
    > Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. First of all, that's not what cargo cult means....https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming. What you're describing (though it doesn't apply to what I was saying) is also a bad thing, but you can't just use random phrases to mean whatever you want. More to the point: You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists? Because as I've mentioned multiple times, those are the basic, basic skills being tested by a question like "merge two sorted lists". One might have actually have occasion to write that algorithm on the job, but the real point is to test for a basic understanding of control flow and performance. I can barely imagine a programming job that would never have occasion to use those things, and most of the actual engineering you do in the simplest engineering jobs involve tasks of similar complexity. This isn't me blindly defending whatever interview policy Google happened to have; I'm talking about the adjustments I personally made to find what works over the course of a couple dozen interviews. > Many of Googles products implode shortly after getting released making software quality irrelevant. Now this is just embarrassing. Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides. I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant.
    - uola 10y ago
      > First of all, that's not what cargo cult means... Per the definition on the linked wikipedia page cargo cult programming is "ritual inclusion of code or program structures that serve no real purpose", "results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle" and "organizations that attempt to emulate more successful development houses". It's of course based on the concept of cargo cult behavior, where you try to achieve success by imitating external properties without the substance. I'm saying that Google by having things like a challenging admissions process, predictable career path, stark focus on credentials, all-inclusive perks and campus environment are trying to imitate an elite school which is an environment where many people at Google felt successful. By doing that they recruit computer science heavy coders which, at least when they are inexperienced, tend to overly rely on CS style programming (advanced techniques, optimizations, correctness) in favor of other concerns of software engineering (organizational friction, code flexibility, overall design). There's evidence that candidates that want to work at companies like Google often cram these types of questions without necessary having used them in real world projects. I would say both imitation of academia, over reliance of CS as a factor in recruiting and the risk of neglecting software engineering in favor of computer science techniques is relevant to the concept of cargo cult and cargo cult programming. > Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides. The whole point of the cargo cult concept is that you do things that in the end is ineffective. We all know that Google has a lot of smart people, with credentials and that can write code. Yet, that doesn't always seem to produce good result as far as shipping products. Yes, one could blame management but that is also a factor of company culture. > I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant. Why would you accuse me of "irrelevant asides" and then bring up "random 14 year olds". Software quality is subjective. One could argue that writing, both as part of developing and documenting software, is essential for software quality. You seem to use a lot of rhetoric that isn't relevant to the discussion at hand. > You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists? That's not the point. There are other ways to find out if people can manage these things that doesn't favor people with a theoretical background. Other method might be looking up peoples portfolios, having them submit code they've written, pair programming or reasoning around example code. Googles hiring process is adopted for how Google works. Having a common theoretical framework might be important at Google. But that doesn't mean that people who doesn't fit into that profile can't be good software engineers, nor that this process is even feasible for other companies.
hvidgaard 10y ago
While that may be the case for some employees, I expect that for any programming work to be done at all, you're able to merge two sorted lists. If a candidate cannot do that I have little faith their abilities to program in general. Note that this is not CS stuff at all, but beginner programming tutorial stuff.
- geebee 10y ago
  I hear you. We should acknowledge, though, that this goes well beyond merging sorted lists. My guess is that there are lots of people who can do this but are filtered out by considerably more difficult questions. Even with merging two sorted lists, remember that you're asking people to merge two sorted lists at a whiteboard while explaining what they're doing, under somewhat stressful conditions, which may trip up someone who could do this easily at a keyboard.
  - deleted 10y ago
    [deleted]

wutbrodo 10y ago

That may be true, but I've never been at a company that was desperate enough to hire cargo cult programmers. Interview jitters aside (that's an unfortunate artifact of the coding interview), not having a grasp of loops, iteration, and the most basic of data structures is a low, low, low bar for "knows how to program". I'm not even being particularly picky here. Big companies can be notorious for hiring CS grads from great programs and never having them do any actual computer science, and I agree that that bar is unnecessary for good engineering. But this filter isn't _unrelated_ to the job of being an engineer (or even a code monkey!), it's basic, basic programming. I'd imagine it does a great job of removing the kind of candidates who are capable of trivially avoidable bugs that become time bombs down the road.

uola 10y ago
Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. Many of Googles products implode shortly after getting released making software quality irrelevant. Also many successful Google products were originally made by other companies, presumably with different hiring processes, that joined Google. That said, from what I've heard it isn't the questions themselves so much as the overall interview process that puts people off.
- GrumpyYoungMan 10y ago
  >Hiring people based on things they won't use seems an awful lot like a cargo cult. Yes, but in this case, it's a cargo cult of over-qualification. Hardly a bad thing. >Many of Googles products implode shortly after getting released making software quality irrelevant. That is a function of leadership and poor product planning and has nothing to do with the quality of the engineers there.
- wutbrodo 10y ago
  > Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. First of all, that's not what cargo cult means....https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming. What you're describing (though it doesn't apply to what I was saying) is also a bad thing, but you can't just use random phrases to mean whatever you want. More to the point: You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists? Because as I've mentioned multiple times, those are the basic, basic skills being tested by a question like "merge two sorted lists". One might have actually have occasion to write that algorithm on the job, but the real point is to test for a basic understanding of control flow and performance. I can barely imagine a programming job that would never have occasion to use those things, and most of the actual engineering you do in the simplest engineering jobs involve tasks of similar complexity. This isn't me blindly defending whatever interview policy Google happened to have; I'm talking about the adjustments I personally made to find what works over the course of a couple dozen interviews. > Many of Googles products implode shortly after getting released making software quality irrelevant. Now this is just embarrassing. Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides. I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant.
  - uola 10y ago
    > First of all, that's not what cargo cult means... Per the definition on the linked wikipedia page cargo cult programming is "ritual inclusion of code or program structures that serve no real purpose", "results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle" and "organizations that attempt to emulate more successful development houses". It's of course based on the concept of cargo cult behavior, where you try to achieve success by imitating external properties without the substance. I'm saying that Google by having things like a challenging admissions process, predictable career path, stark focus on credentials, all-inclusive perks and campus environment are trying to imitate an elite school which is an environment where many people at Google felt successful. By doing that they recruit computer science heavy coders which, at least when they are inexperienced, tend to overly rely on CS style programming (advanced techniques, optimizations, correctness) in favor of other concerns of software engineering (organizational friction, code flexibility, overall design). There's evidence that candidates that want to work at companies like Google often cram these types of questions without necessary having used them in real world projects. I would say both imitation of academia, over reliance of CS as a factor in recruiting and the risk of neglecting software engineering in favor of computer science techniques is relevant to the concept of cargo cult and cargo cult programming. > Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides. The whole point of the cargo cult concept is that you do things that in the end is ineffective. We all know that Google has a lot of smart people, with credentials and that can write code. Yet, that doesn't always seem to produce good result as far as shipping products. Yes, one could blame management but that is also a factor of company culture. > I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant. Why would you accuse me of "irrelevant asides" and then bring up "random 14 year olds". Software quality is subjective. One could argue that writing, both as part of developing and documenting software, is essential for software quality. You seem to use a lot of rhetoric that isn't relevant to the discussion at hand. > You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists? That's not the point. There are other ways to find out if people can manage these things that doesn't favor people with a theoretical background. Other method might be looking up peoples portfolios, having them submit code they've written, pair programming or reasoning around example code. Googles hiring process is adopted for how Google works. Having a common theoretical framework might be important at Google. But that doesn't mean that people who doesn't fit into that profile can't be good software engineers, nor that this process is even feasible for other companies.

hvidgaard 10y ago

While that may be the case for some employees, I expect that for any programming work to be done at all, you're able to merge two sorted lists. If a candidate cannot do that I have little faith their abilities to program in general. Note that this is not CS stuff at all, but beginner programming tutorial stuff.

geebee 10y ago
I hear you. We should acknowledge, though, that this goes well beyond merging sorted lists. My guess is that there are lots of people who can do this but are filtered out by considerably more difficult questions. Even with merging two sorted lists, remember that you're asking people to merge two sorted lists at a whiteboard while explaining what they're doing, under somewhat stressful conditions, which may trip up someone who could do this easily at a keyboard.
- deleted 10y ago
  [deleted]