Thank you for the response. That's good to know. I don't understand why interviewing isn't just, "Did you work yesterday? Great. Open up your laptop and show me the code you wrote yesterday."
1. The person interviewing you is often less experienced and skilled than they let on. They can't make sense of your code, not because it's not any good, but because they don't code at your skill level in that language.
2. Showing off code, while making for a better interview than the behavioral stuff that passes for interviewing at the bigs, still isn't all that great a tool. There are a lot of people who might show it off, and might even talk the talk, but who didn't write all of it and might not even understand it.
3. The code is secondary to the job. How you come up with the code is primary to the job, and showing off code doesn't show off how you came up with it. Even the best code ever would be a bad hire if it took you six months to come up with it or annoyed your fellow devs for months in coming up with it.
4. The way you're used to coding will be different than the culture of the new firm. It just is. If hired, you're going to adapt to it, not the other way around.
Ok. How about, "Show me your personal git commit log from yesterday?" That deals with most of 2 and 3—granted not all of the scenarios.
As for 1, there are many languages and frameworks that I wouldn't be able to say if they used best practices for, but I think I could generally recognize good vs. bad code with no prior knowledge of the language.
1. The person interviewing you is often less experienced and skilled than they let on. They can't make sense of your code, not because it's not any good, but because they don't code at your skill level in that language.
2. Showing off code, while making for a better interview than the behavioral stuff that passes for interviewing at the bigs, still isn't all that great a tool. There are a lot of people who might show it off, and might even talk the talk, but who didn't write all of it and might not even understand it.
3. The code is secondary to the job. How you come up with the code is primary to the job, and showing off code doesn't show off how you came up with it. Even the best code ever would be a bad hire if it took you six months to come up with it or annoyed your fellow devs for months in coming up with it.
4. The way you're used to coding will be different than the culture of the new firm. It just is. If hired, you're going to adapt to it, not the other way around.