4 ms·

>Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (

>Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for. I'm always interested in this point of view, because I understand why candidates don't like it but as a hiring manager myself I also know that there's a fairly large proportion of candidates who look good on paper but can't actually do the most fundamental thing that a developer needs to do: solve an abstract problem with code. What's the alternative to filter those people out?

jen20 5y ago
That largely is a case-by-case decision I think. Perhaps via open source work, perhaps via a short take-home assignment. Since work in most of the US is “at will”, it’s an easy problem to solve if it turns out someone has exaggerated their abilities. My problem is not with _any_ coding to be clear. It’s mostly the Google gotcha questions designed to make the interviewer look smart, and where the primary takeaway is that the candidate has or has not seen that question before. Things like “let’s refactor this thing collaboratively and discuss trade offs” are fine - and discussing trade-offs gives you far more of a feel for a senior engineer than whether they can implement some trivially Googleable algorithm for which “use a library” is almost certainly the actual correct answer. This is the style of question I personally use when doing technical interviewing.
- veets 5y ago
  I always find this argument of "Google gotcha" questions weak. I agree 100% that tricky questions around dynamic programming, linked lists, etc. are a terrible choice. However, I think a lot of these questions do a good job of measuring how well the candidate understands basic data structures. It amazes me how many "seasoned engineers" do not understand when to use things like hash sets/maps (just look at the monthly blog posts about how you shouldn't use `in` in Python on lists because it is O(n)!! It blows my mind this is blog-post worthy). Also, I would far rather have a company not hire me because I failed a programming assessment than have them hire me and then fire me a week later because they were finally able to assess my skills.
  - jen20 5y ago
    The issue fundamentally is that most people do not use this kind of knowledge on a daily basis - even those of us doing low level work, and when it is needed, it is a mere web search away - or if necessary I can reach for Knuth. I think you misunderstand my notion of a "google gotcha" - I'm not proposing that interviews do not into rigorous technical detail. I'm proposing that interviews that test knowledge of easily-looked-up trivia rather than an understanding of engineering pragmatism and trade-offs are fundamentally flawed and yield markedly worse results than those that do not _regardless_ of company.
maxk42 5y ago
FizzBuzz-style questions are fine. Any coding exercise that takes under 30 minutes and doesn't require you to happen to remember some obscure piece of discrete mathematics trivia.
Rapzid 5y ago
Fire fast.

jen20 5y ago

That largely is a case-by-case decision I think. Perhaps via open source work, perhaps via a short take-home assignment. Since work in most of the US is “at will”, it’s an easy problem to solve if it turns out someone has exaggerated their abilities. My problem is not with _any_ coding to be clear. It’s mostly the Google gotcha questions designed to make the interviewer look smart, and where the primary takeaway is that the candidate has or has not seen that question before. Things like “let’s refactor this thing collaboratively and discuss trade offs” are fine - and discussing trade-offs gives you far more of a feel for a senior engineer than whether they can implement some trivially Googleable algorithm for which “use a library” is almost certainly the actual correct answer. This is the style of question I personally use when doing technical interviewing.

veets 5y ago
I always find this argument of "Google gotcha" questions weak. I agree 100% that tricky questions around dynamic programming, linked lists, etc. are a terrible choice. However, I think a lot of these questions do a good job of measuring how well the candidate understands basic data structures. It amazes me how many "seasoned engineers" do not understand when to use things like hash sets/maps (just look at the monthly blog posts about how you shouldn't use `in` in Python on lists because it is O(n)!! It blows my mind this is blog-post worthy). Also, I would far rather have a company not hire me because I failed a programming assessment than have them hire me and then fire me a week later because they were finally able to assess my skills.
- jen20 5y ago
  The issue fundamentally is that most people do not use this kind of knowledge on a daily basis - even those of us doing low level work, and when it is needed, it is a mere web search away - or if necessary I can reach for Knuth. I think you misunderstand my notion of a "google gotcha" - I'm not proposing that interviews do not into rigorous technical detail. I'm proposing that interviews that test knowledge of easily-looked-up trivia rather than an understanding of engineering pragmatism and trade-offs are fundamentally flawed and yield markedly worse results than those that do not _regardless_ of company.

maxk42 5y ago

FizzBuzz-style questions are fine. Any coding exercise that takes under 30 minutes and doesn't require you to happen to remember some obscure piece of discrete mathematics trivia.

Rapzid 5y ago

Fire fast.