5 ms·

Disclaimer: I work at Google but in no way do I represent my employer's views. These are all my personal opinions. I interned successfully at FB, Microsoft and

Disclaimer: I work at Google but in no way do I represent my employer's views. These are all my personal opinions. I interned successfully at FB, Microsoft and Google as a SWE in 2008-2010 and interviewed with a lot of other tech companies (not always but often successfully). Like you, I tend to freeze up in a whiteboard situation, and have most of my life, going back to college and prior (I studied in Romania where at the time you had to stand up and answer questions and use a whiteboard to answer them). I find that a few things help: 1. Practice practice practice. Simulate the interview with a few friends multiple times. It gets easier no matter how shy you are. 2. Smart interviewers and companies open with easy, friendly questions that put the interviewee at ease. It's a sign they understand this is stressful for everyone, no matter how confident, knowledgeable and smart they are. While these interviews aren't perfect, with the right attitude they are helpful: it shows how the person thinks through a problem and communicates their ideas, and how they "work together" with the interviewer. These are important skills that are important for all people regardless of their title. I also believe a solid CS foundation is important even if coding is mostly putting things together. A systematic, mathematical understanding of complexity of Algorithms and Data Structures shows in one's everyday decisions. There are only a few valid alternatives in my mind: 1. Take-home project work More realistic assessment of how effective a person is. Really good simulation of that, but no signal about their collaboration style, interpersonal dynamics etc. 2. On-site trial for a week or two This is probably the best way to assess someone's ability - internships and residencies are as close to real life as one can get. It's hard for people who already have a job, and expensive for a company to do. Simpler proxies/filters are needed. Am I missing any other ways to assess candidates?

NTDF9 10y ago
>> Am I missing any other ways to assess candidates? Yes. You are completely glossing over the fact that the candidate might be bringing something special to the table. You have literally not left any room for the candidate to showcase what they've learned (again, not minutia of algorithms but something completely different..like the candidate could be a specialist in how compilers do register allocation) How about the interviewer improving their interviewing skills to be able to identify strengths rather than being a pseudo automata that docks points?
- george_ciobanu 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. 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

>> Am I missing any other ways to assess candidates? Yes. You are completely glossing over the fact that the candidate might be bringing something special to the table. You have literally not left any room for the candidate to showcase what they've learned (again, not minutia of algorithms but something completely different..like the candidate could be a specialist in how compilers do register allocation) How about the interviewer improving their interviewing skills to be able to identify strengths rather than being a pseudo automata that docks points?

george_ciobanu 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. 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?