4 ms·

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 th

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.

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.