Knowing what good work looks like is a plus, but I wouldn't be convinced by cherry-picked successes. That doesn't tell me how much you struggled with them, how many others you failed, or how much of the work was actually yours.
I think most of your concerns could be answered fairly quickly in a conversation, though. I can look over a Github repo and check out its history and ask specific questions about changes and why they were made or why design decisions were made.
The cherry-picked successes thing is certainly a problem, though, and not just for coding. Maybe it's the candidates I've asked it but when asked "tell me about when you made a mistake in a project" they tend to answer with a strength and try to re-frame it as a weakness. "Oh, I worked too hard on this project and it made me tired" isn't a weakness. "I worked too hard on this project and that made me neglect business requirements since I was too myopic to notice" is a weakness.
Sorry if that's a tangent, it's been a pet peeve of mine since I started interviewing that not many people are humble enough or have thought enough about what their weaknesses actually are, and how that affects the success of their work.
