5 ms·

This is what we do. We created a small programming test that's very representative of 80% of our work. Candidates are asked to only spend 2 hours on it. If they

by brango 9y ago

This is what we do. We created a small programming test that's very representative of 80% of our work. Candidates are asked to only spend 2 hours on it. If they can follow simple instructions and write a reasonable implementation we'll have a face-to-face. This saves us a huge amount of time and I don't feel it's overly burdensome on candidates.

crdoconnor 9y ago
>I don't feel it's overly burdensome on candidates. I do. After doing a couple of these "2 hour" projects from companies I have a suspicion were not even really serious about hiring and not even receiving a courtesy rejection email I swore off them forever. These days I just point the company to my github and am explicit that if that isn't enough to grant me a face to face I probably don't want to work there.
- osi 9y ago
  agreed. if it is a "2 hour" project, have that be part of the on-site interview (with the expectation that people might not complete it)
  - crankylinuxuser 9y ago
    I applied to one position here on a HN job thread a bit back. Looked right up my alley. Doing IoT, 3d modeling, circuit design, and glue code. So, I did the initial phone screen. Then they gave me the 'zinger': we want you to make a webapp for us. We expect this will take 8-12 hours (?!). I responded back, that's billable time there. That would require me to take PTO at my current job, and do your work unpaid. And that, I will not do. I kindly told them where they could put their job. (They still advertise jobs on the monthly, but they seem legit aside that onerous 1.5 days of work. And no, I won't mention whom. Hopefully they'll rethink their policies, but alas..)
    - ryandrake 9y ago
      On behalf of many, many people: Thank you! An 8-12 hour unpaid work assignment is an entirely unreasonable request.
      - crankylinuxuser 9y ago
        Sure thing! Yeah, I did ask around in their area with fellow engineer-y types. They are a legit company, and the webapp wasn't a way to get free work. Think of it as a standards approach, rather than bulletpoint resumes that verge on untruth. To be honest, I'd prefer they have a sit-down with me. They can do their fizzbuzz or linked list test, but I want to get a feel of the problems they're fighting with. I've always liked deep technical discussions, and how I would do it vs how they would/did it. It's a bit more subjective, but I would think that discussing technical aspects and asking how I (interviewee) would do it. I offered an IoT project Ive developed myself in lieu of it, so they could comment on my code quality. They declined that, and wanted their webapp. They're missing out :) Although I've an interview with GitLab coming up. Everything I've seen how they operate and treat their people is just awesome. Regardless if I'm a good fit for the position they're offering, I still think highly of them. :)
  - brango 9y ago
    The thing is, as gilleain says, the majority of promising-sounding candidates aren't worth progressing with. This is a combination of: * Failing outright to do anything even close to the requested task * Not even basic error handling * No tests * Using generated code where it's not appropriate, or not bothering to implement e.g. catch blocks they've generated The instructions explicitly tell candidates what we're looking for, so it's not worth chatting to someone without doing this filter.
    - rhizome 9y ago
      Just a month ago I had a company task me with implementing an xSV parser with four cases, the fourth being "arbitrary delimiter." I implemented all cases except this last one (only because of time) and included the tests and benchmarks offered as "extra credit." Ghosted.
    - expertentipp 9y ago
      Take home assignment is basically an inquisition-style "accuse yourself" situation. Implemented the requirements? Sorry, there are no tests and we took them as granted. Skipped non-trivial part of the task? Sorry, the implementation is incomplete. Used XHR? Sorry, Fetch API is the thing. Used Fetch API? Sorry, async/await are the thing. You sent URL to a repository? Sorry, we wanted an attachment. You sent the code as an attachment? Sorry, our spam filter threw it away. ENOUGH. I'm applying simultaneously to tens of companies, if you insist I can send you a link to my repositories with all take home assignments I've done so far.
  - logfromblammo 9y ago
    The best jobs I have ever had spent less than 2 hours total in on-site interviews. The worst companies that I never heard from again burned a whole day running me through the gauntlet.
- tn_ 9y ago
  Someone sounds pretty entitled. You know how burdensome it'd be to verify that your repos were fully yours and how much energy an employer would have to exert to make sure everything was connected/architected well vs using a template I'd be already familiar with / created, that could be slightly altered to avoid it circulating the internet. 2 hours is not unreasonable for a take home project with the entire internet at your disposal. People need to be motivated to join the company they're applying to! (Anything more is definitely unfair for the candidate and doesn't scale well when reviewing code) This notion that 2 hours is a lot of time, well plenty of engineers would rather have that than waste a few months memorizing algorithms they'll rarely use. It's pretty common for algorithm tests to be an hour long anyway. So many software engineers have it backwards. Companies don't work for you, you're not even in the door yet. Unless you're a vp or principal engineer with a stellar bg, your tasks are replicable and most employers aren't going to be drooling over to get you on board as entitled / piss-poor attitude is going to cause more friction than it's worth.
  - _jal 9y ago
    Eh. There is this thing called a market. Sometimes producers have the whip-hand, sometimes it is the consumers. We have markets in labor, and anyone who (for instance) weathered the 2000 dot.com bust knows, employers in tech don't hesitate to use it when the wheel turns. I refused a homework project for one firm[1]. It was a highly specific problem that only made sense for one specific version of an app server, and was really a lot of work with some tricky edge cases. Call me entitled, but after I made sure I understood what he was asking, told the interviewer where he could put his homework. I think it is important to keep a sense of the power dynamic. It is really easy to start moralizing to the powerless (here, employees) when they do find themselves with bit of leverage for a change. Not only is it a bad look - punching down is for insecure assholes - systems break down without feedback and (sometimes) pushback. [1] Well known, I'm not naming names because it probably was a fluke.
  - crdoconnor 9y ago
    >Someone sounds pretty entitled. Maybe the guy who wants me to volunteer 2 hours of my time before deigning to have a conversation with me? >You know how burdensome it'd be to verify that your repos were fully yours I've never interviewed anybody who lied about the provenance of their repos. I'm pretty sure if I did, it would come out in a 5 minute conversation during the interview. If one or two gifted liars slipped through the hiring funnel into the interview stage before being found out I wouldn't view it as a tragedy. >This notion that 2 hours is a lot of time, well plenty of engineers would rather have that than waste a few months memorizing algorithms they'll rarely use. 2 hours is fine for an interview, but it's way too long to spend on a speculative application for one company.
- brango 9y ago
  > These days I just point the company to my github and am explicit that if that isn't enough to grant me a face to face I probably don't want to work there. I'd be happy with that if the projects looked they were yours. I can count on one hand the number of candidates who have had GH profiles, and even fewer with anything worth looking at. All I really want to see is a few examples of coding style and basic thinking. To me, being an engaged participant in the open source community is a massively positive signal, even if it's just reporting issues and the very occasional PR.
- hinkley 9y ago
  Last interview cycle I got 10 hours of homework total from three of my prospects. It’s not that it’s 2 hours, or four. It’s that you’ve given two hours to twenty people and so have five other companies.
gilleain 9y ago
We do the same. It's amazing to me how many people with superficially impressive CVs do one or more of: * Cheat * Fail to follow simple instructions * Write no tests for there code (even the given examples!) * Just horribly fail to implement an algorithm All in all, it's just a filter to be used before proper face-to-face interviews.
- ryandrake 9y ago
  > Write no tests for there code (even the given examples!) Just curious, do the instructions ask for tests? If one of these "programming quizzes" asked me to implement algorithm XYZ, I would follow it to the letter and implement only the algorithm.
  - gilleain 9y ago
    we don't ask them to actually provide their tests, but implementing a non-trivial algorithm without tests is optimistic at best. we give them a couple of examples (input, output) pairs - surely you would at least run your implementation past these, right?
- crankylinuxuser 9y ago
  > Write no tests for their[sp] code (even the given examples!) Well, I've been on the fence on this one. With imperative languages, testing is pretty much a requirement because of side effects and scope-creep (nahh, throw it into global). Tests can be a good sanity check for simple checks like "I fixed a bug where X is supposed to give 22. Lets verify that"... But the problem is the tests are then code that can update and rot as main code changes occur. I've preferred a more functional method. I don't want to test - I want to prove a function handles its inputs and provides the correct outputs. Unless there's a good reason for state , I prefer keeping functions clean. And even then, with state (say, a tally function for bandwidth), I prefer to have the variable updated with its own function. Keeps clean/nonclean separate. Now.. one thing that's absolutely not acceptable is not commenting code. "Magic sequence in perl doing 6 things unintuitively" is not code comments. :(
  - 9y ago

by brango 9y ago

crdoconnor 9y ago

>I don't feel it's overly burdensome on candidates. I do. After doing a couple of these "2 hour" projects from companies I have a suspicion were not even really serious about hiring and not even receiving a courtesy rejection email I swore off them forever. These days I just point the company to my github and am explicit that if that isn't enough to grant me a face to face I probably don't want to work there.

osi 9y ago
agreed. if it is a "2 hour" project, have that be part of the on-site interview (with the expectation that people might not complete it)
- crankylinuxuser 9y ago
  I applied to one position here on a HN job thread a bit back. Looked right up my alley. Doing IoT, 3d modeling, circuit design, and glue code. So, I did the initial phone screen. Then they gave me the 'zinger': we want you to make a webapp for us. We expect this will take 8-12 hours (?!). I responded back, that's billable time there. That would require me to take PTO at my current job, and do your work unpaid. And that, I will not do. I kindly told them where they could put their job. (They still advertise jobs on the monthly, but they seem legit aside that onerous 1.5 days of work. And no, I won't mention whom. Hopefully they'll rethink their policies, but alas..)
  - ryandrake 9y ago
    On behalf of many, many people: Thank you! An 8-12 hour unpaid work assignment is an entirely unreasonable request.
    - crankylinuxuser 9y ago
      Sure thing! Yeah, I did ask around in their area with fellow engineer-y types. They are a legit company, and the webapp wasn't a way to get free work. Think of it as a standards approach, rather than bulletpoint resumes that verge on untruth. To be honest, I'd prefer they have a sit-down with me. They can do their fizzbuzz or linked list test, but I want to get a feel of the problems they're fighting with. I've always liked deep technical discussions, and how I would do it vs how they would/did it. It's a bit more subjective, but I would think that discussing technical aspects and asking how I (interviewee) would do it. I offered an IoT project Ive developed myself in lieu of it, so they could comment on my code quality. They declined that, and wanted their webapp. They're missing out :) Although I've an interview with GitLab coming up. Everything I've seen how they operate and treat their people is just awesome. Regardless if I'm a good fit for the position they're offering, I still think highly of them. :)
- brango 9y ago
  The thing is, as gilleain says, the majority of promising-sounding candidates aren't worth progressing with. This is a combination of: * Failing outright to do anything even close to the requested task * Not even basic error handling * No tests * Using generated code where it's not appropriate, or not bothering to implement e.g. catch blocks they've generated The instructions explicitly tell candidates what we're looking for, so it's not worth chatting to someone without doing this filter.
  - rhizome 9y ago
    Just a month ago I had a company task me with implementing an xSV parser with four cases, the fourth being "arbitrary delimiter." I implemented all cases except this last one (only because of time) and included the tests and benchmarks offered as "extra credit." Ghosted.
  - expertentipp 9y ago
    Take home assignment is basically an inquisition-style "accuse yourself" situation. Implemented the requirements? Sorry, there are no tests and we took them as granted. Skipped non-trivial part of the task? Sorry, the implementation is incomplete. Used XHR? Sorry, Fetch API is the thing. Used Fetch API? Sorry, async/await are the thing. You sent URL to a repository? Sorry, we wanted an attachment. You sent the code as an attachment? Sorry, our spam filter threw it away. ENOUGH. I'm applying simultaneously to tens of companies, if you insist I can send you a link to my repositories with all take home assignments I've done so far.
- logfromblammo 9y ago
  The best jobs I have ever had spent less than 2 hours total in on-site interviews. The worst companies that I never heard from again burned a whole day running me through the gauntlet.
tn_ 9y ago
Someone sounds pretty entitled. You know how burdensome it'd be to verify that your repos were fully yours and how much energy an employer would have to exert to make sure everything was connected/architected well vs using a template I'd be already familiar with / created, that could be slightly altered to avoid it circulating the internet. 2 hours is not unreasonable for a take home project with the entire internet at your disposal. People need to be motivated to join the company they're applying to! (Anything more is definitely unfair for the candidate and doesn't scale well when reviewing code) This notion that 2 hours is a lot of time, well plenty of engineers would rather have that than waste a few months memorizing algorithms they'll rarely use. It's pretty common for algorithm tests to be an hour long anyway. So many software engineers have it backwards. Companies don't work for you, you're not even in the door yet. Unless you're a vp or principal engineer with a stellar bg, your tasks are replicable and most employers aren't going to be drooling over to get you on board as entitled / piss-poor attitude is going to cause more friction than it's worth.
- _jal 9y ago
  Eh. There is this thing called a market. Sometimes producers have the whip-hand, sometimes it is the consumers. We have markets in labor, and anyone who (for instance) weathered the 2000 dot.com bust knows, employers in tech don't hesitate to use it when the wheel turns. I refused a homework project for one firm[1]. It was a highly specific problem that only made sense for one specific version of an app server, and was really a lot of work with some tricky edge cases. Call me entitled, but after I made sure I understood what he was asking, told the interviewer where he could put his homework. I think it is important to keep a sense of the power dynamic. It is really easy to start moralizing to the powerless (here, employees) when they do find themselves with bit of leverage for a change. Not only is it a bad look - punching down is for insecure assholes - systems break down without feedback and (sometimes) pushback. [1] Well known, I'm not naming names because it probably was a fluke.
- crdoconnor 9y ago
  >Someone sounds pretty entitled. Maybe the guy who wants me to volunteer 2 hours of my time before deigning to have a conversation with me? >You know how burdensome it'd be to verify that your repos were fully yours I've never interviewed anybody who lied about the provenance of their repos. I'm pretty sure if I did, it would come out in a 5 minute conversation during the interview. If one or two gifted liars slipped through the hiring funnel into the interview stage before being found out I wouldn't view it as a tragedy. >This notion that 2 hours is a lot of time, well plenty of engineers would rather have that than waste a few months memorizing algorithms they'll rarely use. 2 hours is fine for an interview, but it's way too long to spend on a speculative application for one company.
brango 9y ago
> These days I just point the company to my github and am explicit that if that isn't enough to grant me a face to face I probably don't want to work there. I'd be happy with that if the projects looked they were yours. I can count on one hand the number of candidates who have had GH profiles, and even fewer with anything worth looking at. All I really want to see is a few examples of coding style and basic thinking. To me, being an engaged participant in the open source community is a massively positive signal, even if it's just reporting issues and the very occasional PR.
hinkley 9y ago
Last interview cycle I got 10 hours of homework total from three of my prospects. It’s not that it’s 2 hours, or four. It’s that you’ve given two hours to twenty people and so have five other companies.

gilleain 9y ago

We do the same. It's amazing to me how many people with superficially impressive CVs do one or more of: * Cheat * Fail to follow simple instructions * Write no tests for there code (even the given examples!) * Just horribly fail to implement an algorithm All in all, it's just a filter to be used before proper face-to-face interviews.

ryandrake 9y ago
> Write no tests for there code (even the given examples!) Just curious, do the instructions ask for tests? If one of these "programming quizzes" asked me to implement algorithm XYZ, I would follow it to the letter and implement only the algorithm.
- gilleain 9y ago
  we don't ask them to actually provide their tests, but implementing a non-trivial algorithm without tests is optimistic at best. we give them a couple of examples (input, output) pairs - surely you would at least run your implementation past these, right?
crankylinuxuser 9y ago
> Write no tests for their[sp] code (even the given examples!) Well, I've been on the fence on this one. With imperative languages, testing is pretty much a requirement because of side effects and scope-creep (nahh, throw it into global). Tests can be a good sanity check for simple checks like "I fixed a bug where X is supposed to give 22. Lets verify that"... But the problem is the tests are then code that can update and rot as main code changes occur. I've preferred a more functional method. I don't want to test - I want to prove a function handles its inputs and provides the correct outputs. Unless there's a good reason for state , I prefer keeping functions clean. And even then, with state (say, a tally function for bandwidth), I prefer to have the variable updated with its own function. Keeps clean/nonclean separate. Now.. one thing that's absolutely not acceptable is not commenting code. "Magic sequence in perl doing 6 things unintuitively" is not code comments. :(
- 9y ago