4 ms·

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 als

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 8y 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 8y 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 8y 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 8y 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 8y 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_ 8y 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.
  - tempguy9999 8y 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: (inserts self-pwn car crash here) I've done SQL for ~20 years and I'd say I'm good at it. I don't make as many mistakes as you've described but I know exactly what you mean, and I'd never hold that against you because I don't give a toss about mistakes that the language will catch. I've rarely interviewed others, but when I did I asked high-level stuff approaches. I wanted to see if they could grasp the solution, not the physical framework. Actual example: you're given a large collection of words, which you're allowed to pre-process - you have plenty of time to do this. Later on you are given another word, how would you very quickly find all acronymns of that word? (inerviewee programmer didn't get it, so I tried it on a non-programmer we had around - she very quickly worked out you ordered the letters and saved them - she didn't explain it clearly (to repeat, she wasn't a programmer) but in programmer terms it was a dictionary with keys as the sorted letters and the values as a set of the words). In this case, would you employ the supposed programmer who didn't get it, or the non-programmer who did? Actual example: Show me how you'd represent an arithmetic expression using objects, and how you'd evaluate it in an OO style (was after class hierarchy of (op, leftexpr, rightexpr and .eval method. With plenty of time and pushes in the right direction, he still didn't get it despite claiming good OO on his CV) (True story: to same guy who didn't get the OO expression question, I started off with an SQL question. His CV said SQL was his strong point, so I gave him an easy one: "explain to me what a left outer join does". He shook his head in confusion "Never heard of it". Actually happened! I'm not even exaggerating!)

jefftk 8y 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 8y 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 8y 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 8y 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 8y 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_ 8y 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.
- tempguy9999 8y 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: (inserts self-pwn car crash here) I've done SQL for ~20 years and I'd say I'm good at it. I don't make as many mistakes as you've described but I know exactly what you mean, and I'd never hold that against you because I don't give a toss about mistakes that the language will catch. I've rarely interviewed others, but when I did I asked high-level stuff approaches. I wanted to see if they could grasp the solution, not the physical framework. Actual example: you're given a large collection of words, which you're allowed to pre-process - you have plenty of time to do this. Later on you are given another word, how would you very quickly find all acronymns of that word? (inerviewee programmer didn't get it, so I tried it on a non-programmer we had around - she very quickly worked out you ordered the letters and saved them - she didn't explain it clearly (to repeat, she wasn't a programmer) but in programmer terms it was a dictionary with keys as the sorted letters and the values as a set of the words). In this case, would you employ the supposed programmer who didn't get it, or the non-programmer who did? Actual example: Show me how you'd represent an arithmetic expression using objects, and how you'd evaluate it in an OO style (was after class hierarchy of (op, leftexpr, rightexpr and .eval method. With plenty of time and pushes in the right direction, he still didn't get it despite claiming good OO on his CV) (True story: to same guy who didn't get the OO expression question, I started off with an SQL question. His CV said SQL was his strong point, so I gave him an easy one: "explain to me what a left outer join does". He shook his head in confusion "Never heard of it". Actually happened! I'm not even exaggerating!)