3 ms·

I think the author is trying to say that interviews are testing for the wrong thing (ability to solve tricky problems quickly, on the fly, and with no help, whi

I think the author is trying to say that interviews are testing for the wrong thing (ability to solve tricky problems quickly, on the fly, and with no help, which is unrealistic in the workplace) when what they should be testing for is good analytical and research skills, with the assistance of the internet available, just like in real life.

pydry 5y ago
Realism is criminally underrated in interviewing.
- rsj_hn 5y ago
  Most likely because an interview is not a probationary period where the candidate does actual work. Neither can it simulate the important parts of doing the work. So you have to look for proxies you believe correlate well with being able to do work and test for those instead. Things that can be reasonable measured in 45 minute chunks, thus the proxies you pick will not at all look like someone doing actual work, they will be far removed from that. Hence they will not be "realistic". But that doesn't mean they aren't informative. So while it's true that having a candidate be able to write code that implements a stack and or whiteboard a simple app is not a realistic scenario of what they will be doing day to day, if they are able to do that well than they are much more likely to be able to do the work than if they are unable to do it well. So you use that as a proxy. Then 5 people interview for an hour, each using a different proxy, and you look at all the information the proxies are telling you to decide whether the candidate should be hired.
  - pydry 5y ago
    >Neither can it simulate the important parts of doing the work. For sure it can. You can combine problem solving, ability to read code, write tests, avoid common pitfalls, clarify requirements all in the space of 45 mins. I typically do this by taking a chunk of real code out of the code base, uncoupling it so it can run on its own and writing some stories.
    - rsj_hn 5y ago
      Without the background information you are not really simulating what happens. But I also took some examples from our code base, abstracted them a bit to remove dependencies on our libraries, simplified the logic and used them in interviews as a "find the bug" type question. I liked that it because you have to read the code, be able to describe what it is trying to do, and then figure out where it goes wrong. Those types of questions have served me well and I always try to ask one when I am asked to interview. But that also was not a realistic description of what happens during a regular workday, but it tries to cover one of the (many) skills you do need, so I think it was a decent proxy. I am not advocating for lots of weird trick questions or brainteasers, but simulating the entire process of design, implementation, test, debug, document, sprint planning and the like. You can't realistically do that in an interview, you pick a few proxies and hope for the best.
      - pydry 5y ago
        It sounds like you achieved a close enough approximation. I find interviews like this give very strong (& often surprising) signals. I don't really object as much to people who try to approximate and don't quite get there than people who decide to just test something that nobody would ever actually do in their job. It's like the difference between having buggy code and a product that just does completely the wrong thing.
  - runawaybottle 5y ago
    Neither can it simulate the important parts of doing the work. I disagree with this. With some effort, you can create a small sandbox app that recreates an exact bug or existing implementation that needs a a feature added to it straight from your day to day work. You can even translate your obscure problem domain into the appropriate analogy.

pydry 5y ago

Realism is criminally underrated in interviewing.

rsj_hn 5y ago
Most likely because an interview is not a probationary period where the candidate does actual work. Neither can it simulate the important parts of doing the work. So you have to look for proxies you believe correlate well with being able to do work and test for those instead. Things that can be reasonable measured in 45 minute chunks, thus the proxies you pick will not at all look like someone doing actual work, they will be far removed from that. Hence they will not be "realistic". But that doesn't mean they aren't informative. So while it's true that having a candidate be able to write code that implements a stack and or whiteboard a simple app is not a realistic scenario of what they will be doing day to day, if they are able to do that well than they are much more likely to be able to do the work than if they are unable to do it well. So you use that as a proxy. Then 5 people interview for an hour, each using a different proxy, and you look at all the information the proxies are telling you to decide whether the candidate should be hired.
- pydry 5y ago
  >Neither can it simulate the important parts of doing the work. For sure it can. You can combine problem solving, ability to read code, write tests, avoid common pitfalls, clarify requirements all in the space of 45 mins. I typically do this by taking a chunk of real code out of the code base, uncoupling it so it can run on its own and writing some stories.
  - rsj_hn 5y ago
    Without the background information you are not really simulating what happens. But I also took some examples from our code base, abstracted them a bit to remove dependencies on our libraries, simplified the logic and used them in interviews as a "find the bug" type question. I liked that it because you have to read the code, be able to describe what it is trying to do, and then figure out where it goes wrong. Those types of questions have served me well and I always try to ask one when I am asked to interview. But that also was not a realistic description of what happens during a regular workday, but it tries to cover one of the (many) skills you do need, so I think it was a decent proxy. I am not advocating for lots of weird trick questions or brainteasers, but simulating the entire process of design, implementation, test, debug, document, sprint planning and the like. You can't realistically do that in an interview, you pick a few proxies and hope for the best.
    - pydry 5y ago
      It sounds like you achieved a close enough approximation. I find interviews like this give very strong (& often surprising) signals. I don't really object as much to people who try to approximate and don't quite get there than people who decide to just test something that nobody would ever actually do in their job. It's like the difference between having buggy code and a product that just does completely the wrong thing.
- runawaybottle 5y ago
  Neither can it simulate the important parts of doing the work. I disagree with this. With some effort, you can create a small sandbox app that recreates an exact bug or existing implementation that needs a a feature added to it straight from your day to day work. You can even translate your obscure problem domain into the appropriate analogy.