6 ms·

Of course computer architecture, compiler knowledge etc is valuable and part of the interview process. I was referring to the general process of evaluating- - t

Of course computer architecture, compiler knowledge etc is valuable and part of the interview process. I was referring to the general process of evaluating- - thus the question was focused on methods not content. Additionally, explaining how a system works is valuable, and I captured it when mentioned communication abilities.

NTDF9 10y ago
>> Of course computer architecture, compiler knowledge etc is valuable and part of the interview process. I was referring to the general process of evaluating- - thus the question was focused on methods not content. The general process is fucked up because the interviewers are incompetent enough that they can't tell who is actually a smart guy. This is why incompetent interviewers resort to binary decision making on programming questions. Here's a way to think about it. Let's take two candidates with equal communication skills: 1. This candidate solves all coding problems fast, with great syntax, good style and discusses algorithmic complexities well 2. This candidate is smart, can go deep in their specialty (because they've spent years developing complex expertise) but couldn't do a medium-level tree traversal without hints or has bad coding style (on whiteboard) Who do you see getting picked (at Google)? I remember a friend of mine at Google (a Java programmer) docked points off a candidate (a C programmer) because the candidate passed length of array as an argument. I was like wtf? Seriously? You don't know C? The data-driven committee-based process completely ignores that not interviewers are equal. Their feedbacks on paper are not equal. There's a reason scouting still exists in Baseball/Soccer/Football because data-driven process has given mediocre results at best. Interviewing is much like scouting. You cannot use mediocre engineers to identify who's a real talent.
- george_ciobanu 10y ago
  Like I said I speak for myself not Google. They're both valuable, perhaps for different types of work. A balanced tree does not tell me much about a person's knowledge but how they are able to apply and learn CS concepts does. Deep knowledge of a problem domain is valuable, but also highly perishable - the world changes fast and good engineers need to learn and adapt. Furthermore, if a candidate speaks about a domain they have deep expertise in, we have two more problems: 1. The interviewer might not know enough about the field to assess the candidate. (Generic CS algs and data structures are a good common denominator). 2. A candidate's knowledge about a field doesn't tell me how good they are at reasoning. They may have spent 5 years doing that one thing - that's enough time to learn almost anything in a limited domain - say OS schedulers. How would you structure an interview process?
  - NTDF9 10y ago
    Good arguments and we're getting there. You seem open minded unlike others and so I'd like you to answer the following: -- Furthermore, if a candidate speaks about a domain they have deep expertise in, we have two more problems: 1. The interviewer might not know enough about the field to assess the candidate. (Generic CS algs and data structures are a good common denominator). So the problem is with the interviewer and not the candidate right? The interviewer is unqualified to interview this person 2. A candidate's knowledge about a field doesn't tell me how good they are at reasoning. They may have spent 5 years doing that one thing - that's enough time to learn almost anything in a limited domain - say OS schedulers. Couldn't the same be said of candidates good at whiteboard tiny algorithm puzzle solving? They may have spent 5 years doing that one thing - say algorithmic puzzle solving. The fact that books and coaching sessions industry exists should prove this right? Your process doesn't give as much weight to someone who has the passion to go deep in something productive as much as passion to solve toy algo puzzles
    - george_ciobanu 10y ago
      That's nice of you to say, though I'm not sure I earned your compliment. Re experience - yes, if you're interviewing for someone with deep Java or ML knowledge certainly make sure the interviewer can assess that. Logic puzzles are not perfect - I used to be really good at solving them and if I ever have to interview on them again, I'd definitely have to practice first, to get up to speed. But I do think that being able to solve them is a meta skill. If you get really good it entails that you are good at reasoning and solving complex problems, or at least a specific class. If you are good with trees you'll likely be able to answer a trie question. It doesn't mean you're just good at that, but that you can apply knowledge to new problems - which is exactly why you are hired. An equivalent real question I got in Java was how to access a private member of a class. If I knew the answer it would mean I have some random bit of trivia in my head. If I solve it using Java knowledge it means I can apply my domain expertise in a new way - that's compelling proof of problem solving skills. If I ask why would you want to do that, it indicates reflective and critical thinking skills. A seasoned engineer in ML or Java should, imho also be able to solve puzzles. They are, in many ways, better proof of abstract thinking abilities and problem solving skills than specific knowledge. But I agree they are both important - if I want to build a search engine I prefer to have a seasoned ElasticSearch lady lead the project than an equally smart person with no background. Re your friend, if it helps, I interviewed at a lot of companies and probably failed about 70% of interviews in the first week or two. I got much better after a few weeks, which proves your point that interviewing is also a skill. And I mean for both tech and behavior questions. That's normal, I think. Re Google, while I don't represent the company, there are public statements that they'd rather have a false negative rate rather than false positives. It's better to say no to a great applicant (politely) than yes to a bad one. If you've ever had to let someone go, or deal with a bad team member, you know what I'm talking about. Of course there's the occasional interviewer who asks a silly question or gets something wrong. Do you never make mistakes? It's impossible to ensure everything goes perfectly in such a large company, but I can tell you, as someone who works here, that people try really hard to do a good job at it, and leave everyone with a good impression. It's the rational thing to do: if you treat people poorly 1. You're and asshole and 2. They'll hate you. Nobody likes assholes especially at Google, and I can share that I haven't met one yet. That's pretty amazing given the size. Thanks for engaging in this discussion, I really enjoy it.
- stagbeetle 10y ago
  The process is not designed to find "real talent." "Real talent" is innate and thus no amount of outside valuation will ever do it justice. No one else, but the "real talent" holder, can effectively judge his "real talent" so it is up to him to make it known to others that he does, in-fact, hold "real talent." The process is designed to find people that are good enough to do an array of jobs. "Real talent" gets scouted, because it's shown that it "has got the right stuff." This argument boils down similarly to the "smart but lazy" exasperations. "I'm talented, but no one realizes it!" Candidate 1 is getting the job at my startup and Candidate 2 will be getting a referral if he ever decides to take up a teaching position. Deep specialization is useless unless you're doing consulting (in-house and out-house) or teaching.

NTDF9 10y ago

>> Of course computer architecture, compiler knowledge etc is valuable and part of the interview process. I was referring to the general process of evaluating- - thus the question was focused on methods not content. The general process is fucked up because the interviewers are incompetent enough that they can't tell who is actually a smart guy. This is why incompetent interviewers resort to binary decision making on programming questions. Here's a way to think about it. Let's take two candidates with equal communication skills: 1. This candidate solves all coding problems fast, with great syntax, good style and discusses algorithmic complexities well 2. This candidate is smart, can go deep in their specialty (because they've spent years developing complex expertise) but couldn't do a medium-level tree traversal without hints or has bad coding style (on whiteboard) Who do you see getting picked (at Google)? I remember a friend of mine at Google (a Java programmer) docked points off a candidate (a C programmer) because the candidate passed length of array as an argument. I was like wtf? Seriously? You don't know C? The data-driven committee-based process completely ignores that not interviewers are equal. Their feedbacks on paper are not equal. There's a reason scouting still exists in Baseball/Soccer/Football because data-driven process has given mediocre results at best. Interviewing is much like scouting. You cannot use mediocre engineers to identify who's a real talent.

george_ciobanu 10y ago
Like I said I speak for myself not Google. They're both valuable, perhaps for different types of work. A balanced tree does not tell me much about a person's knowledge but how they are able to apply and learn CS concepts does. Deep knowledge of a problem domain is valuable, but also highly perishable - the world changes fast and good engineers need to learn and adapt. Furthermore, if a candidate speaks about a domain they have deep expertise in, we have two more problems: 1. The interviewer might not know enough about the field to assess the candidate. (Generic CS algs and data structures are a good common denominator). 2. A candidate's knowledge about a field doesn't tell me how good they are at reasoning. They may have spent 5 years doing that one thing - that's enough time to learn almost anything in a limited domain - say OS schedulers. How would you structure an interview process?
- NTDF9 10y ago
  Good arguments and we're getting there. You seem open minded unlike others and so I'd like you to answer the following: -- Furthermore, if a candidate speaks about a domain they have deep expertise in, we have two more problems: 1. The interviewer might not know enough about the field to assess the candidate. (Generic CS algs and data structures are a good common denominator). So the problem is with the interviewer and not the candidate right? The interviewer is unqualified to interview this person 2. A candidate's knowledge about a field doesn't tell me how good they are at reasoning. They may have spent 5 years doing that one thing - that's enough time to learn almost anything in a limited domain - say OS schedulers. Couldn't the same be said of candidates good at whiteboard tiny algorithm puzzle solving? They may have spent 5 years doing that one thing - say algorithmic puzzle solving. The fact that books and coaching sessions industry exists should prove this right? Your process doesn't give as much weight to someone who has the passion to go deep in something productive as much as passion to solve toy algo puzzles
  - george_ciobanu 10y ago
    That's nice of you to say, though I'm not sure I earned your compliment. Re experience - yes, if you're interviewing for someone with deep Java or ML knowledge certainly make sure the interviewer can assess that. Logic puzzles are not perfect - I used to be really good at solving them and if I ever have to interview on them again, I'd definitely have to practice first, to get up to speed. But I do think that being able to solve them is a meta skill. If you get really good it entails that you are good at reasoning and solving complex problems, or at least a specific class. If you are good with trees you'll likely be able to answer a trie question. It doesn't mean you're just good at that, but that you can apply knowledge to new problems - which is exactly why you are hired. An equivalent real question I got in Java was how to access a private member of a class. If I knew the answer it would mean I have some random bit of trivia in my head. If I solve it using Java knowledge it means I can apply my domain expertise in a new way - that's compelling proof of problem solving skills. If I ask why would you want to do that, it indicates reflective and critical thinking skills. A seasoned engineer in ML or Java should, imho also be able to solve puzzles. They are, in many ways, better proof of abstract thinking abilities and problem solving skills than specific knowledge. But I agree they are both important - if I want to build a search engine I prefer to have a seasoned ElasticSearch lady lead the project than an equally smart person with no background. Re your friend, if it helps, I interviewed at a lot of companies and probably failed about 70% of interviews in the first week or two. I got much better after a few weeks, which proves your point that interviewing is also a skill. And I mean for both tech and behavior questions. That's normal, I think. Re Google, while I don't represent the company, there are public statements that they'd rather have a false negative rate rather than false positives. It's better to say no to a great applicant (politely) than yes to a bad one. If you've ever had to let someone go, or deal with a bad team member, you know what I'm talking about. Of course there's the occasional interviewer who asks a silly question or gets something wrong. Do you never make mistakes? It's impossible to ensure everything goes perfectly in such a large company, but I can tell you, as someone who works here, that people try really hard to do a good job at it, and leave everyone with a good impression. It's the rational thing to do: if you treat people poorly 1. You're and asshole and 2. They'll hate you. Nobody likes assholes especially at Google, and I can share that I haven't met one yet. That's pretty amazing given the size. Thanks for engaging in this discussion, I really enjoy it.
stagbeetle 10y ago
The process is not designed to find "real talent." "Real talent" is innate and thus no amount of outside valuation will ever do it justice. No one else, but the "real talent" holder, can effectively judge his "real talent" so it is up to him to make it known to others that he does, in-fact, hold "real talent." The process is designed to find people that are good enough to do an array of jobs. "Real talent" gets scouted, because it's shown that it "has got the right stuff." This argument boils down similarly to the "smart but lazy" exasperations. "I'm talented, but no one realizes it!" Candidate 1 is getting the job at my startup and Candidate 2 will be getting a referral if he ever decides to take up a teaching position. Deep specialization is useless unless you're doing consulting (in-house and out-house) or teaching.