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.
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.
> Oh, that was a learning project (or prototype code). If I were to write this code again, I would do $X
...where X is something like "use a unique ptr" or "assign ownership of this object to this other object instead".
They must have no training for their interviewers or maybe a training specifically to make them hostile gatekeepers?
The most important phrase here is at the end:
one candidate just got bumped to the next
stage based solely on the fact that in they
had a “Making awesome pancakes” in the CV,
which made me laugh.
And, it's fine.
Junior candidates have to be aware of this and don't get demotivated.
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.
I can vouch for this.
I've personally seen young people with interest and little formal professional experience get up to speed and become great professional.
You realize there can be hundreds of people applying to any position?
Even after some basic filtering, there can still be tens of qualified candidates.
Deep down. 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.
And there you have it--the hiring algorithm in a nutshell.
These “quirky” decisions are the perfect cover for underlying reasons that the interviewer might not want to put in writing.
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.
They're enjoying pointing out both how intelligent and experienced they are, and how discriminating they are.
This is pure social grandstanding to seek pleasure.
No thanks, my personal Github is not a LinkedIn profile.
>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.
If anything, I don't even code for a living anymore (went into system administration/devops engineering).
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.
How about no.
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)
See the justifications at https://www.npgsql.org/doc/basic-usage.html#parameters, for example. My experience is only with Postgres, but I imagine they translate.
Obviously Standards change, but that's what we learned when I went to school.
The only thing that should matter with style is consistency.
myFunc(char *str, int strlen)
Not sure I like that, anyway.
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#.
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.