Ask HN: Advice on flipping SWE interviews upside-down?

[offbynull]

We're about to start interviewing for an SWE role. Rather than asking each candidate to do leetcode questions or take-home assignments, we're going to be asking them to present some existing code they've written and pair with a team member to modify it in some meaningful way. The team member and the candidate work together as equals to add in a new feature, switch to different data structures / algorithms, fix a bug, document, etc..

Has anyone had experience with doing something like this in the past? Everything I’ve personally experienced has been leetcode or take-homes. My hope is that ...

1. the candidate feels more comfortable during the interview since it’s their code.

2. the candidate and the team get a better feel for how each other works / how they work together.

3. it helps the candidate interview us as much as we're interviewing them.

4. it’s more respectful of the candidate’s time (no take-home or grinding leetcode required).

EDIT: I should mention that we have backup problems in place if they don't feel comfortable sharing. The context will be the same, both the candidate and the team member will be working as equals to address the problem.

[version_five]

If you ask someone to bring their own code, you are assuming they have some code to share that they are also confident enough in to bring. I can see lots of people agonizing over this. Even if you've got a relatively broad base of shareable code you've written, what's right for the context of the interview? It would be stressful for a lot of people, probably more than just doing a coding exercise.

I'd suggest giving people another option as well.

[offbynull → version_five]

I thought about this and we have a backup problems in place if they don't feel comfortable sharing. The context will be the same, both the candidate and the team member will be working as equals to address the problem. Although, in this case, the team member is already familiar with the problem.

[mattbillenstein]

Few problems - this is a lot of overhead for you I think, and it'll be hard to measure the strength of one candidate vs another.

Also, a lot of SWEs most significant code bases they've worked on will not be theirs, but property of a previous employer.

The best I've figured out is to have a straightforward coding exercise that doesn't have a lot of dependencies and can be solved fairly quickly in any language the candidate chooses. Do this live in one of your interview sessions - I don't like take-home stuff, it discourages above-average candidates.

Have a couple places where they could chose the wrong data structure or algorithm. And have a follow-up that modifies the first solution to do something slightly different. Give this same exercise to all candidates - you'll more easily know if candidate A is better than candidate B, etc.

[nagyf]

All code I wrote during my 12 YoE is a property of a company. And obviously I don’t even have access to it.

With this type of interview you rule out a LOT of people, and only keep in the pool who either works on open source, or do great projects in their free time.

If that’s the intention, do it. But otherwise I don’t think it’s a good idea.

I think a _ WELL PAID_ take home project is much better way to interview people.

(Saying all this from the interviewee perspective)