> Candidates pair with members of the engineering team, and work together on problems/projects in the actual CircleCI codebase.
Are they compensated for this work?
Are they compensated for this work?
If I were betting on this I would wager that something like 95% of the time, the existing employee would be able to solve the project or problem much faster without the candidate's input at all, but the point is to try and approximate a more realistic work experience and environment.
I think that's a reasonable goal and I don't think CircleCI should be vilified for it.
Not at all.
> Do you believe that CircleCI has some nefarious plot to increase engineering team productivity by mining spare workcycles out of interview candidates?
Your tone suggests that you think this is impossible, but it happens all the time: https://news.ycombinator.com/item?id=16661338 That was on the front page three days ago.
The GP's concern is legitimate; job interviews should not be an excuse for unpaid labor.
That's fair. To be clear, I don't think it's impossible, and especially given what I've heard from friends who've worked in freelance web development there's a huge long tail of scummy opportunities out there.
I more meant to suggest that it was unlikely this was CircleCI's motivation.
Also an important distinction between these two situations is that in the example you point out, someone is being assigned a specific task to produce some new IP which the company can then simply steal, whereas in the CircleCI case I am assuming the "problem/projects" they have you pair on are something in the neighborhood of e.g. "let's go analyze some page load performance data together and see if we can fix some low hanging fruit" or "let's figure out how to set up an alert in our Slack channel for this signal we have in some logs".
Yes it's still true that a candidate could come up with some brilliant insight that saves CircleCI real money in this scenario, but it just seems unlikely and not something they could profitably build a development strategy around.
How should companies interview people in a manner that assesses their technical skills but doesn't "exploit" them? Personally I think the algorithm based interviews are great but also see value in these modified approaches of a short take-home assignment.
In this specific case, that is not what is happening. Rather than assessing candidates on some arbitrary algorithms question (which people are constantly complaining about), they are giving them a real problem the team is currently tackling. It's your time to shine and show how well you work as an engineer on real problems. I'm baffled that companies have finally heard the non-stop complaints about algorithms questions and are treated to new complaints about not being compensated for time spent interviewing. What an amazing time to be alive
"What an amazing time to be alive"
My assumption would be that if a candidate's code is good enough to get released, then the candidate is, by definition, good enough for the company.
I also assume that most of the time spent in this "interview" in a live codebase is the employee asking about how the candidate thinks and decides on things, not for the pair to actually produce working code.
I also assume that the code used within the codebase is non-business-critical stuff like an internal tool.
Anything else is "too much work" on the candidate.
A take-home? "I don't have time to work on unpaid stuff!"
A pairing session? "I don't have time to work on unpaid stuff!"
Software engineering trivia? "Why are they asking me to build a linked list when I'd just use stdlib in real life?"
Asking about stuff on the resume? "They've never worked on ${thing}; how could they judge me on it?"
1. Hiring a new employee into an existing team permanently affects the team's dynamic and morale. Bringing in a bad fit can have undesired cascade effects. Bad team members can cause other good team members to leave earlier than intended, for example. You can counteract this by having the entire team interview the candidate, but this doesn't scale for teams larger than, say, three candidates, doesn't work at all for distributed teams and takes their time away from work that needs to get done.
2. Hiring an employee is also a legal risk. Firing people in "protected" classes is touchy and can take a while, for example: https://www.entrepreneur.com/article/62846. You're also opening yourself up to unnecessary lawsuits that just add more of a headache for Legal to deal with...if you have legal. (Early-stage startups typically don't have legal teams.)
3. Hiring engineers is expensive beyond their base salaries. Firing bad engineers can be a huge waste of money.
If you're an early stage startup, you're better off hiring contractors for point work and taking time to find the best hires that you can. Later-stage or profitable companies can afford to not hire "false positives". At worst, a potentially-good candidate you're on the fence about can come back in six or twelve months and try again.