5 ms·

You have two steps round the wrong way: 1. Do the phone screen first. Frankly, in my experience, you can filter out a lot of people in the first minute; and 2

by cletus 15y ago

You have two steps round the wrong way: 1. Do the phone screen first. Frankly, in my experience, you can filter out a lot of people in the first minute; and 2. Then do the test. Speaking of the test, I had a quick look and it takes time. How much time? I'm not sure as I didn't look at the starting code, just the list of tasks. Maybe it only takes 30 minutes. Maybe it might take hours. I really don't know. Either way, these sorts of things are huge barriers to entry because, as someone looking for a job, I also have to decide on how much time to spend on you. The fact that this test is just to get to the phone screen lowers the amount of effort I'm willing to put in. Also, you don't need terribly complicated coding problems to weed out early stage candidates. Honestly, getting someone to code a relatively efficient (at worst O(n) space and time) factorial function will tell you ~95% of what you need to know from this test if you can witness them actually doing it. Seriously. So screenshare with them and get them to do it. No editor. Just a Google doc or similar. That all being said, I'm really shocked how woefully unqualified an awful lot of programmers are at... programming. The sort of acceptance numbers talked about here and at places like Google (disclaimer: I work for Google) are more testament to the number of clueless cowboys infect our industry than anything else. Also, bear in mind that an interview is a two-way street. The more effort you expect from the candidate the more they need to want to work for you before they even start interviewing. Google, Facebook, Twitter and the like have this kind of developer gravitas. Do you? I don't know. Lastly, the three month trial thing is, for me, a huge problem. After all this there's a 20% chance I might lose my job for no reason other than you may not like me? One reason Google is so selective is we take employment seriously. Leaks and criminal offences notwithstanding, it's actually pretty hard to get fired from Google and those decisions are not made lightly. That may have some negative side effects but overall I think it's a good thing that engineers aren't constantly worried about being fired.

latch 15y ago
I agree re the test. I'm sure it would have been different if I was interested in the job, but I didn't even finish reading what they wanted me to do before I said "screw this".
- arctangent 15y ago
  Hate to be another "me too". But I also looked at the test and it was pretty obvious that (a) it's going to take more than 5 minutes and (b) it's not really clear how I demonstrate my knowledge to the potential employer. Vague requirements like "add support for our new data format" mean nothing to me in this context. Am I supposed to add error checking? Should I automatically detect which format is used? I have no idea how much effort is expected, and so I'm not even going to try because some less talented person may have had more time to work on it than me. The great thing about FizzBuzz is that it's the kind of thing a decent programmer can knock out in a minute or two (so they're not wasting too much time when they speculatively apply) and yet it's just sufficiently difficult that people who can't program at all are easy to screen out.
  - citricsquid 15y ago
    the "new data format" is just them checking if you a) recognise data formats when not labeled or b) are capable of identifying data you don't know. The data format they link to is json; the "puzzle" is identifying it, adding support is trivial.
    - arctangent 15y ago
      I think you've missed my point. How much "support" am I supposed to add?
Homunculiheaded 15y ago
It is possible, I believe, to test first and then interview. I think the greatest example of this is ITA Software's puzzles [1] I find it almost impossible not to stop what I'm doing and try to solve a few, because they are both interesting and difficult (even the more mundane ones). In this case these tests before interview would actually attract me to ITA, if everyone there has solved those problems you'd know you'd be working with pretty smart programmers, and your work would probably be pretty interesting. The Deviant Art test however is something I would consider a dull day of work. If you want me to prove my worth by challenging me to an interesting combinatorial optimization problem, I'll bite. However if you want me to prove my worth by testing my ability to perform the kind of task that usually makes programmers think they should be looking for more challenging work, then good luck to you. 1. http://www.itasoftware.com/careers/work-at-ita/hiring-puzzles.html http://www.itasoftware.com/careers/work-at-ita/hiring-puzzle...
- kemayo 15y ago
  We do worry a bit about the "dull day of work" aspect to it. But what it's testing for is important, and attention to detail in a messy little webapp is likely a better predictor for success than the ability to throw out a flawless algorithm exercise.
  - Homunculiheaded 15y ago
    I can see your point, and obviously DA isn't actually solving combinatorial optimization problems while ITA is. The problem is that this problem will likely only attract devs actively looking for work. DA is a well known site, and I have no doubt that there are many good and happily employed devs who have peaked at the job description, but as you can see in the comments here this test is off-putting. If you're not in serious need of work, this doesn't seem to be worth your time (and in my experience good devs are rarely in serious need of work). I think the reason for the low P(we hire you) is that you may be accidentally skimming off the cream here. At the very least try getting people on the phone first so they can say "hey these DA guys are pretty cool and interested in me, it's worth jumping through a few hoops", or make the test seem interesting/fun/challenging
cperciva 15y ago
...a relatively efficient (at worst O(n) space and time) factorial function... If you can do that, you'll win a Nobel prize. (Yes, I know there isn't a Nobel prize in computing: You'd win a Nobel prize in physics, for showing how to store Θ(n log n) bits in O(n) space.) Heck, if you can compute n! in O(n (log n)^(2-x)) time for any x > 0 you'll probably win the Turing award. Such an algorithm would be really really big news.
- ramchip 15y ago
  I don't understand your comment. Take a simple definition of the factorial: http://codepad.org/GTBdCKin http://codepad.org/GTBdCKin The space usage for this function is obviously constant, and the number of multiplications will be linearly dependent on the number. If you mean to refer to the 'factorial function' as a mathematical object, and point out that bignum operations have different complexity... well that's true, but irrelevant to OP's post, and there are less snide ways of saying it.
  - deleted 15y ago
    [deleted]
    - cperciva 15y ago
      the # of bits required to represent the numeric argument That's usually what we mean, yes. When we talk about algorithms for computing factorials, exponentials, or other rapidly-growing functions, we change terminology. It's one of these "we all know what we mean so we don't need be clear about what we're saying" things. ;-)
  - cperciva 15y ago
    Yes, when I say "factorial function" I mean the factorial function, taking an integer input n and returning the integer output n!. If cletus meant "factorial as long as the result is a 32-bit integer", I don't know why he would accept an O(n) solution to that: I wouldn't hire anyone who didn't immediately produce the obvious O(1) algorithm using a 13-element lookup table. (If he meant "factorial modulo 2^32", a 34-element lookup table suffices.) As for being snide... yes, but I'm tired of the myth that Google is full of (and only hires) algorithms gurus. I have yet to see any indication that Google requires any more than a minimal undergraduate level of algorithmic competency.
kemayo 15y ago
There's a certain amount of selection bias here, given that I've obviously already gone through a similar sort of process to get hired there, but I don't think it's terrible to ask an applicant to do a small proof-of-competence task before you tie up a bunch of time in talking to them. For what it's worth, it's somewhere in the half hour range for that exercise, and I've certainly spent longer than that tweaking a resume + cover letter when applying for jobs in the past. Ultimately "because we don't like you" is the reason you'll lose any job. The main thing that makes us decide someone isn't working out is if they're not performing, though. I don't think I've seen anyone get dropped after the trial for any other reason.
- jwegan 15y ago
  I think the consensus on HN is that your company's hiring practices are not normal. While some percentage of good developers will put up with your practices; I think a much larger percentage pass on you before you ever hear from them. As you alluded to, everyone working at your company has self selected themselves to work there and must fall into the "some percentage" category. Of course all of you think this hiring strategy is a great idea, since all of you put up with it. However, if you really want to increase P(we hire you), it might be time to break out of the groupthink and try something new.
deleted 15y ago
[deleted]
LVB 15y ago
Lastly, the three month trial thing is, for me, a huge problem. Yup. Your hiring practice better be up to the task of bringing in the right people at the outset, because the top candidates aren't going to tolerate a trial period. Not in this market for their talents. I also think the trial approach is potentially harmful to the company. There's a reasonable chance that the most ambitious and positively disruptive people are going to clash with the existing team at the outset since they're not part of the groupthink. Sure, if a guy turns out to be a mistake you can and should fire them, but starting everyone on probation is no good.
lsc 15y ago
>One reason Google is so selective is we take employment seriously. Leaks and criminal offences notwithstanding, it's actually pretty hard to get fired from Google and those decisions are not made lightly. That may have some negative side effects but overall I think it's a good thing that engineers aren't constantly worried about being fired. There are employees who place a very high value on job stability. In the general case, these people are more 'loyal' in that they are less likely to jump for better pay or what have you a few years down the road. But depending on how you run your company, it may be rational to select for the sort of person who does not expect job stability. I'm in this second class, personally. Yeah, I'll jump if I get an offer that is 20% better, but on the other hand, I maintain 'how to fire me' documentation, and I expect that if I go through a long productivity slump, that you will fire me, and I won't hold it against you. I expect and try to give absolute honesty, but as far as I am concerned, loyalty is a lie. (I know that for other people, loyalty is important and not a lie. But if I claimed loyalty, I mean, beyond honesty, I would be lying, and if a company offers me loyalty, I am, ah, suspicious.) I'm not saying one approach is better than the other... Both approaches are valid, and they both get you different sorts of employees. In fact, the optimal solution may be to use a different approach for different types of employees; this is traditionally done by having full-time employees and contractors (now, the way most companies hire contractors is hugely inefficient; the body shop eats so much value that this is probably a bad idea. But if you could have some other way of setting the loyalty vs. no loyalty expectation, a company could benefit having both family and mercenaries. We are good at different things.)
- cletus 15y ago
  What you are describing is the difference between a standing army and mercenaries. Chris Dixon [1] describes it succintly: > Generally speaking, there are two approaches to relating to other people in the business world. The first approach is transactional and legalistic: work is primarily an exchange of labor for money, and agreements are made via contracts. Enforcement is provided by organizations, especially the legal system. The second approach relies on trust, verbal agreements, reputation and norms, and looks to the community to provide enforcement when necessary. Now I'll certainly agree many employers pay lip service to "loyalty" as a means of controlling costs and turnover without it being in the least bit reciprocal. So while this may not be your typical experience (it certainly isn't mine) I can tell you from experience that Google takes this pretty seriously. That all being said, you are basically a fair weather friend and, to be perfectly honest, you'll never see the rewards that only come from sticking through the hard times, which is actually your loss (IMHO). [1]: http://cdixon.org/2009/10/23/twelve-months-notice/ http://cdixon.org/2009/10/23/twelve-months-notice/

by cletus 15y ago

latch 15y ago

I agree re the test. I'm sure it would have been different if I was interested in the job, but I didn't even finish reading what they wanted me to do before I said "screw this".

arctangent 15y ago
Hate to be another "me too". But I also looked at the test and it was pretty obvious that (a) it's going to take more than 5 minutes and (b) it's not really clear how I demonstrate my knowledge to the potential employer. Vague requirements like "add support for our new data format" mean nothing to me in this context. Am I supposed to add error checking? Should I automatically detect which format is used? I have no idea how much effort is expected, and so I'm not even going to try because some less talented person may have had more time to work on it than me. The great thing about FizzBuzz is that it's the kind of thing a decent programmer can knock out in a minute or two (so they're not wasting too much time when they speculatively apply) and yet it's just sufficiently difficult that people who can't program at all are easy to screen out.
- citricsquid 15y ago
  the "new data format" is just them checking if you a) recognise data formats when not labeled or b) are capable of identifying data you don't know. The data format they link to is json; the "puzzle" is identifying it, adding support is trivial.
  - arctangent 15y ago
    I think you've missed my point. How much "support" am I supposed to add?

Homunculiheaded 15y ago

It is possible, I believe, to test first and then interview. I think the greatest example of this is ITA Software's puzzles [1] I find it almost impossible not to stop what I'm doing and try to solve a few, because they are both interesting and difficult (even the more mundane ones). In this case these tests before interview would actually attract me to ITA, if everyone there has solved those problems you'd know you'd be working with pretty smart programmers, and your work would probably be pretty interesting. The Deviant Art test however is something I would consider a dull day of work. If you want me to prove my worth by challenging me to an interesting combinatorial optimization problem, I'll bite. However if you want me to prove my worth by testing my ability to perform the kind of task that usually makes programmers think they should be looking for more challenging work, then good luck to you. 1. http://www.itasoftware.com/careers/work-at-ita/hiring-puzzles.html http://www.itasoftware.com/careers/work-at-ita/hiring-puzzle...

kemayo 15y ago
We do worry a bit about the "dull day of work" aspect to it. But what it's testing for is important, and attention to detail in a messy little webapp is likely a better predictor for success than the ability to throw out a flawless algorithm exercise.
- Homunculiheaded 15y ago
  I can see your point, and obviously DA isn't actually solving combinatorial optimization problems while ITA is. The problem is that this problem will likely only attract devs actively looking for work. DA is a well known site, and I have no doubt that there are many good and happily employed devs who have peaked at the job description, but as you can see in the comments here this test is off-putting. If you're not in serious need of work, this doesn't seem to be worth your time (and in my experience good devs are rarely in serious need of work). I think the reason for the low P(we hire you) is that you may be accidentally skimming off the cream here. At the very least try getting people on the phone first so they can say "hey these DA guys are pretty cool and interested in me, it's worth jumping through a few hoops", or make the test seem interesting/fun/challenging

cperciva 15y ago

...a relatively efficient (at worst O(n) space and time) factorial function... If you can do that, you'll win a Nobel prize. (Yes, I know there isn't a Nobel prize in computing: You'd win a Nobel prize in physics, for showing how to store Θ(n log n) bits in O(n) space.) Heck, if you can compute n! in O(n (log n)^(2-x)) time for any x > 0 you'll probably win the Turing award. Such an algorithm would be really really big news.

ramchip 15y ago
I don't understand your comment. Take a simple definition of the factorial: http://codepad.org/GTBdCKin http://codepad.org/GTBdCKin The space usage for this function is obviously constant, and the number of multiplications will be linearly dependent on the number. If you mean to refer to the 'factorial function' as a mathematical object, and point out that bignum operations have different complexity... well that's true, but irrelevant to OP's post, and there are less snide ways of saying it.
- deleted 15y ago
  [deleted]
  - cperciva 15y ago
    the # of bits required to represent the numeric argument That's usually what we mean, yes. When we talk about algorithms for computing factorials, exponentials, or other rapidly-growing functions, we change terminology. It's one of these "we all know what we mean so we don't need be clear about what we're saying" things. ;-)
- cperciva 15y ago
  Yes, when I say "factorial function" I mean the factorial function, taking an integer input n and returning the integer output n!. If cletus meant "factorial as long as the result is a 32-bit integer", I don't know why he would accept an O(n) solution to that: I wouldn't hire anyone who didn't immediately produce the obvious O(1) algorithm using a 13-element lookup table. (If he meant "factorial modulo 2^32", a 34-element lookup table suffices.) As for being snide... yes, but I'm tired of the myth that Google is full of (and only hires) algorithms gurus. I have yet to see any indication that Google requires any more than a minimal undergraduate level of algorithmic competency.

kemayo 15y ago

There's a certain amount of selection bias here, given that I've obviously already gone through a similar sort of process to get hired there, but I don't think it's terrible to ask an applicant to do a small proof-of-competence task before you tie up a bunch of time in talking to them. For what it's worth, it's somewhere in the half hour range for that exercise, and I've certainly spent longer than that tweaking a resume + cover letter when applying for jobs in the past. Ultimately "because we don't like you" is the reason you'll lose any job. The main thing that makes us decide someone isn't working out is if they're not performing, though. I don't think I've seen anyone get dropped after the trial for any other reason.

jwegan 15y ago
I think the consensus on HN is that your company's hiring practices are not normal. While some percentage of good developers will put up with your practices; I think a much larger percentage pass on you before you ever hear from them. As you alluded to, everyone working at your company has self selected themselves to work there and must fall into the "some percentage" category. Of course all of you think this hiring strategy is a great idea, since all of you put up with it. However, if you really want to increase P(we hire you), it might be time to break out of the groupthink and try something new.

deleted 15y ago

[deleted]

LVB 15y ago

Lastly, the three month trial thing is, for me, a huge problem. Yup. Your hiring practice better be up to the task of bringing in the right people at the outset, because the top candidates aren't going to tolerate a trial period. Not in this market for their talents. I also think the trial approach is potentially harmful to the company. There's a reasonable chance that the most ambitious and positively disruptive people are going to clash with the existing team at the outset since they're not part of the groupthink. Sure, if a guy turns out to be a mistake you can and should fire them, but starting everyone on probation is no good.

lsc 15y ago

>One reason Google is so selective is we take employment seriously. Leaks and criminal offences notwithstanding, it's actually pretty hard to get fired from Google and those decisions are not made lightly. That may have some negative side effects but overall I think it's a good thing that engineers aren't constantly worried about being fired. There are employees who place a very high value on job stability. In the general case, these people are more 'loyal' in that they are less likely to jump for better pay or what have you a few years down the road. But depending on how you run your company, it may be rational to select for the sort of person who does not expect job stability. I'm in this second class, personally. Yeah, I'll jump if I get an offer that is 20% better, but on the other hand, I maintain 'how to fire me' documentation, and I expect that if I go through a long productivity slump, that you will fire me, and I won't hold it against you. I expect and try to give absolute honesty, but as far as I am concerned, loyalty is a lie. (I know that for other people, loyalty is important and not a lie. But if I claimed loyalty, I mean, beyond honesty, I would be lying, and if a company offers me loyalty, I am, ah, suspicious.) I'm not saying one approach is better than the other... Both approaches are valid, and they both get you different sorts of employees. In fact, the optimal solution may be to use a different approach for different types of employees; this is traditionally done by having full-time employees and contractors (now, the way most companies hire contractors is hugely inefficient; the body shop eats so much value that this is probably a bad idea. But if you could have some other way of setting the loyalty vs. no loyalty expectation, a company could benefit having both family and mercenaries. We are good at different things.)

cletus 15y ago
What you are describing is the difference between a standing army and mercenaries. Chris Dixon [1] describes it succintly: > Generally speaking, there are two approaches to relating to other people in the business world. The first approach is transactional and legalistic: work is primarily an exchange of labor for money, and agreements are made via contracts. Enforcement is provided by organizations, especially the legal system. The second approach relies on trust, verbal agreements, reputation and norms, and looks to the community to provide enforcement when necessary. Now I'll certainly agree many employers pay lip service to "loyalty" as a means of controlling costs and turnover without it being in the least bit reciprocal. So while this may not be your typical experience (it certainly isn't mine) I can tell you from experience that Google takes this pretty seriously. That all being said, you are basically a fair weather friend and, to be perfectly honest, you'll never see the rewards that only come from sticking through the hard times, which is actually your loss (IMHO). [1]: http://cdixon.org/2009/10/23/twelve-months-notice/ http://cdixon.org/2009/10/23/twelve-months-notice/