3 ms·

> Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work. Not to disparage the subjects, b

> Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work. Not to disparage the subjects, but it sounds like these applicants failed the interview. If a qualified candidate is meant to complete the project in 2-3 hours and it's taking over a day, then that candidate isn't passing this test of productivity. However, companies absolutely should be time-limiting their problems. Precisely because people could use more time than others and generate false positives.

ozim 3y ago
How do I schedule 2-3 hours right away after you send me a task? I tell people to do it over the weekend and don’t really count the time. Code solution can be bad and if someone returns bad code after he was able to pick his time. Well. Some people refuse to do 1-2hr take home task, I also thank them for the time. Some people take 2 weeks and then I usually have someone who did task last weekend so I pick one that did it earlier. Some people do it right away after getting task I schedule 2nd round also asap for them. You see I don’t have to limit time just pick candidates that are interested enough to do the task. Also sometimes most productive employees are worst. We had a guy that was so productive refactoring BS in code that he took down month or two months of work of the team.
- Manuel_D 3y ago
  The timer starts when the problem is revealed. That's how it worked at a company I previously interviewed at. They sent me a link to a page that explained the 3 hour time limit once the prompt is revealed. I had I think two weeks to choose when to start the problem. It was a totally automated interview
  - ozim 3y ago
    Fair enough, I also took some of these interview tasks where you get the link and time counts from when you accessed, totally forgot about them.
EchoChamberMan 3y ago
Companies are notoriously bad at determining how long software development will take, hence the entirety of Jira et al. How accurate do you think their "2-3 hours" estimate really is? These take homes are also only one of the many ridiculous asks made of candidates. I've seen "Talk for an hour about a project you've worked on," as one step in the process. [Edit] Let me tell you, their estimates are not accurate. Just like the job descriptions, they throw a bunch of stuff in and see what they like.
- Manuel_D 3y ago
  If the actually set a time limit, they would notice the vast majority of candidates failing. I took a test like this for a job application once, I had 180 minutes for a task that took an hour to actually implement, and I spent another 30 minutes testing.
  - EchoChamberMan 3y ago
    Of course, but this is take home with a completely unenforceable time limit. Well, you can enforce it to some extent as someone mentioned. If you give the test friday and say two days, and they turn it in a week later, they've obviously blown the limit.
    - Manuel_D 3y ago
      No, the time limit is enforced. The way it worked when I took this kind of problem is that the company sent me a link to a web page that explained how the 3 hour timer would start when I viewed the prompt. I could choose to view the prompt whenever I wanted, within the next two weeks. I entered my solution in a leet code sort of editor. Presumably it would lock me out if I didn't submit within 3 hours of viewing the prompt.
      - EchoChamberMan 3y ago
        We're starting to go in circles, but here's your quote with the preceding sentence, emphasis mine. You're discussing an online test, not really a take home as described in the article. > Take-home coding tests used to be rare, deployed only if an employer needed to be further convinced. Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work. [Edit] They should probably call it a "take home project" to be more accurate. It can include front and back end code, tests, documentation, design, styling, etc. etc. "2-3 hours," yea right.
WorldMaker 3y ago
It feels like another variation of the Halting Problem. If it is easy to objectively determine how long completing a test project is then it probably isn't Turing Complete or a good test of programming skill, is it? Time limits encourage quick and dirty solutions, often with much emphasis on the dirty, and discourage candidates with carefully thought out solutions or other "senior engineer" habits like TDD or i18n or a11y or documentation or… The list goes on and if the whole point of the exercise is to gauge someone's experience level the more experience they've accumulated the harder they have to "paint within the lines" of your arbitrary time limit.
- EchoChamberMan 3y ago
  "Oh sorry, you didn't include tests - goodbye!" [Edit] I'm a big fan of documentation, but that is the absolutely last thing these processes are interested in.
  - WorldMaker 3y ago
    The point of making something a habit is that you do it every time whether "it needs it or not" because you never know when that documentation will be useful and if you document everything you are more likely to document the things you really need. If your interview processes aren't interested in me at my most habitual then you are also directly sending me a signal that your culture doesn't care about i18n/a11y/documentation/tests/…. You are only as good as your sloppiest code and you are interviewing for sloppy code.
    - EchoChamberMan 3y ago
      Ah, to have unlimited time and or options. "Screen the company" is pretty sad advice for most people who have no choices. I must have misunderstood your point.
      - WorldMaker 3y ago
        It's always a two-way process whether we like it or not. Some of the companies I've hit time limits on or got ghosted in feedback processes after a greatly asymmetric amount of labor in interview processes (I've never yet met a company putting a commensurate amount of labor into their interview responses than what they've asked for from candidates) could greatly use my skills. They aren't actually interviewing for my skills. I can't help but see that as a failure on their part. Not because I'm particularly great (I've got plenty of imposter syndrome to deal with, sorry), but because their interviews are particularly shit and they are absolutely saying in their choices of interview that they aren't hiring for skilled labor, they are hiring for bottom of the barrel, quick/dirty/disgusting talent and they don't care who knows it. Technical interviews aren't about finding skills, they are about finding people with too much labor on their hands skilled or not. They are about finding people willing to do bad solutions quickly just to pass a test, not about if they have any actual skills at writing good production code. We don't have a standardized test for "good production code" so we keep using a bunch of terrible half-assed semi-problems to approximate it, then adding timers on top because arbitrary deadlines are the only thing we know as an industry for how to get work "done". We aren't testing for what we actually want and we don't know how (and we can't afford to actually pay for the labor involved so that the answers aren't just half-assed AI solutions), so let's keep testing half-assed shit and maybe we'll get "good" candidates, maybe.~

ozim 3y ago

How do I schedule 2-3 hours right away after you send me a task? I tell people to do it over the weekend and don’t really count the time. Code solution can be bad and if someone returns bad code after he was able to pick his time. Well. Some people refuse to do 1-2hr take home task, I also thank them for the time. Some people take 2 weeks and then I usually have someone who did task last weekend so I pick one that did it earlier. Some people do it right away after getting task I schedule 2nd round also asap for them. You see I don’t have to limit time just pick candidates that are interested enough to do the task. Also sometimes most productive employees are worst. We had a guy that was so productive refactoring BS in code that he took down month or two months of work of the team.

Manuel_D 3y ago
The timer starts when the problem is revealed. That's how it worked at a company I previously interviewed at. They sent me a link to a page that explained the 3 hour time limit once the prompt is revealed. I had I think two weeks to choose when to start the problem. It was a totally automated interview
- ozim 3y ago
  Fair enough, I also took some of these interview tasks where you get the link and time counts from when you accessed, totally forgot about them.

EchoChamberMan 3y ago

Companies are notoriously bad at determining how long software development will take, hence the entirety of Jira et al. How accurate do you think their "2-3 hours" estimate really is? These take homes are also only one of the many ridiculous asks made of candidates. I've seen "Talk for an hour about a project you've worked on," as one step in the process. [Edit] Let me tell you, their estimates are not accurate. Just like the job descriptions, they throw a bunch of stuff in and see what they like.

Manuel_D 3y ago
If the actually set a time limit, they would notice the vast majority of candidates failing. I took a test like this for a job application once, I had 180 minutes for a task that took an hour to actually implement, and I spent another 30 minutes testing.
- EchoChamberMan 3y ago
  Of course, but this is take home with a completely unenforceable time limit. Well, you can enforce it to some extent as someone mentioned. If you give the test friday and say two days, and they turn it in a week later, they've obviously blown the limit.
  - Manuel_D 3y ago
    No, the time limit is enforced. The way it worked when I took this kind of problem is that the company sent me a link to a web page that explained how the 3 hour timer would start when I viewed the prompt. I could choose to view the prompt whenever I wanted, within the next two weeks. I entered my solution in a leet code sort of editor. Presumably it would lock me out if I didn't submit within 3 hours of viewing the prompt.
    - EchoChamberMan 3y ago
      We're starting to go in circles, but here's your quote with the preceding sentence, emphasis mine. You're discussing an online test, not really a take home as described in the article. > Take-home coding tests used to be rare, deployed only if an employer needed to be further convinced. Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work. [Edit] They should probably call it a "take home project" to be more accurate. It can include front and back end code, tests, documentation, design, styling, etc. etc. "2-3 hours," yea right.

WorldMaker 3y ago

It feels like another variation of the Halting Problem. If it is easy to objectively determine how long completing a test project is then it probably isn't Turing Complete or a good test of programming skill, is it? Time limits encourage quick and dirty solutions, often with much emphasis on the dirty, and discourage candidates with carefully thought out solutions or other "senior engineer" habits like TDD or i18n or a11y or documentation or… The list goes on and if the whole point of the exercise is to gauge someone's experience level the more experience they've accumulated the harder they have to "paint within the lines" of your arbitrary time limit.

EchoChamberMan 3y ago
"Oh sorry, you didn't include tests - goodbye!" [Edit] I'm a big fan of documentation, but that is the absolutely last thing these processes are interested in.
- WorldMaker 3y ago
  The point of making something a habit is that you do it every time whether "it needs it or not" because you never know when that documentation will be useful and if you document everything you are more likely to document the things you really need. If your interview processes aren't interested in me at my most habitual then you are also directly sending me a signal that your culture doesn't care about i18n/a11y/documentation/tests/…. You are only as good as your sloppiest code and you are interviewing for sloppy code.
  - EchoChamberMan 3y ago
    Ah, to have unlimited time and or options. "Screen the company" is pretty sad advice for most people who have no choices. I must have misunderstood your point.
    - WorldMaker 3y ago
      It's always a two-way process whether we like it or not. Some of the companies I've hit time limits on or got ghosted in feedback processes after a greatly asymmetric amount of labor in interview processes (I've never yet met a company putting a commensurate amount of labor into their interview responses than what they've asked for from candidates) could greatly use my skills. They aren't actually interviewing for my skills. I can't help but see that as a failure on their part. Not because I'm particularly great (I've got plenty of imposter syndrome to deal with, sorry), but because their interviews are particularly shit and they are absolutely saying in their choices of interview that they aren't hiring for skilled labor, they are hiring for bottom of the barrel, quick/dirty/disgusting talent and they don't care who knows it. Technical interviews aren't about finding skills, they are about finding people with too much labor on their hands skilled or not. They are about finding people willing to do bad solutions quickly just to pass a test, not about if they have any actual skills at writing good production code. We don't have a standardized test for "good production code" so we keep using a bunch of terrible half-assed semi-problems to approximate it, then adding timers on top because arbitrary deadlines are the only thing we know as an industry for how to get work "done". We aren't testing for what we actually want and we don't know how (and we can't afford to actually pay for the labor involved so that the answers aren't just half-assed AI solutions), so let's keep testing half-assed shit and maybe we'll get "good" candidates, maybe.~