Comment by whack | Hacker News Reader

Comment by whack | Hacker News Reader

Here's what they are doing, from the linked blog post:

> Our dev teams had taken to working with candidates to solve a bug or feature as part of the interview process. It was a collaborative effort with the candidate and the team working together to solve a real problem.

Sounds like a great idea.

Except it's so variable. What if you get lucky and you get a easy bug, whereas someone else gets something much harder. Let's standardize that by giving everyone the same task to work on.

And what if we want to hire people who aren't fluent in your project's programming language? That would be a big handicap for them. Let's deal with that by having minimally sized "projects" in all the languages, and allowing the candidate to choose their preferred language.

And we don't want the interviews to be biased against people who don't already have domain knowledge in a specific field. So let's make the task generic enough to be approachable by any good programmer.

Congrats, if you did all of the above, you've reinvented leetcode style interviews.

There's some cool stuff that MS has put into practice. I like the focus on reading/understanding existing code, instead of just writing code. I also like the relaxed pacing and "open book" approach.

But for the most part, I don't think this is really as revolutionary as people think it is.

Even just having the interviewer pair with the candidate on random leetcode problems would be pretty revolutionary.

Why do you think so? I know many companies that pair for interviews, Thoughtworks, and Pivotal Labs for example

I know those two, but they’re definitely outliers in many ways. I’ve never seen it done for a non-consulting company.

It's less about solving the issue and more about how you approach it.

> taken to working with candidates to solve a bug or feature as part of the interview process

This is unethical. How is this anything other than unpaid labor?

A little bit of unpaid labor is honestly fine. Especially since I can’t imagine this being easy to exploit in a way that really impacts a company’s bottom line.

It’s like getting a free sample of food at the store, before committing to a full purchase

Imagine being a carpenter applying for a job and being asked to make a small bedside table for free. So the employer can sample your skills before committing to a full purchase.

Absurd.

If you ever sat on the hiring side and had just one new hire not work out, you would understand your throw away statement is actually more absurd than asking for free work. Let's flip the scenario and go your way instead...

Imagine being a programmer applying for a job and not being asked to demonstrate your skills at interview. The interview goes well, and you're offered the job.

You give your 4 weeks notice on your existing job, and turn up to your new role. You sit down, it's day one, and you're presented with a small sprint of bugs to work through to get warmed up on the project you're assigned.

Your heart sinks.

You realise that you are totally out of your depth. The solution you're working on is hard, the documentation insanely complex, and you feel more and more despondent as the week goes on.

By the end of the week your colleagues and managers have started to pick up on your struggles. Despite their effort to help you can't make meaningful progress. To cut a long story short you're let go, and now you're unemployed.

-THE END-

As an employer and owner of a software company, it's my job to assess the skills of somebody as quickly and efficiently as possible. If getting them to "build a small bedside table for free" gets both me, my colleagues, and the candidate attending the interview comfortable that we're offering a job to somebody who can succeed at my company, then so be it.

I'm more often on the hiring side of the table than on the other. Probation periods exist specifically to address the issue of hiring false positives, and they work fine.

Your story is only possible if the interview process failed miserably. If your process sucks and results in a lot of false positives, that's your problem. Don't use it as justification for milking candidates for unpaid work towards actual deliverables.

One must not use probation as a get out of jail free card. We used to think the same way you do, we ultimately realised we were wrong.

Probation exists to be used only extreme circumstances, not as a catch all for "hey, sorry we made the wrong hire". It's more expensive to hire a candidate and kick them out on probation than to avoid making the wrong hire. This is another reason my approach works - we don't "milk" free labour, we don't need it. Our interview ensures we make the right hire first time, every time and part of that process is some "real" work.

Our interview process is awesome. Refined over a period of 10 years. Candidates learn something, we learn something, we collaborate with them. We often have candidates, even those who do not receive a job offer, compliment us on our process.

I'll write our interview process up one day and share it on HN so others can benefit.

Fixing a simple bug in your own software is an order of magnitude faster than doing it in someone else's codebase. Make no mistake, it would be cheaper for them to fix it themselves than guide someone else through a paired-programming exercise. This isn't unpaid labor, it's more expensive labor.

Why is being biased in favour someone with domain knowledge a bad thing? I assume that is the domain you are hiring them to do.

Reply on news.ycombinator.com