6 ms·

Strange, I have yet to meet a single Google interviewer who was looking for perfect syntax during the interview. Last year I forgot the syntax for a data struct

Strange, I have yet to meet a single Google interviewer who was looking for perfect syntax during the interview. Last year I forgot the syntax for a data structure, told my interviewer "something like this," and he just said "that's fine." Got the internship later on. I even had one interviewer who was ok with me writing out matrix algebra mathematically instead of using np.matmul and all that.

adtac 7y ago
I can confirm. In one of my interviews, when writing Python, I used arr.push instead of arr.append (I don't usually write JS, but idk what happened), and I realised the mistake only half-way through. The interviewer noticed it apparently, and he said he didn't care. I imagine he didn't want to throw me off my thought train, which was nice. Got the offer too, so it really must not have mattered.
jogjayr 7y ago
As an interviewer, I can confirm that I don't care about syntax or whether the program compiles if I'm convinced their solution and approach would work. I'm also OK with candidates using placeholder helper functions or shorthand for trivial things (e.g. null/undefined check in JS) if they explain to me verbally what that part is supposed to do.
- jefftk 7y ago
  I also interview software engineering candidates at Google (n=150) and while I mostly agree, I do think there's some signal in whether a candidate can get the syntax right. It's not a dealbreaker if they don't, but all things considered someone who comfortably writes code all day is more likely to be able to write syntactically correct code than someone who doesn't. The main things I want to see, though, are: can you communicate well about the parts of the problem that aren't clear to you? Can you analyze and compare solutions? Can you figure out something reasonably efficient? Do you understand your solution well enough to code it? (Speaking for myself, not my employer.)
  - jogjayr 7y ago
    > I do think there's some signal in whether a candidate can get the syntax right I agree with that. I've had candidates explain certain points of syntax as they worked, or demonstrate their knowledge in other ways, or write their code particularly well or cleanly, and I make sure to mention that positively in my notes. But less-than-flawless syntax by itself isn't a negative for me. I agree with the main things you look for - I too try to focus on those more than syntax.
  - DenisM 7y ago
    Better designs require fewer lines of code [#]. Maybe the person spends more time thinking than writing. Also think about a typical enterprise Java program - writing lots of boilerplate code is bound to create fantastic muscle/syntax memory and no useful skill beyond that. [#] If this doesn't seem obvious consider the inverse - worse designs will inevitably require more lines of code to get the same result.
    - CaptainZapp 7y ago
      Better designs require fewer lines of code I think that's extremely dependent on context. I write mostly SQL and bash and would argue that both languages are not conductive to try to reduce size at the cost of future maintenance.
      - z3t4 7y ago
        There are simply no metric which can automatically measure code/design quality. Here's how I feel about code/design quality: 1) How many files I need to open to understand what the code does (less is better) 2) How many times I have to jump to follow the execution path (less is better) 3) How easy can I remove or rewrite this piece of code
  - oarabbus_ 7y ago
    > I do think there's some signal in whether a candidate can get the syntax right. I know you're talking about software engineers, not data analysts, but: select from <table> [oops... you're supposed to put an asterisk there] select <column>, count(field) from <table> [holy shit... I forgot the group by] select <column>, case when <condition> then <result> else <other> from <table> [oh man, case statements need to be terminated with an `END`] select <columns>, from <table> [oh no... SQL doesn't like that comma before the from statement] select <...> from <table1> join <table2> table1.column = table2.column [This is embarrassing, I forgot the `on` keyword] select <stuff> from <table1> union <stuff> from <table2> [Jesus... I forgot to type `select` after the union] select <column>, sum(column2) over (partition by column3 between unbounded preceding and current row) as cumulative_sum from <table> [dang, SQL doesn't know which rows if I don't actually mention `ROWS BETWEEN`] select <column>, count(case when <condition> then 1 else null end) as count from <table> order by count desc having count > 1 [ahh that's silly, you can't put your HAVING clause after the ORDER BY] with cte_1 as (select <...>), cte_2 as (select <...>) cte_3 as (select <...>) select <columns and aggregations> from cte_1 join cte_2 on <...> left join cte_3 on <...> where <condition> group by <many columns> [Oh my goodness, I forgot a comma after closing cte_2] Now, perhaps this says more about myself more than anything, but I really do write code comfortably all day, I'm glad my current employer, or any number of the clients I've worked for, haven't had this philosophy (even when watching over my shoulder waiting for results they need at the moment). I'd be mortified if anyone ever dug up some of the atrocious things I've requested of the database in the server logs.

adtac 7y ago

I can confirm. In one of my interviews, when writing Python, I used arr.push instead of arr.append (I don't usually write JS, but idk what happened), and I realised the mistake only half-way through. The interviewer noticed it apparently, and he said he didn't care. I imagine he didn't want to throw me off my thought train, which was nice. Got the offer too, so it really must not have mattered.

jogjayr 7y ago

As an interviewer, I can confirm that I don't care about syntax or whether the program compiles if I'm convinced their solution and approach would work. I'm also OK with candidates using placeholder helper functions or shorthand for trivial things (e.g. null/undefined check in JS) if they explain to me verbally what that part is supposed to do.

jefftk 7y ago
I also interview software engineering candidates at Google (n=150) and while I mostly agree, I do think there's some signal in whether a candidate can get the syntax right. It's not a dealbreaker if they don't, but all things considered someone who comfortably writes code all day is more likely to be able to write syntactically correct code than someone who doesn't. The main things I want to see, though, are: can you communicate well about the parts of the problem that aren't clear to you? Can you analyze and compare solutions? Can you figure out something reasonably efficient? Do you understand your solution well enough to code it? (Speaking for myself, not my employer.)
- jogjayr 7y ago
  > I do think there's some signal in whether a candidate can get the syntax right I agree with that. I've had candidates explain certain points of syntax as they worked, or demonstrate their knowledge in other ways, or write their code particularly well or cleanly, and I make sure to mention that positively in my notes. But less-than-flawless syntax by itself isn't a negative for me. I agree with the main things you look for - I too try to focus on those more than syntax.
- DenisM 7y ago
  Better designs require fewer lines of code [#]. Maybe the person spends more time thinking than writing. Also think about a typical enterprise Java program - writing lots of boilerplate code is bound to create fantastic muscle/syntax memory and no useful skill beyond that. [#] If this doesn't seem obvious consider the inverse - worse designs will inevitably require more lines of code to get the same result.
  - CaptainZapp 7y ago
    Better designs require fewer lines of code I think that's extremely dependent on context. I write mostly SQL and bash and would argue that both languages are not conductive to try to reduce size at the cost of future maintenance.
    - z3t4 7y ago
      There are simply no metric which can automatically measure code/design quality. Here's how I feel about code/design quality: 1) How many files I need to open to understand what the code does (less is better) 2) How many times I have to jump to follow the execution path (less is better) 3) How easy can I remove or rewrite this piece of code
- oarabbus_ 7y ago
  > I do think there's some signal in whether a candidate can get the syntax right. I know you're talking about software engineers, not data analysts, but: select from <table> [oops... you're supposed to put an asterisk there] select <column>, count(field) from <table> [holy shit... I forgot the group by] select <column>, case when <condition> then <result> else <other> from <table> [oh man, case statements need to be terminated with an `END`] select <columns>, from <table> [oh no... SQL doesn't like that comma before the from statement] select <...> from <table1> join <table2> table1.column = table2.column [This is embarrassing, I forgot the `on` keyword] select <stuff> from <table1> union <stuff> from <table2> [Jesus... I forgot to type `select` after the union] select <column>, sum(column2) over (partition by column3 between unbounded preceding and current row) as cumulative_sum from <table> [dang, SQL doesn't know which rows if I don't actually mention `ROWS BETWEEN`] select <column>, count(case when <condition> then 1 else null end) as count from <table> order by count desc having count > 1 [ahh that's silly, you can't put your HAVING clause after the ORDER BY] with cte_1 as (select <...>), cte_2 as (select <...>) cte_3 as (select <...>) select <columns and aggregations> from cte_1 join cte_2 on <...> left join cte_3 on <...> where <condition> group by <many columns> [Oh my goodness, I forgot a comma after closing cte_2] Now, perhaps this says more about myself more than anything, but I really do write code comfortably all day, I'm glad my current employer, or any number of the clients I've worked for, haven't had this philosophy (even when watching over my shoulder waiting for results they need at the moment). I'd be mortified if anyone ever dug up some of the atrocious things I've requested of the database in the server logs.