5 ms·

In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. In fact, y

by btmorex 16y ago

In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. In fact, you can probably improve how well you do so much that even a mediocre developer can come out looking very good. So why is that bad? Well, for one thing, the questions asked usually aren't directly to being good at your job. Consider the classic "How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?" Very, very few people are going to come up with the correct answer to that question without having seen it before especially in a high pressure interview environment. Yet people ask it all the time in interviews. Why? You're just selecting for people who have had to interview a lot (got rejected a lot). A newer style of interview that I quite like is to ask someone to write a moderate chunk of code with a laptop, access to the internet, and a few hours. At least you're measuring something that's directly related to software development.

CamperBob 16y ago
A newer style of interview that I quite like is to ask someone to write a moderate chunk of code with a laptop, access to the internet, and a few hours. An amusing variation on this might be to pick the next n interviewees and tell them to spend the day working on something as a team. Observe via camera or one-way glass.
- eru 16y ago
  Make sure to pay them.
  - Psyonic 16y ago
    My buddy actually had an interview just like that at a California company (much smaller than Google) and he did get paid.
deleted 16y ago
[deleted]
_Lemon_ 16y ago
> In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. In fact, you can probably improve how well you do so much that even a mediocre developer can come out looking very good. While this is true, isn't quite unlikely? Why not just invest the time into becoming a /good/ developer. >"How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?" What do you mean by "accounting" information? In the real-world I'd probably just brute-force it and keep around a set of elements already gone over. However I couldn't imagine ever having a need for that as I'd (and hopefully anyone I was working with) stick to the standard push_back functions available or that I created. So it shouldn't come about... I feel I've missed something here, so care to elaborate on the answer?
- kaens 16y ago
  While this is true, isn't quite unlikely? Why not just invest the time into becoming a /good/ developer. It might be unlikely for people applying to google, but I can attest that people will memorize what they think are details that will make them sound like they are competent to get through an interview. The software development industry is one where you can really make it into a position with decent pay by bullshitting, and then surf the wave of nothing-getting-done-because-of-corporate-policy for a while, while making yourself appear like a magic technology man if you really feel like it. This probably isn't going to happen as much with a company whose hiring process is filled with competent software engineers (but there's also the opposite problem...) It sounds like hell to me, but I'm concerned with writing code and feeling intellectually fulfilled, not just with making stacks of cash.
- brown9-2 16y ago
  What do you mean by "accounting" information? In the real-world I'd probably just brute-force it and keep around a set of elements already gone over. That is what is meant by accounting information - keeping track of the elements in the list you've visited. I believe the generally accepted answer for this question is to use two iterators, one moving faster (two elements at a time) than the other (one element at a time). If there is a cycle in the list, at some point the two iterators will be pointing at the same node. Otherwise, the iterators will reach the end of the list, meaning no cycle exists.
JabavuAdams 16y ago
In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. You can get to be a better programmer, by practicing, too. If the system is easily gamed, and they know that, and you know that then failing to game the system shows a lack of motivation. So, perhaps they're not selecting for what you (or even they) think they're selecting for.
strlen 16y ago
> In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. In fact, you can probably improve how well you do so much that even a mediocre developer can come out looking very good. It's a popular meme on HN that people's intelligence and abilities are fixed from the start. In reality, they're quite plastic and improve over time when they're put to a use. Note that outside of few companies such as Google, Microsoft, Apple and some start-ups (and even for good chunk of roles within those companies) great deal of programming involves wiring together components somebody else wrote, while working around bugs in those components. There's nothing wrong with that, in fact, if someone already solved a problem adequately enough it's your duty to build an application based on that solution rather than re-invent the wheel, this time with new and exciting bugs (I'll confess to having done that bunch of times, going as far as writing my own RNG once). If you want to understand how the "magic" of those components works (so that you could get some of the most intellectually rewarding jobs which involve creating such "magic"), you have to do that on your own time. Thus, if you have a regular programming job specific portions of your intelligence will atrophy as they're not being used. If you've found a job that is intellectually stimulating, then you have no reason to interview elsewhere unless you're grossly underpaid, have to commute to the North Pole and write firmware for machines that torture baby seals. When an interview candidate is truly smart e.g., can figure out a more puzzle-like problem without ever having seen them before, that's great and respectable. Give her a few extra points. When a candidate shows persistence, passion (coding in her spare time on the sort of problems you typically don't see in day to day work), curiosity (learning about skip lists just because they're... really cool) and a way to apply her intelligence (even if that's not genius level) to her field of work (being able to keep multiple levels of indirection e.g., pointers and recursion in her head) that's even better. In my (so far, limited) experience in the industry I've noted that there are several types of programmers: 1) The "99.9th percentile" or "10x" programmers. They usually have an innate ability that was well nurtured from the beginning. There's only a handful of them, fairly equally distributed between Google (prior to it Sun, Bell Labs), start-ups, academia and quantitative finance / hedge funds. It's very visible: they'll solve problems quickly, they'll write code and get many things right the first time. They'll spot tricky concurrency issues by just looking at the code. If you manage to find one, by all means move mountains to hire them. Problem is, why would they join you? Money is not a motivating factor for them (not always out of principle: they're generally well off already) and companies bend rules for them (e.g., let them work from home or open offices in their home town if they're not local). If you want to hire them, hire all of their (respected) coworkers and friends, first. May be then (if things turn sour at their workplace) they'll consider you. The other way is to spot one amongst the crowd of interns or fresh graduates (Joel recommends that). 2) Visible poor ones. Typically very nice people, sometimes highly persistent and entrepreneurial but without the ability and/or education (self or formal) needed to succeed in an engineering discipline. They may still be smart: surprisingly, I've seen several people with advanced degrees in Mathematics and Computer Science that fit that bill (how that could happen evades me). Typically these are the people that are always on the market: who can't do fizz buzz, reverse a linked list, etc... It's trivial to filter them out. If they're really eager to be involved in software development, project/product management may be a right fit for them if they're otherwise smart and technical (see "The Russian Lit Major" by Rands for more on that). Oddly enough, I've seen people like that found profitable and sustainable small businesses (even if they weren't technology start-ups with home-run exits). 3) Everybody else. They're intelligent and educated (again, whether self or formally) enough to be <b>a programmer</b> but it either took or will take them work to be a great one. They have no genial ability, they will write code that has bugs and will have to sit down at a debugger to figure out why their code doesn't work. Odds are most people on HN fall into that category. Question is, how persistent are they at this? Do they give up after getting a cryptic error message? Have they had enough experience to avoid common causes of bugs? Are they willing to take time to improve themselves (to be able to "work magic") rather than being content to be typical enterprise developers? People in this category are very well capable of being 95-98th percentile programmers. It just takes practice (and not just paid practice at work) in addition to dedication and passion, not just innate qualities (such some forms of intelligence), to get to that level. They range in their current ability from "framework developers" (who don't care how something is implemented, but know a particular implementation well enough to get the job done) to what I called "95th-98th percentile" developers. Finding people on the upper end of that range (who have worked/studied their way to that place) is what programming questions should be aimed at, not just at finding general intelligence. Majority of employees in serious technology companies (Google et al) as well as a most start-up founders (with a few exceptions of some true "10x" programmers e.g., Bill Joy of Sun) fit that bill: they persisted at and practiced something they loved for a long period of time and became great at it. There are more of these people than there are "10x" programmers and many have earned the respect of the "10x" programmers and are going to be able to attract them to your organization in a "get an already great programmer, get introduced to his genius friend" deal.

by btmorex 16y ago

CamperBob 16y ago

A newer style of interview that I quite like is to ask someone to write a moderate chunk of code with a laptop, access to the internet, and a few hours. An amusing variation on this might be to pick the next n interviewees and tell them to spend the day working on something as a team. Observe via camera or one-way glass.

eru 16y ago
Make sure to pay them.
- Psyonic 16y ago
  My buddy actually had an interview just like that at a California company (much smaller than Google) and he did get paid.

deleted 16y ago

[deleted]

_Lemon_ 16y ago

kaens 16y ago
While this is true, isn't quite unlikely? Why not just invest the time into becoming a /good/ developer. It might be unlikely for people applying to google, but I can attest that people will memorize what they think are details that will make them sound like they are competent to get through an interview. The software development industry is one where you can really make it into a position with decent pay by bullshitting, and then surf the wave of nothing-getting-done-because-of-corporate-policy for a while, while making yourself appear like a magic technology man if you really feel like it. This probably isn't going to happen as much with a company whose hiring process is filled with competent software engineers (but there's also the opposite problem...) It sounds like hell to me, but I'm concerned with writing code and feeling intellectually fulfilled, not just with making stacks of cash.
brown9-2 16y ago
What do you mean by "accounting" information? In the real-world I'd probably just brute-force it and keep around a set of elements already gone over. That is what is meant by accounting information - keeping track of the elements in the list you've visited. I believe the generally accepted answer for this question is to use two iterators, one moving faster (two elements at a time) than the other (one element at a time). If there is a cycle in the list, at some point the two iterators will be pointing at the same node. Otherwise, the iterators will reach the end of the list, meaning no cycle exists.

JabavuAdams 16y ago

In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. You can get to be a better programmer, by practicing, too. If the system is easily gamed, and they know that, and you know that then failing to game the system shows a lack of motivation. So, perhaps they're not selecting for what you (or even they) think they're selecting for.

strlen 16y ago

> In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. In fact, you can probably improve how well you do so much that even a mediocre developer can come out looking very good. It's a popular meme on HN that people's intelligence and abilities are fixed from the start. In reality, they're quite plastic and improve over time when they're put to a use. Note that outside of few companies such as Google, Microsoft, Apple and some start-ups (and even for good chunk of roles within those companies) great deal of programming involves wiring together components somebody else wrote, while working around bugs in those components. There's nothing wrong with that, in fact, if someone already solved a problem adequately enough it's your duty to build an application based on that solution rather than re-invent the wheel, this time with new and exciting bugs (I'll confess to having done that bunch of times, going as far as writing my own RNG once). If you want to understand how the "magic" of those components works (so that you could get some of the most intellectually rewarding jobs which involve creating such "magic"), you have to do that on your own time. Thus, if you have a regular programming job specific portions of your intelligence will atrophy as they're not being used. If you've found a job that is intellectually stimulating, then you have no reason to interview elsewhere unless you're grossly underpaid, have to commute to the North Pole and write firmware for machines that torture baby seals. When an interview candidate is truly smart e.g., can figure out a more puzzle-like problem without ever having seen them before, that's great and respectable. Give her a few extra points. When a candidate shows persistence, passion (coding in her spare time on the sort of problems you typically don't see in day to day work), curiosity (learning about skip lists just because they're... really cool) and a way to apply her intelligence (even if that's not genius level) to her field of work (being able to keep multiple levels of indirection e.g., pointers and recursion in her head) that's even better. In my (so far, limited) experience in the industry I've noted that there are several types of programmers: 1) The "99.9th percentile" or "10x" programmers. They usually have an innate ability that was well nurtured from the beginning. There's only a handful of them, fairly equally distributed between Google (prior to it Sun, Bell Labs), start-ups, academia and quantitative finance / hedge funds. It's very visible: they'll solve problems quickly, they'll write code and get many things right the first time. They'll spot tricky concurrency issues by just looking at the code. If you manage to find one, by all means move mountains to hire them. Problem is, why would they join you? Money is not a motivating factor for them (not always out of principle: they're generally well off already) and companies bend rules for them (e.g., let them work from home or open offices in their home town if they're not local). If you want to hire them, hire all of their (respected) coworkers and friends, first. May be then (if things turn sour at their workplace) they'll consider you. The other way is to spot one amongst the crowd of interns or fresh graduates (Joel recommends that). 2) Visible poor ones. Typically very nice people, sometimes highly persistent and entrepreneurial but without the ability and/or education (self or formal) needed to succeed in an engineering discipline. They may still be smart: surprisingly, I've seen several people with advanced degrees in Mathematics and Computer Science that fit that bill (how that could happen evades me). Typically these are the people that are always on the market: who can't do fizz buzz, reverse a linked list, etc... It's trivial to filter them out. If they're really eager to be involved in software development, project/product management may be a right fit for them if they're otherwise smart and technical (see "The Russian Lit Major" by Rands for more on that). Oddly enough, I've seen people like that found profitable and sustainable small businesses (even if they weren't technology start-ups with home-run exits). 3) Everybody else. They're intelligent and educated (again, whether self or formally) enough to be <b>a programmer</b> but it either took or will take them work to be a great one. They have no genial ability, they will write code that has bugs and will have to sit down at a debugger to figure out why their code doesn't work. Odds are most people on HN fall into that category. Question is, how persistent are they at this? Do they give up after getting a cryptic error message? Have they had enough experience to avoid common causes of bugs? Are they willing to take time to improve themselves (to be able to "work magic") rather than being content to be typical enterprise developers? People in this category are very well capable of being 95-98th percentile programmers. It just takes practice (and not just paid practice at work) in addition to dedication and passion, not just innate qualities (such some forms of intelligence), to get to that level. They range in their current ability from "framework developers" (who don't care how something is implemented, but know a particular implementation well enough to get the job done) to what I called "95th-98th percentile" developers. Finding people on the upper end of that range (who have worked/studied their way to that place) is what programming questions should be aimed at, not just at finding general intelligence. Majority of employees in serious technology companies (Google et al) as well as a most start-up founders (with a few exceptions of some true "10x" programmers e.g., Bill Joy of Sun) fit that bill: they persisted at and practiced something they loved for a long period of time and became great at it. There are more of these people than there are "10x" programmers and many have earned the respect of the "10x" programmers and are going to be able to attract them to your organization in a "get an already great programmer, get introduced to his genius friend" deal.