I think looking at the Github of applicants is useful as a conversation starter however: "Oh I see you've built X with Y, what was interesting about that? What did you learn?"
Like does that just mean overly long functions? Lazy symbol naming? Linter violations? Lack of tests? Those might all be reasonable through the "not prod" lens, but there's other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used, or using obviously non-idiomatic structures like an indexed loop in Python.
None of this should be a deal breaker, but if you're seeing stuff that's obviously like "I would be annoyed to be reviewing this code" then it's worth talking about.
One of the reasons why I enjoy programming as a hobby and avoid it as a profession is the pleasure of reinventing the wheel. For example: I learnt how to use git and am learning how to read datasheets is by taking simple Arduino programs then refining it until most of the abstractions are removed. Likewise, it can be fun to implement my own data structures and algorithms. Contrast that to simply using libraries. It's mostly an exercise of reading documentation and hoping that a tiny subset of what's learnt is transferable to other libraries.
If nothing else, again, it's an opportunity for a conversation— the person might have a great war story about how they deep-dived on library X after finding it lacking, or tried to submit a PR that was shot down. Or even if they had no idea, it's an opportunity for them to demonstrate teachability, like "oh that looks nifty, yes I can definitely see how that would make this whole section redundant and the rest easier to read."
As an early career developer, your team wants you to write useful code with few errors and that works best when you can rely on established libraries.
But as your career progresses, your value comes from understanding how those libraries work and from being capable of writing new libraries that support and stabilize the early career developers coming up behind you.
And the only way to go from the first group to the second is from getting your hands dirty. Writing personal and hobby projects that “reinvent the wheel” is one of the best ways to do that.
What you’re going to do, though, is ask them to let you have a look round the treehouse they built on weekends in their backyard.
After all, the choices of materials and techniques they use there in that ‘not for production’ context probably tell you a lot about how they approach their work, right?
- What their work looks like when they're solely in charge of it and it's not a massive, long-lived team effort.
- Obvious flaws that shouldn't be acceptable to anyone. Like, loose boards, nails sticking out, a fence that's not supported and may collapse if a kid leans on it wrong.
Neither of these things are the entirety of the evaluation, but IMO they're a relevant signal to use in combination with talking through past professional projects, particularly if the professional projects aren't visible or known to the interviewer.
I love breaking things down to understand them. Rewriting them (sometimes better!) to get a feel for what is involved. I think it makes me a better programmer. It saddens me to hear that this is an undesirable quality in seeking engineering candidates, for some.
For an example from my own code— I was learning Rust via AoC a few years ago, and I deliberately chose to do some of the challenges with natural language inputs using Pest rather than just dumb regexes [1]. The regex solution would have almost certainly been shorter and quicker for this limited task, but I would have no trouble justifying this design choice to an interviewer as having been an intentional learning experience.
[1]: https://github.com/mikepurvis/advent-of-code/blob/master/202...
This is a particularly shitty signal to my mind. Half the reason to experiment with writing software outside of work is to reinvent the wheel and see what shakes out - you'll almost never have the opportunity to do that at work, and if nobody ever does that, we never discover better ways of developing software.
As for "reinventing the wheel", this overuse and overdependence on hundreds of libraries is how we as an industry keep running into the same old issues, so I'd quite happily reinvent the wheel for production. I'm not adverse to libraries, but they shouldnt be approached as a first resort.
I'm just glad I don't have my github on my CV
See that's interesting— I'm far from a testing-absolutist, and I agree with the basic premise here that there's no point having an elaborate "testing" strategy for a one-off script, stuff that isn't very branchy, etc.
However, there's also some stuff that I basically always write a trivial unit test for, assuming the language is set up to allow me to do so cheaply. Obvious examples of this include any kind of string processing, parsing, or regex-type logic— I'm just like, this looks fragile, and I'd like to know for me that it does what I think it does and I'm not going to be tripped up later by some subtle bug that boiled down to an edge case in this particular piece of trivially-isolated and testable logic.
Then again, I haven't used unit tests much at all in any language other than Python (maybe a few others, but not for some time certainly), maybe other languages make it much easier.
I wouldn't call not using a well known library "reinventing the wheel". The wheel in that expression is a concept, not a implementation. A library is an implementation of a concept. Writing yourself code instead of using a library is a great way to learn about what that library does and the tradeoffs it makes.
When I think about "reinventing the wheel" as something negative, I think about something like "Medical researcher discovers integration, gets 75 citations": https://fliptomato.wordpress.com/2007/03/19/medical-research....
Your comment is a great reason for me not to share my Github profile.
I'm not going to treat my Github project defensively. The notion that most people need to worry about what they put in their README because some interviewer is going to look at it - it's just so much better not to let them see your Github profile.
The irony with this article is that it's proposing a solution to a problem - yet that solution is as problematic. A resume is a poor indicator of one's skills, as is their Github profile.
I'd argue with you that a GitHub profile could be a useful signal, but it's not a given.
As a hiring manager:
- If they don't have a GH profile, I won't ding them.
- If they add it to the resume, and it's a scrap yard, I won't ding them.
- If they add it to the resume, and it's well maintained, I will ask questions about it.
- If they add it to the resume, and it's clearly deception, I will have a negative perception.
I feel like most hiring managers take this approach.
The message is "I code in ny spare time" not "this is representative of my professional work"
My repos are hidden specifically because I do them for fun. I’d make them public if tinkering were an understood thing but its not.
> If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him.
Better to have a clear separation between work and play.
Make it private like you are doing?
If you don't want someone to perceive something about you, then don't make it public. If you do make it public and add it to a resume then don't be surprised if the person who manages programmers is interested in possibly looking at the programming that person has done.
I proposed that you can tinker in public if you make sure your tinkering won't be confused for your magnum opus. You dismissed that because a one sentence readme isn't needed on a public side project.
I didn’t say anything about adding a link to a resume. This thread has hints of people thinking “I’ll just look up their GitHub if they don’t include it” and other threads make that explicit.
> You dismissed that because a one sentence readme isn't needed on a public side project.
I don’t think that’s what I said. I was saying that tracking all the things one might be judged for is unreasonable, not that having a readme is unreasonable.
https://news.ycombinator.com/newsguidelines.html
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
It's a personal project. I do it for fun. I didn't write tests because it wasn't fun. I cut corners to get to the fun part faster. I made breaking changes because the one single user accepted them.
OTOH, reinventing the wheel as a hobby and to deepen understanding makes perfect sense.
If you just want an offsite backup for your noodling around, make it a private repo; the contributor limit won't be a problem. If you're putting it out for the world to see, take the time to comment it, put a little polish on it, a decent README, and a license. If nothing else you'll be starting from a place of sanity if you ever have to revisit the code.
I don't view GitHub as a place to show off your code, or a place to find new code, or whatever. It's where my code is stored. I trust what's on GitHub more than I trust what's on any server, or any laptop, or running on my dev environment right now. As such, the idea of "cleaning it up" before putting it on GitHub seems backward. Code gets committed as soon as it's written, and if it gets cleaned up that history gets saved too. If somebody wants to pull my shitcode down that doesn't even have a readme, that's on them.
They are, that's the moment you see how the person code when she/he is responsible. You see the real skills and potentials of that person.
On a personal project there is no accountability. The developer didn’t have to understand what someone else wanted and try to figure out how to make it real. They set their own goalposts and had freedom to move them at will. You have no idea what their ambition was.
Adam Savage had some interesting insights relevant to this in the context of evaluating model makers and artists for special FX work. While portfolio pieces showing their own concepts or creations might show off heir basic craft skills, it doesn’t show that they can create something to fulfill someone else’s vision - and that is the job. So what you want are portfolio pieces where they have drawn or built something recognizable - a replica or a scale model or portrait or something. Because that shows they can direct their skill to a particular goal. You know what they were trying to go for, and you can tell whether or not they nailed it.
Mostly I’m hiring for developers to work in a large team, within a large organization. What they can accomplish when left to their own devices is scarcely relevant to what they will be able to do in that work environment.
There is no responsibility in small side projects. I write better code during my day job because I know other people will eventually have to interact with it.