4 ms·

A warning: If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding proble

A warning: If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else? Why couldn't he rip through that problem and teach _us_ a thing or two on the way? Another thing is you're basically coming in and saying "your interview process is wrong". If you're being interviewed as a manager or a lead, you can afford that risk. If not, be careful, because many people, myself included, don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time.

programmarchy 9y ago
> don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.
majormajor 9y ago
I think it's fair for non-simple coding problems. If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional). Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too. But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.
- golergka 9y ago
  > "do you find this more useful than questions that are more representative of the work you're expecting me to do?" Yes, because tasks representative of the work we're expecting you to do are too obvious and simple for an interview 95% of the time, and are too hard and take too long for an interview 5% of the time.
  - cableshaft 9y ago
    If 95% of the work you need done is too obvious and simple, maybe you don't need to hire as good of programmers as you think you do, and why are you trying to make things in the interview artificially harder than the work that needs to be done? It's kind of like asking someone interviewing to be a cashier at a fast food restaurant multivariable calculus problems, because 95% of the math they're going to have to do at their job is "too obvious and simple".
    - golergka 9y ago
      > If 95% of the work you need done is too obvious and simple, maybe you don't need to hire as good of programmers as you think you do, and why are you trying to make things in the interview artificially harder than the work that needs to be done? If these high-priority and hard 5% were easily separable from the tedious 95%, this logic would be correct.
Swizec 9y ago
> feels the need to question things Call me old fashioned, but I thought that was my job as an engineer. To question things and find ways to fix/improve them. Am I wrong?
Karunamon 9y ago
>...and feels the need to question things that have clearly been thought out ahead of time. I only take issue with this. Many things in organizations that have been through explosive growth (and sometimes others) are that way because for no reason in particular and amount to bandaids upon bandaids because nobody's ever had a chance to actually look at the process. It very well might suck. Questioning it is the first step in making it not suck. That said, as an interviewee is probably not the right time to do so. You're an outsider, you have very little rapport or relatability compared to the people that already work there. Even if you can point to something and unambiguously prove that They're Doing It Wrong, your advice isn't in a position to be heeded.
- thesmallestcat 9y ago
  Thank you, your second paragraph is exactly my point, and I didn't appreciate everybody else dressing it down in isolation. Of course I don't want to work with a bunch of robots. But there's a time and place, and please don't throw a wrench in the interview process to prove how smart you are: I want to work with people who pursue their initiatives tactfully.
  - majormajor 9y ago
    I think you'd find more tact with a less combative-sounding opener than "If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem." Moving the bit about the scope of the role (jr vs sr vs lead) up to preface the rest of the comment would've toned it down a bit, but even there I disagree with the "taking a risk" part - a senior candidate shouldn't feel like it's risky to offer alternative perspectives. If I got the impression that the hiring manager thought asking questions would likely be a sign of "cannot focus on the task at hand," that's going to set off my own flags a bit. If you're married to your interview process I'm worried you'd be even more married to your day-to-day process, and I haven't met a perfect company yet, so I consider being overly adherent to process instead of results a warning sign.
    - 9y ago
irq11 9y ago
”If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else?” And those people are what we call “assholes”. Everyone makes mistakes. If you make a habit of questioning people’s competence because they make mistakes, and didn’t ace your whiteboard coding tests beforehand, you are 100% the source of the problem in this industry.
- deleted 9y ago
  [deleted]
rimliu 9y ago
So you prefer working with people having no selfrespect? > question things that have clearly been thought out > ahead of time. Does not look that way to me.

programmarchy 9y ago

> don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.

majormajor 9y ago

I think it's fair for non-simple coding problems. If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional). Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too. But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.

golergka 9y ago
> "do you find this more useful than questions that are more representative of the work you're expecting me to do?" Yes, because tasks representative of the work we're expecting you to do are too obvious and simple for an interview 95% of the time, and are too hard and take too long for an interview 5% of the time.
- cableshaft 9y ago
  If 95% of the work you need done is too obvious and simple, maybe you don't need to hire as good of programmers as you think you do, and why are you trying to make things in the interview artificially harder than the work that needs to be done? It's kind of like asking someone interviewing to be a cashier at a fast food restaurant multivariable calculus problems, because 95% of the math they're going to have to do at their job is "too obvious and simple".
  - golergka 9y ago
    > If 95% of the work you need done is too obvious and simple, maybe you don't need to hire as good of programmers as you think you do, and why are you trying to make things in the interview artificially harder than the work that needs to be done? If these high-priority and hard 5% were easily separable from the tedious 95%, this logic would be correct.

Swizec 9y ago

> feels the need to question things Call me old fashioned, but I thought that was my job as an engineer. To question things and find ways to fix/improve them. Am I wrong?

Karunamon 9y ago

>...and feels the need to question things that have clearly been thought out ahead of time. I only take issue with this. Many things in organizations that have been through explosive growth (and sometimes others) are that way because for no reason in particular and amount to bandaids upon bandaids because nobody's ever had a chance to actually look at the process. It very well might suck. Questioning it is the first step in making it not suck. That said, as an interviewee is probably not the right time to do so. You're an outsider, you have very little rapport or relatability compared to the people that already work there. Even if you can point to something and unambiguously prove that They're Doing It Wrong, your advice isn't in a position to be heeded.

thesmallestcat 9y ago
Thank you, your second paragraph is exactly my point, and I didn't appreciate everybody else dressing it down in isolation. Of course I don't want to work with a bunch of robots. But there's a time and place, and please don't throw a wrench in the interview process to prove how smart you are: I want to work with people who pursue their initiatives tactfully.
- majormajor 9y ago
  I think you'd find more tact with a less combative-sounding opener than "If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem." Moving the bit about the scope of the role (jr vs sr vs lead) up to preface the rest of the comment would've toned it down a bit, but even there I disagree with the "taking a risk" part - a senior candidate shouldn't feel like it's risky to offer alternative perspectives. If I got the impression that the hiring manager thought asking questions would likely be a sign of "cannot focus on the task at hand," that's going to set off my own flags a bit. If you're married to your interview process I'm worried you'd be even more married to your day-to-day process, and I haven't met a perfect company yet, so I consider being overly adherent to process instead of results a warning sign.
  - 9y ago

irq11 9y ago

”If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else?” And those people are what we call “assholes”. Everyone makes mistakes. If you make a habit of questioning people’s competence because they make mistakes, and didn’t ace your whiteboard coding tests beforehand, you are 100% the source of the problem in this industry.

deleted 9y ago
[deleted]

rimliu 9y ago

So you prefer working with people having no selfrespect? > question things that have clearly been thought out > ahead of time. Does not look that way to me.