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.
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)
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.