4 ms·

I'm not the author (perhaps he'll chime in as well), but I'm the CEO of interviewing.io (we're the ones who ran the experiment). I think it depends on whether

by leeny 3y ago

I'm not the author (perhaps he'll chime in as well), but I'm the CEO of interviewing.io (we're the ones who ran the experiment). I think it depends on whether the interviewer has agreed to make the interview "open book". Looking up stuff on Stack Overflow during the interview can be OK or can be cheating, depending on the constraints. In this experiment, the interviews were not "open book". That said, I am personally in favor of open book interviews.

michael_mroczka 3y ago
I AM the author, and I also am in favor of "open book" interviews. I'm not against ChatGPT use in interviews, but if you're doing it secretly in an interview that clearly is meant to be "closed book," I think it's fair to say you're cheating.
- pierat 3y ago
  Well that's the rub. There's no way, even for a senior engineer, to know everything. In fact, one of the required skills is "how to ask the question as to elicit the answer in a reasonable amount of time". The closed-book crap can stay closed in the universities and schools demanding a regurgitation of mostly-right knowledge. Now... The skill of asking the right Qs also directly intersects with LLMs, and how to discern good/bad responses. But hiding it? Yeah, probably not a good fit.
  - vinni2 3y ago
    > The closed-book crap can stay closed in the universities and schools demanding a regurgitation of mostly-right knowledge. I work at a university and most of our exams are open book or project based. You probably want to update your image of universities.
    - ziddoap 3y ago
      >You probably want to update your image of universities. I have a close friend who is a prof at a university and most exams remain closed book. You probably want to update your image of universities. Or, perhaps, we can agree that it depends on the university, the subject, etc. and blanket statements based on single anecdotes are silly?
- randomdata 3y ago
  > an interview that clearly is meant to be "closed book," I am not sure that is clear. It seems the expectation was not "closed book", but "never opened a book before, not even in the past": "It's tough to determine if the candidate breezed through the question because they're actually good or if they've heard this question before." Clearly the interviewers were looking not for knowledge, but for uncanny ability. How well was that communicated to the interviewees? It is not cheating if the rules of the game are not defined.
- gabrieledarrigo 3y ago
  > but if you're doing it secretly in an interview that clearly is meant to be "closed book," I think it's fair to say you're cheating. I would argue that is the opposite: it's fair to say that the interview is a cheat.
- jacques_chester 3y ago
  > I also am in favor of "open book" interviews. I recall reading an interviewing.io blog post[0] in which the dominant considerations interviewers weighed were (my interpretation): (1) Did they solve the problem optimally? (2) How fluid was their coding? With "communication" turning out to be basically worthless for predicting hire/no-hire decisions. Perception of coding fluidity seems like it would be affected by how often the candidate stops and looks up things like library functions or obscure syntax. For that reason I've been investing time in committing a lot of library functions to memory, so they instantly flow from my fingers rather than spending a minute looking it up. It's dumb that I need to do this, but I don't make the rules. I'm just at the bottom of the information cascade that led to how things are done now. [0] https://interviewing.io/blog/does-communication-matter-in-technical-interviewing-we-looked-at-100k-interviews-to-find-out https://interviewing.io/blog/does-communication-matter-in-te...
  - madeofpalk 3y ago
    Companies that optimise for memorising obscure stdlib functions don't seem like great places to work.
    - spongebobstoes 3y ago
      Occasionally looking something up is normal, but if you don't know how to append to a list in Python or iterate over a vector in C++ then you probably are not currently writing much code in those languages. That's a signal by itself, and one that is too often a negative.
      - mark38848 3y ago
        Why? Maybe you just use good programming languages instead.
      - doix 3y ago
        I'm not saying you're wrong, but that reasoning is why I have to prepare for interviews. I'm _really_ bad at remembering that stuff, I think it really depends on how you think while programming. I've got an abstraction that I think in that then needs to be translated to code. e.g. if I want to append to a list, I think "push to list", regardless of language/framework/whatever. Then somehow my hands will translate that automatically to code in the language I'm working in. If I'm not in my usual editing environment, that magic just sort of breaks, and I just look incompetent. It's not a huge deal, but I have to actively sit and memorize that stuff before an interview. Usually by writing it out on paper or writing it in some foreign editor that I'm not used too. It probably wouldn't be _too_ bad today, because I just sit and write Typescript everyday, but when I was switching between perl/ruby/python/tcl/kotlin/javascript/bash/csh/lisp my brain was basically mush. I couldn't tell you how to do any basic operation in any language.
BriggyDwiggs42 3y ago
Given your knowledge of the subject, do you think leetcode-type questions are meaningfully able to appraise an employee’s performance in a production environment? I’ve always thought it was basically unrelated beyond testing basic coding experience.
- michael_mroczka 3y ago
  The short answer is, "Yes." They are very flawed, but one of the most reliable ways to avoid "bad" hires. The longer answer is: Fundamentally, you need to address the fact that there exist a huge number of people in this industry declaring they have masters degrees/phds or years of industry experience, but when pressed they can't write even the simplest of functions. While we called it out explicitly, some folks seem to miss that "Custom" questions are still fundamentally DS&A leetcode-style questions. I completely agree that "leetcode style" interviews are flawed, but most people don't have a better answer for this problem that still guarantees the person you're hiring actually can code. We are optimizing for coders that make good choices quickly, and if they can code efficient code to toy CS problems, then you at least guarantee that 1) they can actually code and 2) they can code simple things quickly. Non-coding interviews allow you to hire people who can't do these basic things and therefore guarantee their performance is worse in a production environment.
  - consp 3y ago
    You forget where you lose good hires since leetcode questions are pathetic and demeaning for anyone with experience.
    - trgdr 3y ago
      Keep it civil, dude. This is a pretty reductive take that is not obviously true and adds little to the discussion.
    - michael_mroczka 3y ago
      Let's keep it civil, my friend. I totally get the frustration with leetcode-style questions and acknowledge that they aren't perfect. They can indeed overlook the diverse strengths that experienced engineers bring to the table. My perspective is that understanding the basics, like the efficiency of different data structures, is crucial, not just for interviews but for making informed decisions in our work. I'm not advocating for spot tests on complex algorithms without context. However, I believe a conversation about fundamental concepts like big-O notation reflects on one's approach to problem-solving and software design. It's not about dismissing anyone's experience or capability but ensuring a solid foundation that benefits all aspects of engineering work. I understand senior engineers being out of practice and not being able to derive things like topological sort on the fly, but an inability to talk about the basics of big-O or the simplest of data structures is more commonly a red flag than "rust." If they never learned the material, that's a red flag. If they learned the material and they've been building software for the last decade without taking the basics of the material into account while coding, then that is a red flag as well. Again, happy to admit that this is a flawed approach that will lose some great engineers, but most engineers that have your line of thinking are ones I actively avoid hiring. These concepts are practical, available to learn for free, and easy to understand. If an engineer feels that testing these concepts is beneath them, then they definitely aren't a good fit for any team I'm on. Big-O is to software engineers what Ohm's Law is to electricians. Imagine a world where electricians thought it was demeaning to talk about Ohm's law in an interview. ¯\_(ツ)_/¯
blitzar 3y ago
I have been part of a few interview tests that were proudly "open book". However, if you are going to read the context and tasks then build 20 spreadsheets in 20 minutes you have 0 time to google something.

by leeny 3y ago

michael_mroczka 3y ago

I AM the author, and I also am in favor of "open book" interviews. I'm not against ChatGPT use in interviews, but if you're doing it secretly in an interview that clearly is meant to be "closed book," I think it's fair to say you're cheating.

pierat 3y ago
Well that's the rub. There's no way, even for a senior engineer, to know everything. In fact, one of the required skills is "how to ask the question as to elicit the answer in a reasonable amount of time". The closed-book crap can stay closed in the universities and schools demanding a regurgitation of mostly-right knowledge. Now... The skill of asking the right Qs also directly intersects with LLMs, and how to discern good/bad responses. But hiding it? Yeah, probably not a good fit.
- vinni2 3y ago
  > The closed-book crap can stay closed in the universities and schools demanding a regurgitation of mostly-right knowledge. I work at a university and most of our exams are open book or project based. You probably want to update your image of universities.
  - ziddoap 3y ago
    >You probably want to update your image of universities. I have a close friend who is a prof at a university and most exams remain closed book. You probably want to update your image of universities. Or, perhaps, we can agree that it depends on the university, the subject, etc. and blanket statements based on single anecdotes are silly?
randomdata 3y ago
> an interview that clearly is meant to be "closed book," I am not sure that is clear. It seems the expectation was not "closed book", but "never opened a book before, not even in the past": "It's tough to determine if the candidate breezed through the question because they're actually good or if they've heard this question before." Clearly the interviewers were looking not for knowledge, but for uncanny ability. How well was that communicated to the interviewees? It is not cheating if the rules of the game are not defined.
gabrieledarrigo 3y ago
> but if you're doing it secretly in an interview that clearly is meant to be "closed book," I think it's fair to say you're cheating. I would argue that is the opposite: it's fair to say that the interview is a cheat.
jacques_chester 3y ago
> I also am in favor of "open book" interviews. I recall reading an interviewing.io blog post[0] in which the dominant considerations interviewers weighed were (my interpretation): (1) Did they solve the problem optimally? (2) How fluid was their coding? With "communication" turning out to be basically worthless for predicting hire/no-hire decisions. Perception of coding fluidity seems like it would be affected by how often the candidate stops and looks up things like library functions or obscure syntax. For that reason I've been investing time in committing a lot of library functions to memory, so they instantly flow from my fingers rather than spending a minute looking it up. It's dumb that I need to do this, but I don't make the rules. I'm just at the bottom of the information cascade that led to how things are done now. [0] https://interviewing.io/blog/does-communication-matter-in-technical-interviewing-we-looked-at-100k-interviews-to-find-out https://interviewing.io/blog/does-communication-matter-in-te...
- madeofpalk 3y ago
  Companies that optimise for memorising obscure stdlib functions don't seem like great places to work.
  - spongebobstoes 3y ago
    Occasionally looking something up is normal, but if you don't know how to append to a list in Python or iterate over a vector in C++ then you probably are not currently writing much code in those languages. That's a signal by itself, and one that is too often a negative.
    - mark38848 3y ago
      Why? Maybe you just use good programming languages instead.
    - doix 3y ago
      I'm not saying you're wrong, but that reasoning is why I have to prepare for interviews. I'm _really_ bad at remembering that stuff, I think it really depends on how you think while programming. I've got an abstraction that I think in that then needs to be translated to code. e.g. if I want to append to a list, I think "push to list", regardless of language/framework/whatever. Then somehow my hands will translate that automatically to code in the language I'm working in. If I'm not in my usual editing environment, that magic just sort of breaks, and I just look incompetent. It's not a huge deal, but I have to actively sit and memorize that stuff before an interview. Usually by writing it out on paper or writing it in some foreign editor that I'm not used too. It probably wouldn't be _too_ bad today, because I just sit and write Typescript everyday, but when I was switching between perl/ruby/python/tcl/kotlin/javascript/bash/csh/lisp my brain was basically mush. I couldn't tell you how to do any basic operation in any language.

BriggyDwiggs42 3y ago

Given your knowledge of the subject, do you think leetcode-type questions are meaningfully able to appraise an employee’s performance in a production environment? I’ve always thought it was basically unrelated beyond testing basic coding experience.

michael_mroczka 3y ago
The short answer is, "Yes." They are very flawed, but one of the most reliable ways to avoid "bad" hires. The longer answer is: Fundamentally, you need to address the fact that there exist a huge number of people in this industry declaring they have masters degrees/phds or years of industry experience, but when pressed they can't write even the simplest of functions. While we called it out explicitly, some folks seem to miss that "Custom" questions are still fundamentally DS&A leetcode-style questions. I completely agree that "leetcode style" interviews are flawed, but most people don't have a better answer for this problem that still guarantees the person you're hiring actually can code. We are optimizing for coders that make good choices quickly, and if they can code efficient code to toy CS problems, then you at least guarantee that 1) they can actually code and 2) they can code simple things quickly. Non-coding interviews allow you to hire people who can't do these basic things and therefore guarantee their performance is worse in a production environment.
- consp 3y ago
  You forget where you lose good hires since leetcode questions are pathetic and demeaning for anyone with experience.
  - trgdr 3y ago
    Keep it civil, dude. This is a pretty reductive take that is not obviously true and adds little to the discussion.
  - michael_mroczka 3y ago
    Let's keep it civil, my friend. I totally get the frustration with leetcode-style questions and acknowledge that they aren't perfect. They can indeed overlook the diverse strengths that experienced engineers bring to the table. My perspective is that understanding the basics, like the efficiency of different data structures, is crucial, not just for interviews but for making informed decisions in our work. I'm not advocating for spot tests on complex algorithms without context. However, I believe a conversation about fundamental concepts like big-O notation reflects on one's approach to problem-solving and software design. It's not about dismissing anyone's experience or capability but ensuring a solid foundation that benefits all aspects of engineering work. I understand senior engineers being out of practice and not being able to derive things like topological sort on the fly, but an inability to talk about the basics of big-O or the simplest of data structures is more commonly a red flag than "rust." If they never learned the material, that's a red flag. If they learned the material and they've been building software for the last decade without taking the basics of the material into account while coding, then that is a red flag as well. Again, happy to admit that this is a flawed approach that will lose some great engineers, but most engineers that have your line of thinking are ones I actively avoid hiring. These concepts are practical, available to learn for free, and easy to understand. If an engineer feels that testing these concepts is beneath them, then they definitely aren't a good fit for any team I'm on. Big-O is to software engineers what Ohm's Law is to electricians. Imagine a world where electricians thought it was demeaning to talk about Ohm's law in an interview. ¯\_(ツ)_/¯

blitzar 3y ago

I have been part of a few interview tests that were proudly "open book". However, if you are going to read the context and tasks then build 20 spreadsheets in 20 minutes you have 0 time to google something.