9 ms·

With this approach you'll miss good senior people; I have dependants and very little free time outside work. Last time I was looking for a job I skipped everyon

by ldite 8y ago

With this approach you'll miss good senior people; I have dependants and very little free time outside work. Last time I was looking for a job I skipped everyone who wanted me to do prep/homework. If the other interviews hadn't worked out I'd have gone back to them, but I didn't need to.

g105b 8y ago
Senior people will be able to do the two hour coding homework in way less than two hours. If someone can't manage this as part of an interview process, it might be a sign of their time management abilities.
- lifeisstillgood 8y ago
  Senior does not mean you type faster. It means you don't do unnecessary work, you avoid pitfalls and traps you have seen before, you don't over-engineer but you keep it as simple as possible. It also means that you push back against non-constructive requests from business and management and focus your time and effort on what matters. I also avoid anyone who wants me to do a coding exercise for a few hours over the weekend. If you want pay me for that time, and make it not a dig and fill hole exercise - find a OSS project that needs some contributions. Decide that you and your team will do thsoe via your ongoing interview process that hires people before the need arises, so you can all take your time selecting and onboarding people. Value your own time, or no one will
  - PurpleBoxDragon 8y ago
    >you don't over-engineer but you keep it as simple as possible It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).
  - scarejunba 8y ago
    Contributions to a new OSS project that show significant programming ability are very time-intensive. Do you know anyone who has successfully implemented this scheme? I could set up one of our OSS projects with first-contribution issues and help walk someone through but I suspect most people would rather not spend the time. If it takes 4 hours with back-and-forth in the PR (simply because I may be asleep when you commit and you when I comment) that's a big request of any person.
  - lifeisstillgood 8y ago
    A slightly extended thought The main antagonism here is that the hiring company wants to minimise its effort in getting great devs, and the devs want to minimise their effort in getting great jobs. The first point to note is that constant marketing is the first, best solution to this. I would definitely put more effort into joining a well-marketed company (StackOverflow?) than J.Random Inc. So both me and J.Random Inc had better put some effort into standing out from the crowd. OSS is one seemingly good way to do this - and having a reasonable Github account is something I would say should get you through most interview filters (ie if you are looking for a Python dev, and they have commits to say a flask extension or bits of salt-stack, then you can blip over the Fizzbuzz and whiteboards.) But marketing is simply a way to get past other people's filters. "Networking" is good, whatever that might mean, and being a good citizen works. but these are as always, long term, constant application efforts. And of course, costly. Secondly get over the "we only hire the best of the best of the best". If that's true then like the SEALs you clearly have a six month training programme that takes the best and shapes them into effective teams, fully paid while they learn - yes? And the training staff for this programme are pulled off current fee-paying projects to keep up the standards yes? Otherwise your best-of-the-best is so much auto-trumpet blowing. So please leave that at home. Focus on process not heroes. The interview by takehome project is a big problem. Yes it clearly weeds out candidates - mostly by making the ones with options elsewhere go elsewhere. (Even Google, with its firehose of applicants, seemed to realise this was a dumb idea and instead used the MIT graduate program as a filter instead). My main issue with interviews-by-homework is it is usually a hole-dig-and-fill session as the problem has been done by dozens of people before (often you can find their solutions on github). My time is then valued at less than zero. As a filter before we get to interview, it really is just an artifical hurdle. All you are saying is that "we have soooo much choice we can make you dance before talking to you" - if it works for you great. Your marketing is working (see above) IMO a better approach is to find different existing properties that you can filter to get applicants to the interview. Sometimes these are "Alpha Male" filters like 1st class honours at MIT. Other people on HN stand by different filters - I seem to remember someone saying one of their best hires had taught themselves coding whilst getting off drugs in a Glasgow slum. How you filter for that is harder than the MIT problem but I bet its a less tapped seam than MIT. Overall, a good interview process is probably focusing on the wrong end of the problem. If you have a new open position and then you start looking its too late. Be a good OSS citizen, be involved in the community of developers (OSS and elsewhere), find ways to reach out to unusual developers, or people not marketing themselves, and keep the process going constantly, with suitable investment. The general Big Co idea of "you cannot put out job ads before you have a signed off budget and position" tends to make this a problem. A solution would be to take the expected Agency percentages for each new hire (between 5-20%) and put it into a centralised "developer evangelist" team that just gets people through the door. This way when you need to open a new position, you will have four people in mind you already want to hire, and you can just go to Starbucks for an interview.
- kurtisc 8y ago
  They can, but why would they? They're probably busy, possibly with family. These aren't graduates desperate for a job, if they're the ideal employee you're looking for they'll have a comfortable fallback in continuing what they're doing and plenty of other companies that don't want them to do homework. What if 9 great companies give just 2 hours of homework and 1 gives none?
  - nicoburns 8y ago
    If you believe that coding challenges lead to a more accurate assessment of the candidates, then it would make sense.
- tomca32 8y ago
  My experience is quite opposite. I used to be much faster 5+ years ago. I would just jump to a conclusion, execute, and see what happens. I rarely start anything these days without thinking about the problem thoroughly. It results in longer development times, but better designed, and more robust software, or so I hope.
  - MattHeard 8y ago
    This is the difference between building a solution that works today and building a solution that works tomorrow. A good interviewer would prefer the latter, but would recognise that it takes longer.
chrisseaton 8y ago
> With this approach you'll miss good senior people Aren't you already spending many hours researching a job as the part of the process? Aren't you already taking a full day off work for the interviews? Why is that time all fine to spend, but not fine to spend a couple of hours on doing an assignment?
- C1sc0cat 8y ago
  That's only at a later stage when you get an interview - with a company that looks good. Coding tests are just an early stage filter for experienced people - so those companies get dropped early on.
  - mcv 8y ago
    I have the exact opposite opinion: a coding test is for a candidate you already want to hire and introduce to your development team, to have a look at their coding style. You don't want to get your developers together for any random loser who'd never want in your team anyway. So the coding is a late stage filter. At least for me it's always been.
    - C1sc0cat 8y ago
      But if experienced candidates go "meh" life's to short you might have missed a better candidate. And Martin any professional should adapt to the systems in place - and I wouldn't use terms like "random luser" might have some blowback.
      - mcv 8y ago
        If life's too short to continue with the final stages of an interview process, I don't know what to say. The whole idea, if you do it right, at least, is that you only give this test to developers that you already know you want. That means that for those developers, this is not one of dozens of tests they need to do, it's the one test; or one of a few, if they're that lucky. And if they're not interested in putting any time or effort into a new job, it seems to me they're probably not that interested in that new job in the first place. But it seems weird to me that so many people here consider a whole day of interviews to be totally acceptable, while some actual coding is not. Compared to some of the interview horror stories I often read here, this seems vastly preferable. I actually get to show what I can do in a realistic setting, and I get to explain why I do what I do. I get to meet the other developers and talk to them. And with the best programming tests, I actually get to learn something new. For the best one, I had to learn React (which I had no experience in), build a game board on which you can put obstacles, and write an algorithm to find the shortest part through the resulting maze. (I ended up rejecting that job because it was too far away and not enough pay, but I'm still really happy I did that coding challenge.)
rglullis 8y ago
Wait, what is the difference between taking the time for an interview (no matter if via phone or in-person) and one for a gate-filter task?
- jclardy 8y ago
  This is what I am wondering. The process at my company is a personal interview, coding challenge, then technical interview. So essentially about 4 hours of time. What makes this different from a company that wants 4 interviews from different managers, which likely takes up more time plus all of it being fixed time slots, versus having one hour of work that you can work on at your own pace?
- ldite 8y ago
  An interview is a two-way process. I typically find out a lot about the company and the people I'll be working with. Even a 30 minutes phone call is as much for me to be able to filter them out.
  - swish_bob 8y ago
    I get where you're coming from, and am in a similar position. On the other hand, I've used a coding test to drop a company before (completed the test and refused to submit it, told them the test gave me enough information to know I didn't want to work there). It gives you a hint as to what they think is important technically.
- mchannon 8y ago
  In theory there shouldn’t be any, assuming it’s limited to an hour, both in description and in reality. In practice there’s a pervasive phenomenon called asymmetry of effort. The hiring manager may crib a task set either from a perfunctory google search or their own body part. The sum total of time spent on their part is often five minutes, including coming up with the problem and their review of your code. This follows no industry standard, and I can count multiple experiences where they were too inept to “grade” the homework assignment, thinking it didn’t work when it did, or that the problem set was impossible. The reason senior engineers in particular turn down homeworks is because they’ve been burned by them before, and the average hiring engineer tends to know less than they do (but as the hiring manager, can’t assess it, mistaking competence for arrogance or ineptitude). When a company is not willing to invest the same amount of time to interview as they ask of the candidate, it’s a strong signal of how serious they are as a quality employer. When job hunting as a senior, hearing about take homes (esp. early stage ones) is the young person’s dating equivalent of considering a relationship with someone divorced twice and a felony. You just get conditioned to pass up kissing frogs.
imaginenore 8y ago
If it takes an hour to code, it shouldn't be a problem.
kstenerud 8y ago
So, if this is a deal breaker, what is your ideal interview scenario?
ahoka 8y ago
Think of it as a small (hopefully) fun mini project in your own pace versus a scheduled phone/onsite screening. Of course it requires the task to be small and open enough.
PurpleBoxDragon 8y ago
If the project only takes an hour for a junior it shouldn't be a problem. I would be worried that their senior position problems might not be as quick to solve (which is similar to the real world), but then this interview technique might just be best for junior positions and they do something different for senior positions given the different in skill sets and what problems they are expected to solve.
- raygelogic 8y ago
  this comment misses the point and is why we don't give take-home work to senior developer candidates. they are in high demand and will not spend their free time on homework, when many other companies will gladly hire them without making them jump through hoops.
  - gortok 8y ago
    I only see two possibilities: 1. Require developers to code on demand during an interview (personally, I have a hard time with this; the pressure of an interview is not a normal working situation). 2. Allow someone to do it on their own time, under no time pressure. (I advocate paying them for their time at a fair market rate). Do you see another way of a senior developer demonstrating their abilities without hitting either of the two above?
    - ryandrake 8y ago
      Ask the candidate to thoroughly review code during the interview and offer insight. See if they can spot undefined behavior, if they can improve an already-good solution, and ask what their approach would be to refactor it. If they are truly senior programmers, their actual job will be reviewing more than they write anyway, and you’re not hiring them for their ability to crank out a quicksort implementation. For the junior folks, sure: have them burn through homework.
  - ghaff 8y ago
    Furthermore, just because you can bang out something in an hour or two doesn't mean that you will spend only an hour or two when you know you'll be competing against people who put a lot of effort into the task. In my case, I do a lot of writing these days and, if someone were to ask me to write a thousand word analysis on some topic I was familiar with, I certainly could knock that off in a few hours. But, assuming I agreed to do it at all as part of the interview process--I'd be far more inclined to just give them a bunch of links to my work--I'm going to put the effort in to come up with a tight, polished product.
Hansi 8y ago
Might be location specific but out of 300+ candidates for 15 positions mid to senior level over 8 years in London recruited using this technique I've only ever had one person turn it down. We ask for fairly simpler requirements and for people to limit themselves to 4-6 hours over the course of a week with a focus on comments and recording their thoughts in a readme to suggest how they'd scale things if it was a real project. We don't really bother with many technical questions outside of the project anymore. It really is the single most important thing to get a glimpse into a persons ability to deliver, let them code at their own time in a setting they are comfortable with and then do a peer review with them on location and discuss the implementation and potential enhancements. The rest after that is generally just team fit and culture alignment checks.
- ldite 8y ago
  I don't turn them down - bridge burning is for pyromaniacs - I just make non-committal noises and don't usually get back to them. I should clarify that I was thinking more of outfits that respond to my enquiry with "Hi $candidate, please do this generic exercise after which we'll deign to look at your CV". Bonus points awarded/deducted if the requested exercise is for something already available on my github profile. And 4-6 hours is typically my free time (not free computer time, total free time) for a week.

by ldite 8y ago

g105b 8y ago

Senior people will be able to do the two hour coding homework in way less than two hours. If someone can't manage this as part of an interview process, it might be a sign of their time management abilities.

lifeisstillgood 8y ago
Senior does not mean you type faster. It means you don't do unnecessary work, you avoid pitfalls and traps you have seen before, you don't over-engineer but you keep it as simple as possible. It also means that you push back against non-constructive requests from business and management and focus your time and effort on what matters. I also avoid anyone who wants me to do a coding exercise for a few hours over the weekend. If you want pay me for that time, and make it not a dig and fill hole exercise - find a OSS project that needs some contributions. Decide that you and your team will do thsoe via your ongoing interview process that hires people before the need arises, so you can all take your time selecting and onboarding people. Value your own time, or no one will
- PurpleBoxDragon 8y ago
  >you don't over-engineer but you keep it as simple as possible It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).
- scarejunba 8y ago
  Contributions to a new OSS project that show significant programming ability are very time-intensive. Do you know anyone who has successfully implemented this scheme? I could set up one of our OSS projects with first-contribution issues and help walk someone through but I suspect most people would rather not spend the time. If it takes 4 hours with back-and-forth in the PR (simply because I may be asleep when you commit and you when I comment) that's a big request of any person.
- lifeisstillgood 8y ago
  A slightly extended thought The main antagonism here is that the hiring company wants to minimise its effort in getting great devs, and the devs want to minimise their effort in getting great jobs. The first point to note is that constant marketing is the first, best solution to this. I would definitely put more effort into joining a well-marketed company (StackOverflow?) than J.Random Inc. So both me and J.Random Inc had better put some effort into standing out from the crowd. OSS is one seemingly good way to do this - and having a reasonable Github account is something I would say should get you through most interview filters (ie if you are looking for a Python dev, and they have commits to say a flask extension or bits of salt-stack, then you can blip over the Fizzbuzz and whiteboards.) But marketing is simply a way to get past other people's filters. "Networking" is good, whatever that might mean, and being a good citizen works. but these are as always, long term, constant application efforts. And of course, costly. Secondly get over the "we only hire the best of the best of the best". If that's true then like the SEALs you clearly have a six month training programme that takes the best and shapes them into effective teams, fully paid while they learn - yes? And the training staff for this programme are pulled off current fee-paying projects to keep up the standards yes? Otherwise your best-of-the-best is so much auto-trumpet blowing. So please leave that at home. Focus on process not heroes. The interview by takehome project is a big problem. Yes it clearly weeds out candidates - mostly by making the ones with options elsewhere go elsewhere. (Even Google, with its firehose of applicants, seemed to realise this was a dumb idea and instead used the MIT graduate program as a filter instead). My main issue with interviews-by-homework is it is usually a hole-dig-and-fill session as the problem has been done by dozens of people before (often you can find their solutions on github). My time is then valued at less than zero. As a filter before we get to interview, it really is just an artifical hurdle. All you are saying is that "we have soooo much choice we can make you dance before talking to you" - if it works for you great. Your marketing is working (see above) IMO a better approach is to find different existing properties that you can filter to get applicants to the interview. Sometimes these are "Alpha Male" filters like 1st class honours at MIT. Other people on HN stand by different filters - I seem to remember someone saying one of their best hires had taught themselves coding whilst getting off drugs in a Glasgow slum. How you filter for that is harder than the MIT problem but I bet its a less tapped seam than MIT. Overall, a good interview process is probably focusing on the wrong end of the problem. If you have a new open position and then you start looking its too late. Be a good OSS citizen, be involved in the community of developers (OSS and elsewhere), find ways to reach out to unusual developers, or people not marketing themselves, and keep the process going constantly, with suitable investment. The general Big Co idea of "you cannot put out job ads before you have a signed off budget and position" tends to make this a problem. A solution would be to take the expected Agency percentages for each new hire (between 5-20%) and put it into a centralised "developer evangelist" team that just gets people through the door. This way when you need to open a new position, you will have four people in mind you already want to hire, and you can just go to Starbucks for an interview.
kurtisc 8y ago
They can, but why would they? They're probably busy, possibly with family. These aren't graduates desperate for a job, if they're the ideal employee you're looking for they'll have a comfortable fallback in continuing what they're doing and plenty of other companies that don't want them to do homework. What if 9 great companies give just 2 hours of homework and 1 gives none?
- nicoburns 8y ago
  If you believe that coding challenges lead to a more accurate assessment of the candidates, then it would make sense.
tomca32 8y ago
My experience is quite opposite. I used to be much faster 5+ years ago. I would just jump to a conclusion, execute, and see what happens. I rarely start anything these days without thinking about the problem thoroughly. It results in longer development times, but better designed, and more robust software, or so I hope.
- MattHeard 8y ago
  This is the difference between building a solution that works today and building a solution that works tomorrow. A good interviewer would prefer the latter, but would recognise that it takes longer.

chrisseaton 8y ago

> With this approach you'll miss good senior people Aren't you already spending many hours researching a job as the part of the process? Aren't you already taking a full day off work for the interviews? Why is that time all fine to spend, but not fine to spend a couple of hours on doing an assignment?

C1sc0cat 8y ago
That's only at a later stage when you get an interview - with a company that looks good. Coding tests are just an early stage filter for experienced people - so those companies get dropped early on.
- mcv 8y ago
  I have the exact opposite opinion: a coding test is for a candidate you already want to hire and introduce to your development team, to have a look at their coding style. You don't want to get your developers together for any random loser who'd never want in your team anyway. So the coding is a late stage filter. At least for me it's always been.
  - C1sc0cat 8y ago
    But if experienced candidates go "meh" life's to short you might have missed a better candidate. And Martin any professional should adapt to the systems in place - and I wouldn't use terms like "random luser" might have some blowback.
    - mcv 8y ago
      If life's too short to continue with the final stages of an interview process, I don't know what to say. The whole idea, if you do it right, at least, is that you only give this test to developers that you already know you want. That means that for those developers, this is not one of dozens of tests they need to do, it's the one test; or one of a few, if they're that lucky. And if they're not interested in putting any time or effort into a new job, it seems to me they're probably not that interested in that new job in the first place. But it seems weird to me that so many people here consider a whole day of interviews to be totally acceptable, while some actual coding is not. Compared to some of the interview horror stories I often read here, this seems vastly preferable. I actually get to show what I can do in a realistic setting, and I get to explain why I do what I do. I get to meet the other developers and talk to them. And with the best programming tests, I actually get to learn something new. For the best one, I had to learn React (which I had no experience in), build a game board on which you can put obstacles, and write an algorithm to find the shortest part through the resulting maze. (I ended up rejecting that job because it was too far away and not enough pay, but I'm still really happy I did that coding challenge.)

rglullis 8y ago

Wait, what is the difference between taking the time for an interview (no matter if via phone or in-person) and one for a gate-filter task?

jclardy 8y ago
This is what I am wondering. The process at my company is a personal interview, coding challenge, then technical interview. So essentially about 4 hours of time. What makes this different from a company that wants 4 interviews from different managers, which likely takes up more time plus all of it being fixed time slots, versus having one hour of work that you can work on at your own pace?
ldite 8y ago
An interview is a two-way process. I typically find out a lot about the company and the people I'll be working with. Even a 30 minutes phone call is as much for me to be able to filter them out.
- swish_bob 8y ago
  I get where you're coming from, and am in a similar position. On the other hand, I've used a coding test to drop a company before (completed the test and refused to submit it, told them the test gave me enough information to know I didn't want to work there). It gives you a hint as to what they think is important technically.
mchannon 8y ago
In theory there shouldn’t be any, assuming it’s limited to an hour, both in description and in reality. In practice there’s a pervasive phenomenon called asymmetry of effort. The hiring manager may crib a task set either from a perfunctory google search or their own body part. The sum total of time spent on their part is often five minutes, including coming up with the problem and their review of your code. This follows no industry standard, and I can count multiple experiences where they were too inept to “grade” the homework assignment, thinking it didn’t work when it did, or that the problem set was impossible. The reason senior engineers in particular turn down homeworks is because they’ve been burned by them before, and the average hiring engineer tends to know less than they do (but as the hiring manager, can’t assess it, mistaking competence for arrogance or ineptitude). When a company is not willing to invest the same amount of time to interview as they ask of the candidate, it’s a strong signal of how serious they are as a quality employer. When job hunting as a senior, hearing about take homes (esp. early stage ones) is the young person’s dating equivalent of considering a relationship with someone divorced twice and a felony. You just get conditioned to pass up kissing frogs.

imaginenore 8y ago

If it takes an hour to code, it shouldn't be a problem.

kstenerud 8y ago

So, if this is a deal breaker, what is your ideal interview scenario?

ahoka 8y ago

Think of it as a small (hopefully) fun mini project in your own pace versus a scheduled phone/onsite screening. Of course it requires the task to be small and open enough.

PurpleBoxDragon 8y ago

If the project only takes an hour for a junior it shouldn't be a problem. I would be worried that their senior position problems might not be as quick to solve (which is similar to the real world), but then this interview technique might just be best for junior positions and they do something different for senior positions given the different in skill sets and what problems they are expected to solve.

raygelogic 8y ago
this comment misses the point and is why we don't give take-home work to senior developer candidates. they are in high demand and will not spend their free time on homework, when many other companies will gladly hire them without making them jump through hoops.
- gortok 8y ago
  I only see two possibilities: 1. Require developers to code on demand during an interview (personally, I have a hard time with this; the pressure of an interview is not a normal working situation). 2. Allow someone to do it on their own time, under no time pressure. (I advocate paying them for their time at a fair market rate). Do you see another way of a senior developer demonstrating their abilities without hitting either of the two above?
  - ryandrake 8y ago
    Ask the candidate to thoroughly review code during the interview and offer insight. See if they can spot undefined behavior, if they can improve an already-good solution, and ask what their approach would be to refactor it. If they are truly senior programmers, their actual job will be reviewing more than they write anyway, and you’re not hiring them for their ability to crank out a quicksort implementation. For the junior folks, sure: have them burn through homework.
- ghaff 8y ago
  Furthermore, just because you can bang out something in an hour or two doesn't mean that you will spend only an hour or two when you know you'll be competing against people who put a lot of effort into the task. In my case, I do a lot of writing these days and, if someone were to ask me to write a thousand word analysis on some topic I was familiar with, I certainly could knock that off in a few hours. But, assuming I agreed to do it at all as part of the interview process--I'd be far more inclined to just give them a bunch of links to my work--I'm going to put the effort in to come up with a tight, polished product.

Hansi 8y ago

Might be location specific but out of 300+ candidates for 15 positions mid to senior level over 8 years in London recruited using this technique I've only ever had one person turn it down. We ask for fairly simpler requirements and for people to limit themselves to 4-6 hours over the course of a week with a focus on comments and recording their thoughts in a readme to suggest how they'd scale things if it was a real project. We don't really bother with many technical questions outside of the project anymore. It really is the single most important thing to get a glimpse into a persons ability to deliver, let them code at their own time in a setting they are comfortable with and then do a peer review with them on location and discuss the implementation and potential enhancements. The rest after that is generally just team fit and culture alignment checks.

ldite 8y ago
I don't turn them down - bridge burning is for pyromaniacs - I just make non-committal noises and don't usually get back to them. I should clarify that I was thinking more of outfits that respond to my enquiry with "Hi $candidate, please do this generic exercise after which we'll deign to look at your CV". Bonus points awarded/deducted if the requested exercise is for something already available on my github profile. And 4-6 hours is typically my free time (not free computer time, total free time) for a week.