5 ms·

There is evidence that traditional software engineering interviews[1] assess a candidate's ability to perform under pressure better than their ability to do the

There is evidence that traditional software engineering interviews[1] assess a candidate's ability to perform under pressure better than their ability to do the job. I find it crazy that you need to spend weeks studying leetcode-style problems after doing the job all day in order to prepare for an interview. Coincidentally, I've started working on a product to help this[2]. The general idea is that tasks like pull-requests, bug fixes and realistic take home projects are a better way to test candidates. Everything is done using Github, the tasks are all realistic and candidates can use their own laptop and development environment. It's not fully ready yet, but if anybody wants to chat about it just use the info@ address for the site. [1] https://www.sciencedaily.com/releases/2020/07/200714101228.htm https://www.sciencedaily.com/releases/2020/07/200714101228.h... [2] https://devscreen.io/ https://devscreen.io/

mountainriver 5y ago
This is cool!
javajosh 5y ago
If you can capture the candidates ability to setup a BTD (build-test-debug) loop, their ability to find and fix bugs, and that they know enough tooling to get it into production (and troubleshoot deployment), then you have successfully checked 80% of the job requirements for...almost every programming job out there.
- HWR_14 5y ago
  I'm lost on the "tooling to get it to deployment" test idea. Deployment seems both company (and industry) specific and trivially easy to learn compared to programming skills.
  - javajosh 5y ago
    Great! Today you learned something new: sometimes software deployment is complicated! Get more experience, and you'll find less trivial deployments. "Trivial deployment" is the goal of many systems, and is rarely met.
    - HWR_14 5y ago
      I never said deployments were trivial. I said they were trivial compared to programming skills. And I also said they are both industry and company specific. Expecting a random hire to already be familiar with your deployment process and tools seems very strange. I've done deployments in many situations and, well, I wish there was an industry standard. But as you point out there are many conflicting tools and using them is never turnkey.
      - hiptobecubic 5y ago
        They are industry and company specific, but so is any concrete problem you'd ask anyone to work on. They don't t need to be familiar your specific tools, but they need to be familiar with why they exist and be able to do something similar on their own if needed. Even at a place like Google, where deployment is extremely mature, it's still important to know what's needed to roll your own. As you say, these things are never turnkey.
UncleMeat 5y ago
That paper has been widely misunderstood in these discussions. Both groups were given the same whiteboarding questions. The only difference was whether the interviewer was in the room.
- actually_a_dog 5y ago
  Having the interviewer in the room clearly creates a higher pressure situation.
  - UncleMeat 5y ago
    Sure. But the study does not conclude that coding-challenge interviews are what tests for anxiety management. It only speaks to the effect of having the interviewer be present. But people cite this paper as though it makes an argument against coding-challenge interviews as a whole.
    - actually_a_dog 5y ago
      Is the interviewer typically in the room or no when doing a Leetcode whiteboard interview?
      - UncleMeat 5y ago
        Typically yes. But if a company did leetcode questions without the interviewer in the room, I find it exceedingly unlikely that people would shout "Interviewing has been saved! It now tests skill rather than anxiety!" As such, the conclusions of this paper don't seem especially relevant to the discussion about interviewing processes.
        actually_a_dog 5y ago
        Well, it seems like either you don't understand the concept of incremental improvement, or you're being deliberately obtuse. Taking a good portion of the anxiety out of the situation can only help, right? I don't think anybody is pointing at this paper and saying "if we do this one thing, then interviewing is fixed," except people who are looking for a straw man, do you?

mountainriver 5y ago

This is cool!

javajosh 5y ago

If you can capture the candidates ability to setup a BTD (build-test-debug) loop, their ability to find and fix bugs, and that they know enough tooling to get it into production (and troubleshoot deployment), then you have successfully checked 80% of the job requirements for...almost every programming job out there.

HWR_14 5y ago
I'm lost on the "tooling to get it to deployment" test idea. Deployment seems both company (and industry) specific and trivially easy to learn compared to programming skills.
- javajosh 5y ago
  Great! Today you learned something new: sometimes software deployment is complicated! Get more experience, and you'll find less trivial deployments. "Trivial deployment" is the goal of many systems, and is rarely met.
  - HWR_14 5y ago
    I never said deployments were trivial. I said they were trivial compared to programming skills. And I also said they are both industry and company specific. Expecting a random hire to already be familiar with your deployment process and tools seems very strange. I've done deployments in many situations and, well, I wish there was an industry standard. But as you point out there are many conflicting tools and using them is never turnkey.
    - hiptobecubic 5y ago
      They are industry and company specific, but so is any concrete problem you'd ask anyone to work on. They don't t need to be familiar your specific tools, but they need to be familiar with why they exist and be able to do something similar on their own if needed. Even at a place like Google, where deployment is extremely mature, it's still important to know what's needed to roll your own. As you say, these things are never turnkey.

UncleMeat 5y ago

That paper has been widely misunderstood in these discussions. Both groups were given the same whiteboarding questions. The only difference was whether the interviewer was in the room.

actually_a_dog 5y ago
Having the interviewer in the room clearly creates a higher pressure situation.
- UncleMeat 5y ago
  Sure. But the study does not conclude that coding-challenge interviews are what tests for anxiety management. It only speaks to the effect of having the interviewer be present. But people cite this paper as though it makes an argument against coding-challenge interviews as a whole.
  - actually_a_dog 5y ago
    Is the interviewer typically in the room or no when doing a Leetcode whiteboard interview?
    - UncleMeat 5y ago
      Typically yes. But if a company did leetcode questions without the interviewer in the room, I find it exceedingly unlikely that people would shout "Interviewing has been saved! It now tests skill rather than anxiety!" As such, the conclusions of this paper don't seem especially relevant to the discussion about interviewing processes.
      - actually_a_dog 5y ago
        Well, it seems like either you don't understand the concept of incremental improvement, or you're being deliberately obtuse. Taking a good portion of the anxiety out of the situation can only help, right? I don't think anybody is pointing at this paper and saying "if we do this one thing, then interviewing is fixed," except people who are looking for a straw man, do you?