When I was an undergrad I would post all my homework assignments on Github, but I later learned this was a mistake when I interviewed at Apple and a few of their engineers went over my homework code with a fine tooth comb and found a memory leak in one of my OS assignments. Reporting this to me, they asked me "why did you code this memory leak?". I didn't get the job. Now I have removed all this from my github. Unfortunately it's one of those things where "everything you say can and will be used against you".
> Unfortunately it's one of those things where "everything you say can and will be used against you".
Indeed.
It kinda takes the fun out of programming. Sometimes you just don't bother with error-checking and with making code production-grade, because you just wanted to publish this small thing that other people might find useful. If people find it useful but find bugs, they might as well send pull-requests.
And let's be honest: error checking is important and everything but it's quite a chore.
Often in your toy project it's okay to be optimistic.
And often the purpose for writing a project is to explore a topic, not to release a production grade project.
FWIW, I think that's terrible interviewing on their part.
Literally looking for their wallet under the lamp post because it's easy to pick nits in your homework assignments, but difficult to determine whether you could be a productive team member today under completely different circumstances with complete different incentives and forces on your choices.
How do you know that was the reason you didn't get the job? It sounds like they gave you an opportunity to say you made a mistake, and maybe figure out how you'd fix it.
Haven't been to Apple but that sounds extremely unlucky for you - can't imagine 99% of Apple engineers wanting to spend their time reading random github repositories made by a candidate they aren't even going to approve.
I still think this post is insightful, because it shows a subjective and presumably rather honest perspective on reviewing CVs. Sure, it's no big deal that a recent graduate points to an unmaintained GitHub profile with only assignment code on it. But these applicants make whoever is considering hiring them look at something that's both irrelevant and boring. I wouldn't blame them too much, though. They've probably heard somewhere that you should have code on GitHub and link to your GitHub account in your CV, and they lack the experience to take this advise with a grain of salt.
It reads a little like the last time he was hiring having a github profile at all was a differentiator. Nowadays almost every applicant has a profile but it's just full of forks and unfinished learn to code projects.
Unless you're competitively _desirable_ to work for then your hiring strategy should be something close to: _hire literally anyone you can afford_[0].
This industry too often overlooks the enormous value that can be harvested by training under-skilled hopefuls into fully productive team members. There's often an associated fear that, once trained, the individuals in question will jump ship for greener pastures. The answer to that problem should be obvious: be a green pasture.
Yes. Most of us are not working towards society changed stuff can easily afford half hour a day and sometimes more on making another member of society productive and contribute to the economy. That you also get employees that are very grateful to the company for the initial chance is just a plus.
I don't think this generalizes. If you're a larger, more established company, sure, but most startups and small businesses can't afford to spend significant engineering time not building features that customers pay for. For those companies, there is a ton of value to hiring someone experienced who is at least somewhat familiar with your stack.
Hiring is mostly about rejecting people because there are simply too many people.
The myth that there is a desperate skills shortage exists to sell training and to drive down wages. The industry is actually saturated except for a few particular niches, of which generalist webdev isn’t one.
The issue is most companies don't want to be greener pastures - which usually means they don't want to promote or give raises internally too often. No idea why.
I really don't understand what would possess someone to publish something like this.
It's one thing to decide that your own company has such little value to you that you'd prefer to damage it by hiring people based on random arbitrary criteria rather than by how well you think they can perform the job. It's another thing entirely to actually decide to publish such idiocy, and tie it to you and your company's image.
When hiring for a junior position, you can probably get away with applicants knowing that you're using nonsense criteria. They likely don't care, don't know any better, or have no other options. But some day you're going to want to hire a senior developer, and they're going to do research on your company, and see that your hiring practices are so bad that you let CV-jokes and the presence of profile pictures affect your rankings, and they are going to rightfully identify those as red flags and go elsewhere.
I'm also sure many people take special issue with the author's desire for a picture of the applicant on their Github profile, considering how often that kind of thing represents a source of bias in hiring. No, your company should not be encouraging applicants to reveal their race, gender, and physical attractiveness at the time of application so the author can factor those things into his hiring decisions.
>A small tip, if you expect people to visit your profile (and I assume you do, since you provided the link in the resume), it is worth it to put a (professional) picture of yourself there. The profiler readme on GitHub is also surprising attractive when looking at a candidate.
No thanks, my personal Github is not a LinkedIn profile.
People put Github on their CV because employers like candidates who are interested enough in programming to do it in their spare time (for better or worse). My Github is my personal tool to interact with the open source community for practical purposes and to host my own projects, not a professional profile built to impress you. I just put it on my CV for your interest. Not everything I mention on my CV is done solely in service of getting my next job.
>GitHub is there so you can present your code to the world in an organised, documented, and personalised way
Not really, it is not a portfolio. It is a tool for programming and collaboration.
GitHub is there so you can present your code to the world in an organised, documented, and personalised way. Part of that includes a short bio and profile pic. I don’t expect a professionally framed headshot with nice lighting, just upload something that’s not the default, to set yourself slightly apart from the crowd.
I don't believe any company without a big brand or insane salaries can really reject candidates because of bad Github profile pictures or bad code from years ago when the candidate was still a student.
It’s not unreasonable to expect a candidate to groom their public profile before using it as part of a job application. If they have some bad, old code they’re not proud of, why not make it private temporarily?
Let me reframe this: You are the director of engineering. I am a manager reporting to you.
You ask me to hire and lead a team to build X, which will generate $Y in revenue. But I tell you that everything is delayed, because I'm having trouble finding good hires.
"What's the problem," you ask, "let's pair up and go through the funnel." And I reject resumes because I don't like the profile pictures or some old homework assignments.
Do you accept my argument that the company has to wait on $Y in revenue until I find some candidates who have nicely formatted github profiles and a blemish-less history of code, even code not written for professional purposes?
Or do you replace me with a manager who is focused on shipping a product using whatever team of misfits and uglies they can hire, provided they can actually do the job?
---
It's not unreasonable to prefer that candidates make our job as hiring managers easier, but at the end of the day, the hopes and dreams of an entire organization rests upon our ability to hire people who can do the job.
If our funnel is bursting with great people, we can disqualify unlucky people with little consequence. But for most companies, it's better to hire good engineers that have flaws in their presentation than to wait in the hopes that someone will present well, have the job skills, and be willing to accept the offer we can afford to make.
They don't just want developers, they want full stack developers and full pancake stack cooks! This field moves fast, gotta keep your skills up to date.
> A small tip, if you expect people to visit your profile (and I assume you do, since you provided the link in the resume), it is worth it to put a (professional) picture of yourself there.
"On the other hand, I find such code painful to look at."
It also pains me to see the opening bracket in its own line. (Being from a field where I don't get to use C# or SQL, I don't understand what the author is referring to)
Even if the ID variable is an integer (and therefore you're immune to injection), it's still inefficient. If you use the command "select * from Customer where ID=@id" and you set ID as a parameter instead, then caching can happen behind the scenes ("prepared statements").
It's also what VS Code autoformats even C++ to by default.
Also I wonder if the other commenters reflexively saying "SQL injection" realize that is just the symptom; the underlying problem is that LINQ is not used. Even if the SQL injection was fixed, a literal SQL query is usually not the right tool in C#.
Re: braces on their own lines, one practical advantage of doing so (leaving aside subjective anesthetics like symmetry) is that source control (at least got) will be able to automatically distinguish and merge changes to the header and the body independently, since they're no longer adjacent.
This feels like a lot of noise. If we can't use our github profiles to show code that isn't meant for production, and we're applying to junior roles for people with less experience (and presumably few, if any, examples of production-ready code), what's left to publish? Should I unlink my github from my resume because it might detract from it?
In my last job (small company, probably not unlike the company here) I was involved in interviewing for a junior developer role. Most resumes contained a GitHub link.
But what was most fascinating to me was that these GitHub accounts were largely inactive. It's not hard to see this: the contributions/calendar feature let's you see at glance how much they've used GitHub, and it's basically the first thing you see when you open a profile. I literally clicked on GitHub links from resumes where the applicant had not used GitHub in the last 365 days.
unless being a core contributor to a top project there is virtually no benefit in including your gh profile in resume. for a matter of fact, during a period of general online housekeeping, i have deleted my personal gh account. i now use my work one when needed, and never include it in my cv.
I don't think this is true at all, though it may depend on what jobs you are seeking. When I look at github profiles I assume they are going to be forks and garbage, which is fine - the person still at least knows github exists and probably has some concept of the point of source control. But when I see a project with an actual purpose that they wrote, or some commit history to a project they forked, that is a big plus! That is strong evidence that the candidate has a passion for programming.
reply