I remember one interview I had with a candidate. It was for a database analyst position that required SQL.
The first round was typically a phone screen where I chat with the candidate, get to know them a bit.
Second round was code review. I asked them to do a SQL query that did x.
The queries were simple. The goal was to get the candidate to walk through the query.
I had one candid that, over screen share, wrote the query flawlessly. Then I asked them to explain what it was doing. The candidate froze.
I can get understand getting nervous so I moved onto an insert statement. I had them write one and then do another without using certain terms (often leading to a sub query).
Again, flawless. I asked what situations would you use one over the other.
Again, they froze. I started to get suspicious that they were cheating and had them, instead of typing the answer, say the answer. When they couldn’t, I knew enough that it wasn’t going to work.
I wonder why people do this. You wouldn’t apply to a welding job if you can’t weld. Why so many people apply to programming positions if they can’t actually code (or a database analyst position without knowing SQL)?
Some people seem to think you can just Google stuff or more recently use AI to do the coding, not knowing that being a dev is mostly about knowing what to search and that being a dev isn’t just coding.
A lot of the time I find “spot the bug” questions to be more informative, especially for junior roles. We stopped asking fizz-buzz - just about everyone has heard of it by now and it’s pretty easy to just rote learn a solution. Instead we give them the spec for fizz-buzz and a deliberately broken implementation and ask them to fix it. If they get flustered, just asking “what does this program output” usually give a pretty clear indication if they can reason about code in a systematic way.
That’s fine if there are no weird pedantic ropes to fall over. I am not a compiler or linker, that’s what I have compilers and linkers for. Same with an IDE. I don’t know many details of the stdlib or other common libs, because why should I waste space in my brain for stuff code completion can show me…
The kind of bugs I’m talking about are things like “the logical flow of the code is broken because the order of the if/else if/else branches is wrong”, “this program never finishes because you don’t increment that counter” and “you specified print the numbers 1 to 100, but that counter starts at 0”.
I’m testing your ability to think logically, not your knowledge of stdlib trivia
I remember one interview I had with a candidate. It was for a database analyst position that required SQL.
The first round was typically a phone screen where I chat with the candidate, get to know them a bit.
Second round was code review. I asked them to do a SQL query that did x.
The queries were simple. The goal was to get the candidate to walk through the query.
I had one candid that, over screen share, wrote the query flawlessly. Then I asked them to explain what it was doing. The candidate froze.
I can get understand getting nervous so I moved onto an insert statement. I had them write one and then do another without using certain terms (often leading to a sub query).
Again, flawless. I asked what situations would you use one over the other.
Again, they froze. I started to get suspicious that they were cheating and had them, instead of typing the answer, say the answer. When they couldn’t, I knew enough that it wasn’t going to work.
I wonder why people do this. You wouldn’t apply to a welding job if you can’t weld. Why so many people apply to programming positions if they can’t actually code (or a database analyst position without knowing SQL)?
Some people seem to think you can just Google stuff or more recently use AI to do the coding, not knowing that being a dev is mostly about knowing what to search and that being a dev isn’t just coding.
I had an applicant very obviously read to me that Wikipedia article about Active Directory.
When in doubt I ask them what RAID 45 is.
Knowing how to quickly look something up isn’t a bad skill. The problem is when that’s all they do
Sure, look up specific configuration points or architectures, but looking up AD is a bad sign.
A lot of the time I find “spot the bug” questions to be more informative, especially for junior roles. We stopped asking fizz-buzz - just about everyone has heard of it by now and it’s pretty easy to just rote learn a solution. Instead we give them the spec for fizz-buzz and a deliberately broken implementation and ask them to fix it. If they get flustered, just asking “what does this program output” usually give a pretty clear indication if they can reason about code in a systematic way.
That’s fine if there are no weird pedantic ropes to fall over. I am not a compiler or linker, that’s what I have compilers and linkers for. Same with an IDE. I don’t know many details of the stdlib or other common libs, because why should I waste space in my brain for stuff code completion can show me…
The kind of bugs I’m talking about are things like “the logical flow of the code is broken because the order of the if/else if/else branches is wrong”, “this program never finishes because you don’t increment that counter” and “you specified print the numbers 1 to 100, but that counter starts at 0”.
I’m testing your ability to think logically, not your knowledge of stdlib trivia