[kevinoconnor7]

I remember interviewing with DO back in late 2014 and it was nuts! The entire interview process took ~3 months and it was clear that they were defining the process as they went. The entire process was basically:

  1. initial call with recruiter
  2. homework project
  3. call with engineer to discuss said homework project
  4. two phone screens with engineers
  5. onsite interview with 6 engineers

Finally I had was at the final step which was a call with Ben who was really interesting to talking to as we shared the sysadmin background.

They we going through some pretty crazy growth at the time so I forgave a lot of disorganization in the interview process. Unfortunately I didn't end up getting the role but I'm glad to have had that experience; it was definitely an interesting point in DigitalOcean's history.

[gist]

> 2. homework project > 3. call with engineer to discuss said homework project

How much time does it typically take (or should take) to complete a 'homework' project?

> 4. two phone screens with engineers > 5. onsite interview with 6 engineers

This seems very 'camel is a horse by committee' to me.

Reminds me a bit (know it's different) of dating where someone wants you to meet their family for approval. I immediately pass on those dates (and will add I am happily married to a woman who did not do that).

I wonder about situations where it takes so many inputs to make a decision to me that speaks a great deal about the decision making process being faulty.

Fwiw when I graduated college years ago I was rejected by a company (friend of the family no less) who said they couldn't hire me because 'yes you are smart but you don't know this business' (true I knew zero). So I started a company like theirs myself and now many years later they are gone and my company (which I sold) still survives. (Will add this was years before the internet and common practice for people who knew nothing to go into businesses they knew about).

Now yes I do understand programming is not the same but my point still stands why so many chefs in the kitchen? Does anyone ever go back and track the people who were rejected what happened to them?

[kevinoconnor7]

> How much time does it typically take (or should take) to complete a 'homework' project?

I was still in college at the time but I maybe spent 5-10 hours over the course of a week or so. I do remember it took a very long time for them to respond after I had sent it in though. I believe the project was to implement a basic web crawler in Go.

> Now yes I do understand programming is not the same but my point still stands why so many chefs in the kitchen?

After the homework problem I think that's where they were defining the process as they went. They seemed to be growing quite a bit at the time (IIRC when I was onsite they had just rented two more floors of office space) and I had bounced between a few contacts that were brand new to the company. The real struggle is that I never knew how many more steps were to come, and I'm not sure they knew either.

Though after the onsite they e-mailed me almost immediately to setup the call with Ben so I think everything had gone well up to that point. I don't think the call with Ben went poorly so my best guess is that they went with someone that had experience rather than a new grad.

FWIW I'm not actually bitter about this. I just found it to be an interesting snapshot of a particularly chaotic point in the company's history.

[mixmastamyk]

> Does anyone ever go back and track the people who were rejected what happened to them?

Almost never, in my experience. Several times I came second in the running and never heard from them again. Contacting them myself didn't work either. Typical shop would rather look thru another hundred randos than revisit one decent candidate.

[AYBABTME]

Not long, perhaps 2h for the core and then some cleanup over a few hours as I cogit about it? This was my submission back in 2014 https://github.com/aybabtme/crawler/commits/master

[Ansil849]

Not to hijack this sub-thread, but just a general question: how does one deal with unethical 'homework projects'? I've had a case during an application where I was given a 'homework project' that seemed to me very much not like a theoretical scenario, but more like the company wanting me to do free work for an actual real-world issue they had. Have people had situations where you suspected the same? How do you deal with it?

[jeffparsons]

My employer deals with this by compensating candidates for their time. Y'know... with money.

We also don't give them our actual problems as homework tasks. We'll occasionally talk about our real problems with candidates in interviews, but we're very clear about it when we do.

It's not a perfect system. Some candidates will choose to spend longer on the task so that in the follow-up interview they'll have the opportunity to talk about stuff that really shows off their strengths, so their effective hourly compensation for doing it would be quite low. The task is explicitly flexible like this, and we've also hired people who spent _half_ the par time on it (e.g. life circumstances making spare hours hard to come by) and didn't implement much at all, but then were able to confidently answer our questions about the bits they didn't actually implement.

Even if we were to only hire 1 out of every 15 people who get far enough through the pipeline to do the homework task (I don't recall the actual numbers) it costs us _nothing_ to compensate people for their time compared to, e.g., what it would cost us to make a bad hire. So it seems like an obvious thing to do even if only to stop candidates from having to wonder "am I getting screwed here?"

[kasey_junk]

Nearly every worker in the US is covered by an employment agreement that says they have to get pre-approval for moonlighting. It may or may not be legal in their jurisdiction but by paying people to do your interview process you potentially open them up to bad liabilities.

That said it is completely unethical to make people do real work as part of an interview process. We collectively should name and shame any firm that does that.

[nocman]

"Nearly every worker in the US is covered by an employment agreement that says they have to get pre-approval for moonlighting."

This is not true.

I've can think of one employer my entire career that had conditions regarding work outside of my normal work hours.

Granted, if you worked for your competetors and they found out about it you could be fired due to trade secrets or conflicts of interest. I only remember one employer I had where I signed something with binding agreements related to other work (and, as it happens, that was perhaps the worst employer I ever had).

I know some employers in some regions do this, but it is a far cry from affecting "nearly every worker in the US". In fact, I am not aware of any of my friends in tech positions currently being under such an agreement (that is, an agreement requiring pre-approval for outside work). In fact I believe it is illegal under many circumstances in some states for an employer to require it (but don't rely on me for that, conditions/laws change, and I have had no reason to look into it recently). I do remember discussions about it in the not too distant past, however.

[jldugger]

It was definitely part of the agreement when I worked in Univerisity IT, and part of the agreement when I accepted an offer from a FAANG company.

The language you're looking for in the contract is 'preponderance of time'.

[piva00]

I don't know about the US but anecdotally it's been definitely the case for most of my work contracts in Brazil and Sweden for the past 17 years, I believe that only 2-3 startups I worked for didn't have a clause about moonlighting requiring pre-approval from management.

[pacman2]

I did do analytical "sample" work for a company that took me two weeks. They were thankful for the work but did not hire me. I published it on my website and they were not very amused.

Agilent is not great either. They interviewed me for 6 month and implemented some of my ideas. (In fact, I got the job, out of 500 applicants, but then they axed the job and hired nobody)

[teeray]

One downside is that to do this properly, you probably should be sending out 1099s for all of those candidates. Depending on the number of open reqs out there, your payroll department may be less than thrilled with this idea. I’ve seen some teams that have tried to sidestep this by paying in gift cards, but that sure does seem to be playing with fire.

[SkyPuncher]

You are not required to file a 1099 if the payment is less than $600. Even then, I can't imagine it's that hard to send out an additional 1099 if needed.

[0] https://www.irs.gov/businesses/small-businesses-self-employe...

[dotBen]

Doesn't this discriminates against people who are on visas who can't accept remuneration from anyone other than their current employers..? They then either have to do the same project for free or decline to continue the interview process.

[simlevesque]

Paying someone for their work isn't discrimination. It never is.

The visa process may be flawed, but putting the blame on the employer is... weird.

[johannes1234321]

Not only visa, but also while employed one often can't simply be paid by a "competitor" for similar work, that would break the loyality to the current employer which is mandated by contract law and general low.

[smabie]

or they can just take the money anyways and no one will know. besides, you can accept a gift in btc

[codysan]

This is always, always the answer. It's not only the decent thing to do, it ensures you'll get an accurate representation of the quality of the prospective employee's work.

[stjohnswarts]

This seems reasonable. I've never been offered anything like that. It would be minimum $1000 a day.

[VintageLight]

Some people don't like whiteboarding or timed pair programming because it's not close to a real-work environment.

Some people don't like take-homes that replicate scenarios/projects because they think it's too close to real work and want to be paid instead!

There's no pleasing everyone with interviewing processes.

[SMAAART]

It's pretty simple: the interviewing process goes both ways. The company interviews the candidate, the candidate interviews the company.

If you feel that a request is unethical and it's not what you want in a company, well... you - as a candidate - can terminate the interviewing process.

[dotBen]

Simple - you give candidates assignments you've designed solely for interviewing. Ones that you clearly state up front are not real, not based around current project deliverables and commit that the code will ever be used in production.

Then it's no different to the rest of the candidate's time spent interviewing - it's cost of doing business that no one expects to be remunerated for.

The other benefit is that you then keep a benchmark of deliverables by having each candidate complete the same task (you have to change tasks over time as the details of the project get leaked/discussed).

[kgc]

When I give homework projects, they are extracted from a previous part of the interview: What is a personal project that you’ve wanted to do but haven’t had time to do? Then I just ask them to do that. Win / win.

[temp667]

We give new hires a homework project that is directly work related. We don't consider it unethical. It's really a fantastic way to sort out who can deliver. We used to have it be part of the onsite interview - they could sit for a few hours and do it.

I like these because they are not games. If you want something done, you'd ask an employee to do it. So just ask someone to do something you need done.

In our case at least by the time it was something that was part of an interview, it had already been implemented on the business side. Our projects were usually 2 hours tops?

The idea that this is unethical is wild.

We also do paid internships and have folks actually work on stuff that way -> do a good job, pretty good line up for a full time position.

[jimhi]

You are misunderstanding. They are saying it is unethical to ask an interviewee to code for free and use that in production. In your case you are not doing that, although if I interviewed with you and saw the same feature added after I submitted the code I would definitely assume you did something unethical.

[temp667]

But is that what is happening? They said it was a work related project. That's exactly what we do.

Why would a place like google even use an interviewees code without careful copyright assignment and work for hire protections (ie, you need to pay someone in USA generally to own their code).

I've found some potential hires are randomly paranoid - and if they start giving you lots of hypothetical disaster / ripoff scenarios early, not worth the hire?

[jimhi]

Sometimes companies do illegal things that save them money. I would assume Google wouldn't do that. Not every company is Google.

A 6-person company in New York did that to me. I reviewed the interview project I did for them and their latest product update. I had to ask them a week after the interview if they used my code in production and if so - this is how many hours I worked on it and a fair rate. The CEO emailed me threatening legal action and then called me 10 minutes later apologizing and venmo'd me the amount I stated it was worth.

If your interview process works for you that is great.

But I could totally see why potential hires are paranoid if you are giving them a situation to be paranoid about. I hope you are being super clear with your process and giving assurance you aren't using their code. If it was me, I would show them the code our team wrote at the same time they submit their project and use that as part of the follow up interview.

[jdavis703]

This happened to me in am interview. It was my first software engineering job, so I was a junior. Wound up solving a problem one of the senior engineers had been struggling with for days. It’s probably what got me the job. Assuming the company is actually hiring for the role I think it’s perfectly fine to do this. It identifies people who can fill in gaps.

[pc86]

We don't use homework projects at my current job (I don't care for them personally and thankfully have a bit of influence in the hiring process), but I've worked places that did. We always took real-world problems we had but had already solved. This has a couple benefits: a) we have full context around edge cases, bugs, historical stuff, etc. that the candidate doesn't; b) we can see pretty quickly when a candidate does something innovative we didn't think of and it's always lead to extremely good discussions in the interview; c) it's very similar to the work they'd be doing day-to-day, so if they have a lackluster resume and/or don't interview well, but shine on this, their odds of an offer skyrocket; d) the company gains nothing from the work so that settles most (but not all) of the ethical objections to it.

[stjohnswarts]

I just don't do them and move on to the next company. I've never had an issue landing my next gig. I'll do all day multi round interviews and white board questions. I'm not doing your work or taking a college exam again. Good luck and godspeed is all I can tell them.

[srcreigh]

Ubiq (YC company) interviewed me with an 8 hour assignment that had ridiculously challenging requirements. It was very fun because there was no way any normal human could do it in 8 hours... but how far could I get? And they paid me for 8 hours working on it.

I felt this was good. I got paid and it was a fun challenge. It also obviously wasn't "actual work," but even if it was, I was getting paid, so why not?

I don't think it would have been out of the question to say I was too busy to dedicate 8 hours either, but in my case I had the time.

Overall it was an excellent experience.

[usr1106]

I had to solve a real world problem for my current employer in my assignment. However, when they usually say it takes 20% to make a nice demo and 80% to make a the demo production-ready, I'd say the distribution for my assignment was even more uneven. It's just a PoC, a toy, nothing that can really be used. I did not know the tools used, the coding style or anything when I coded the assignment.

I see nothing unethical in it.

3 years later the feature has still not made it to production. I hate that every time it would have made my working day easier :)

[Beefin]

I will only ever commit to a homework assignment if the employers' commitment level is on par. For example, if they want me to do a homework assignment before meeting the hiring manager, no way. In other words, the assignment CANNOT be the first gate otherwise companies will just spray and pray then find the most desperate candidates.

[umvi]

If it were me I would be like: "here is proof I completed it and that it works, source code contingent on my being hired ;)"

[xedeon]

I like the way you think!

[tedk-42]

It's actually a good idea to pick a JIRA/project ticket from your backlog and see how the new engineer tries to solve the problem.

It's good because it will determine if they're a good fit for the team and gauge how much they have to offer.

[mamurphy]

I was bored so I clicked on the key proof in your profile and it says it's been revoked.

[kevinoconnor7]

oops! I rotated my private key a couple years back and never updated that. Fixed!

[cobaltoxide]

That interview process sounds completely standard.

[kevinoconnor7]

Overall I don't think the total amount was excessive, or maybe just slightly. My experience has always been been technical phone screen or homework problem before onsite, but not both.

The real issue was how chaotic the process was. I had started out talking to an engineer that had picked up my application, but was handed off to recruiter only after the homework portion was done (said recruiter even mentioned that they had just been hired). The two technical phone screens also were two discrete steps (i.e. the second was only scheduled after the success of the first).

That was really the issue: neither I nor them knew how many more steps there were. It wasn't helped by having long periods of radio silence between each step either. But it was painfully obvious that they were scrambling to figure out how to scale their processes, so much so that it still stands out to me 6+ years later.

[aerosmile]

As a sysadmin, you probably have a number of areas of responsibility. Imagine a time in your career when you had the least amount of sleep, and still tried your hardest to keep everything together. Then you meet someone who gives you the feedback that they enjoyed talking to you, but they noticed that one of those areas is not quite as buttoned up as it should be. Presumably you take that feedback to heart and fix it as quickly as the circumstances allow. 6+ years later, that person goes on HN and takes you through the dirt. Would that seem reasonable to you?

[kevinoconnor7]

Thanks for calling this out: you're right. I don't think I highlighted properly what I actually wanted to highlight.

I more wanted to emphasize my view as a bystander at a very hectic point of their growth, not actually complain about the experience. It was an interesting experience to me, not a negative one.

I have no hard feelings about it and I'm sure things got sorted out. I certainly have no negative views of any individual I dealt with.

[dilyevsky]

The feedback is completely reasonable. No chance you’re going to hire someone decent today if your interview process for IC roles takes 3 months!