3 ms·

Question based on some surprising-to-me chatter in a thread some weeks back about interviews: When people claim that some shocking proportion of allegedly-acco

Question based on some surprising-to-me chatter in a thread some weeks back about interviews: When people claim that some shocking proportion of allegedly-accomplished candidates can’t write basic code to perform even a simple task on a whiteboard—do they mean pseudocode, or something akin to that? Or are they counting off points for getting actual syntax wrong? Because I’ve been paid to write code for more than two decades but will reliably screw up syntax details on a language I wrote 200 lines of earlier that same day. Like I’ll use the wrong “elseif” (or is it elif? elsif? else if? God I don’t remember). Basic shit like that. I might well fail a fizzbuzz even, by those standards, unless asking some really dumb questions about the language won’t raise red flags.

lesuorac 2y ago
Plenty of candidates can't figure how to use a for-loop to iterate over input or even how to handle nested data (Trees). If you're biggest worry about leetcode is does this language need a semi-colon at the end then I doubt you have trouble interviewing. --- Do you do much interviewing as an interviewer?
- vundercind 2y ago
  I have in past roles. We never leetcoded anyone where I’ve been an interviewer. One place where I guided it my approach was to attempt to learn something from the candidate—this not-infrequently led to my being the only person (they claimed) to have ever e.g. engaged them in a conversation about a paper they authored and listed on their résumé. Which, wtf, how do you not get curious enough to skim that before the interview and ask a couple non-stupid questions about it? I don’t exactly have a dataset (who does? A few Bigcos but most interviewers are working with tea-leaves and guesses) but I really liked the “try to learn something” approach and would use it again. It helps that I don’t know much so it’s pretty easy for me to find something I don’t know that the candidate can teach me about, I suppose—maybe this doesn’t work so well for people who know a lot and also aren’t good at faking not-knowing things.
lelandfe 2y ago
Just one example, but I was failed on a technical I took recently. It had a runtime, so not a whiteboard. But the editor I had to use provided no checking and I only found out after minutes of work that debugger breakpoints were not supported (the interviewer had not used them before) So I failed the technical as I had to spend like a substantial amount of a 45m session console logging out values and experimenting as I went. It turned out I missed a few characters in my code. I was pretty beside myself.

lesuorac 2y ago

Plenty of candidates can't figure how to use a for-loop to iterate over input or even how to handle nested data (Trees). If you're biggest worry about leetcode is does this language need a semi-colon at the end then I doubt you have trouble interviewing. --- Do you do much interviewing as an interviewer?

vundercind 2y ago
I have in past roles. We never leetcoded anyone where I’ve been an interviewer. One place where I guided it my approach was to attempt to learn something from the candidate—this not-infrequently led to my being the only person (they claimed) to have ever e.g. engaged them in a conversation about a paper they authored and listed on their résumé. Which, wtf, how do you not get curious enough to skim that before the interview and ask a couple non-stupid questions about it? I don’t exactly have a dataset (who does? A few Bigcos but most interviewers are working with tea-leaves and guesses) but I really liked the “try to learn something” approach and would use it again. It helps that I don’t know much so it’s pretty easy for me to find something I don’t know that the candidate can teach me about, I suppose—maybe this doesn’t work so well for people who know a lot and also aren’t good at faking not-knowing things.

lelandfe 2y ago

Just one example, but I was failed on a technical I took recently. It had a runtime, so not a whiteboard. But the editor I had to use provided no checking and I only found out after minutes of work that debugger breakpoints were not supported (the interviewer had not used them before) So I failed the technical as I had to spend like a substantial amount of a 45m session console logging out values and experimenting as I went. It turned out I missed a few characters in my code. I was pretty beside myself.