|
|
|
|
|
by adeaver
4591 days ago
|
|
Except in a live coding exercise most people are trying to be efficient or 'to it right' and paying attention to what they are doing and how. I realize this is anecdotal, but 95% of the public code in my git repo is stuff I did as fun. I didn't care about being right, or care about memory issues or being thread safe or anything other than 'I wonder if...' In that instance, and I suspect a lot of other people public where they aren't contributing to something using the repo code as a talking point is counter-productive. Why did I do it that way? Because I wanted to see what would happen. |
|
Before the interview, I will check out your stuff and make sure I have compilers/interpreters for your favorite languages (as best I can identify them). Then I will do a combination of live coding, and talking about repositories that might have caught my eye.
In this kind of situation "Why did I do it that way? Because I wanted to see what would happen" Is a great answer. It leads into a discussion about what happened, and whether or not you would do it again (without waiting half an hour for you to work through a problem of my devising). I could not care less whether the code was good or bad if you can show that you analyzed the experience and learned from it.
Part of writing good code is having written bad code in the past. I get that. I'm a programmer myself.
Now, we do not use Github as a filter (as the article discourages). If you put your Github in your resume, I will use it to make the interview itself a more valuable experience for both of us. If you chose not to put your Github on your resume, then you will get the generic interview, and I might not have your text editor/IDE ready to go.