All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored.

If all this person is evaluating me on is my Github, they'll think that I've never advanced beyond an amateur level despite my having over a decade of experience in the industry... all because I treat my open source work as a hobby rather than as a second job.

When I go to a GitHub as a hiring manager, I try to get as much signal as I can. You are scared that I'll solely judge you on the code, but I'm looking for metadata. Is this person interested in or exploring problems/technologies that are related to the problems/technologies we are using here? Oh, They are exclusively doing music based coding? INTERESTING. Let's talk about that in the interview.

Oh, They've contributed a bug report to an open source project, lemme see what that looks like. Nice, repro steps are clear.

And yes, some hiring managers are gonna say "welp, this candidate isn't an open source ninja so we don't want them." But that's not all hiring managers.

What is a big turn off for me personally is the "I'm gonna slap something on github to tick the box" group. I had someone submit a resume with a link to their website and a link to their github. The website was literally just a demo site, but they had changed all of the blog titles so it looked like real posts, but if you clicked through, it was all lorem ipsum. The GitHub was also just the code for this site.

I'll take a graveyard of personal exploration everyday over a half-baked sham site. (Note: They could have just been playing around BUT TELL ME THAT! Because it sure looked like an attempt to look the part.)

So probably is good risk management to not include your GitHub ever when applying.

(and the inverse holds as well: if you do want to be evaluated at least in part based on something, consider putting it on your resume).

Still, I'd be pretty irritated to learn that someone decided not to even talk to me because I included a github link to some toy project that they didn't like.

I do think all hiring processes have a component of arbitrariness, so I don’t think it is necessarily a bad sign that a company quickly dismiss candidates from poorly-maintained GitHub accounts. I would gladly not show my GitHub and try to get the job showing my skills in some other way.

There are other processes where you must never fail. For those you want to minimize risks. If you want a job at X and nowhere else, this is your situation. But that's not very common.

Could go either way.

It seems pretty clear that the Github link in resumes has been cargo-culted for several years now.

Maybe a location thing. I am from India.

But if someone lists their Github on a resume, and then the whole account is just full of do-nothing forks and no original work, I'm going to be a little suspicious.

If recruiters start looking only at github accounts, dishonest job seekers will quickly learn to create fake github accounts, just as they present fake resumes now.

A few of the most successful and memorable hires I was a part of have real github accounts with something more than a bunch of forks or fancy profile readme.

In my opinion, it doesn’t matter if the content isn’t representative of what you want to do at work. Seeing that you’re curious and interested in building things, trying weird experiments, and so on is a strong data point in and of it’s self.

Here’s a similar example from an unrelated field: there’s a handyman that lives down the street from me. His humble home is neatly manicured and I often see him outside in the morning, dressed for the job and working on projects. Observing the pride he takes in his craft was a signal to me that he probably does good work. And after hiring him for a small project, my hunch was correct.

I am sure you can find valid candidates with your method, but also that you could be missing much better ones.

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.

OTOH, reinventing the wheel as a hobby and to deepen understanding makes perfect sense.

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.

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....

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.

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.

It's certainly possible to get from my real name to my leisure activities and vice versa with a concerted effort, but the first page or two of a casual Google search won't do it.

Yes, but only if it’s representative of their work. Good luck finding the one kind of sensible library I’ve written in the 100 forks and experiments.

And again, if you have nothing worth pinning, there's always the option to leave it off your resume.

This is my Github too; part of me thinks I should finally arse myself, remove unused repos, and build a portfolio with some example projects of how I build software (hopefully allowing me to skip a technical interview assignment), and maybe build some libraries for various purposes. Doesn't have to be anything unique.

I mean my CV is impressive (according to recruiters / employers), but it's a high level overview of projects I've been involved in, it doesn't really boil down to my individual achievements because projects are generally team efforts.

I do believe this is the danger of judging someone by CV alone though; just because they were a part of a project, doesn't mean they were big contributors to it. I've seen plenty of people who do one small commit per week and call it a day. There's always the one team member who gets carried by the rest of the team, just like in school. (childish as it might be, I do believe managers should review individual team members' contributions and to let people go if they're only along for the ride.)

This is a very common problem and I solved it in a very simple way: one account for playing, experimenting, testing and enjoying, and another for showing off. This is not fundamentally different to how people treat HN accounts.

If someone's GitHub profile is a mess, mixing experiments, serious work, goofy stuff, etc. as a result of their multiple uses of it (it's a _tool_ per se), that's up to them and it's up to no one to say "well, that doesn't look very professional to me, does it? your worth doesn't look great here".

But for me, experimental work is fine - I use github for conversation items.

But that's not necessarily a portfolio per se (something _really_ curated for that purpose, which is something specific). If it says so on the GitHub profile page "Portfolio", so be it.

And the recruiter is perfectly fine looking at it, but only for what it is.

What I'm rather aware of, is the pressure/mandate for everyone in the industry to showcase themselves, while that's not a relevant proxy for their fit to this or any job posting.

Sure there are people in the industry making themselves visible through github, twitter and whatnot, and some of these are also excellent. But that's only a tiny piece of the crowd that's available for hire.

I am usually easily able to tell if it is a half-baked project for some hobby-thing or active participation in e.g. a well known piece of open source software.

Someone who does this, is likely also skilled enough to separate those things. I don't only look at the user's own repos but also at contributions/comments etc. to others.

And just as the author, I too experience more often than not that people have NO idea how to set the level for own experience.

I'm preparing to publicly release a project with the intent of building it up to demonstrate my own experience level. I'm asking as someone with next to no prior public code despite developping back-end almost full time since I dropped out 10ish years ago. I guess I'm asking for external criteria for whether I'm impostor-syndroming!

1) All projects have a bad commit history. Just one commit and that's it. Usually it's something for school with really basic stuff inside. Most might be IDE provided "generate code" boilerplate.

Even a single commit beyond the GitHub provided initial commit example is enough. Multiple ones in a sane cycle is even better. Even if you just update some comments.

2) Does the project run? If I check out the project, is there a clear way to run it or does it rely on the compile & run commands being on the submitter's bash history?

Add a make/magefile or run.sh or anything.

3) README. Does it exist? GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.

4) Bonus task: does the repo have integrations or GH Actions enabled? If the project automatically runs some tests or builds on commit, it's a big green flag for me. If I'm going to be paying you over 100€/hour, I don't want you spending your time doing stuff manually if it can be automated with 15 minutes of boilerplate work.

This is a strange one, I am not sure why the priorities of a third party hosting platform should take priority. Many people use it is more of a cloud repo backup than a social sharing site.

So why knock people for using it differently? It does not measure their understanding of how Github works.

My memory sucks, that's why I write down what I'm planning to do with a project into the readme. It doesn't need to be super fancy with images and status badges and all that jazz.

This is perfectly enough:

  projectname
  ===========

  This fizzes

  TODO
  ----

  Add buzzing later
  Check if bazzing library is ready for production

However, I strongly associate Readme.md, designed for a web based intro view with Github.

It would be interesting to get the real history, because it could be a fluke of timing.

I’d bet if we look back at old source forge projects created pre-github there would be a strong correlation with the markdown version added and the rise of github. (Of course this could be a timing fluke)

Yes GitHub pushes you really hard to add one. But I disagree that not having one on a personal project means you don't understand how GitHub works. I don't need (or really even want) a README for a personal project. It detracts from writing code. If I neglect the personal project for months or years and come back to it then I'm not going to give a flying crap about the README anyway: I will have come back to it specifically to look at the code. Whether that's because I had a new/better idea or wanted to reminisce or maybe to copy/paste some idea from it.

All of the rest of your points are good though.

How ironic ;)

I do wonder what a recruiter looks for in a good README though. Technical chops or perspective on potential applications/intended project direction or ... ?

I've ended up building boilerplate workflows for various languages, environments, etc. to just drop in and tweak per-project.

But I think it's a plus for using something off the beaten path, provided that the other conditions are met.

I consider them as conversation items. I don't think anyone is expecting to see multiple completed products with 1k+ stars.

The worst case is, you waste time agonising over the quality of your code and either: don't publish, or no one even looks at it (highly likely)

You're not about to get code-reviewed. At most, if anything, it would be:

"explain this class/function": I'd expect you to vaguely know the answer after reading it

or, "why did you do <something> this way?": answers like "I got it from SO", "I don't know of a better way" are perfectly fine.

I use my pinned repositories to showcase side projects that I've worked on that are either complicated/challenging problems or that solve a specific problem in a complete way. These 6 repositories are "the most serious" work that is available in my public GitHub profile.

Some time ago, when I put my mind to doing this, I made sure to put extra effort and attention to detail into about a dozen different projects that were in my public profile, so that I had options across languages, project types, etc., for what I'd pin. I put each project through its paces, made sure it ran on multiple platforms (or, that there were notes in the README about how to get there otherwise), cleaned up Makefiles, test suites, etc.

At least one of these projects is incomplete and/or a work in progress, but I've indicated as much in the README, but it's also obvious to see exactly where (and why) that project stalled, if you read through the code.

I can't say that it's helped get me a job (I haven't changed employers) but I do feel a little better about the other 100 or so projects in my public profile now that are in varying states of completeness.

I like to write "toy" software that more often than not does not leave my laptop. In the rare occasions I believe the software I write could be of help to others, I do publish it. But man, I code in my free time for fun! I couldn't care less about following guidelines or the latest patterns or using docker, or whatever.

In this case there's no need to publish this type of code; Github offers private repositories for free. If one is convinced that there is value for other people from half-baked experiments, it's definitely worth publishing them in the open (it's possible that they're valuable), but if there isn't, why doing it?

I also notice that many people display private commits in their profile stats; this way, one can signal the amount of activity, if they want (within the limits of what's possible, as certainly commits don't necessarily correlate with intense activity).

When I read CV and I see github link it is "nice to have" so I check it after I consider that person has enough work experience.

I have only seen "meh" code on GH. If someone would have contributions to some real OSS project he would probably jump queue to front, but it is not like I would throw away application because person is trying just stuff out on GH.

That said - I don't see value in putting my own trash projects on public GH profile. I can have it in local repository or in private repo if I want to synch it between computers or deploy to VPS.

Whenever an employer wants to look at my GitHub I tell them, "Look, this is all going to be half finished tutorials... as soon as I'm halfway decent with a technology I go out and build something proprietary"

Maybe I'm getting old and no longer "with it", but to me, this is just like teenagers entering way too much personal info on social media just because there are empty text boxes available.

I have a "code" dir with dozens of subdirectories where I keep all that stuff. Some of those are local git repos because I'm starting to do something actually non-trivial there, and yes, some of those eventually get the "git remote add ..." treatment, and get published on a public code forge somewhere.

1. It forces me to write a README. No matter how small the project, I afford it an introductory paragraph, installation instructions, usage instructions, and a license. Doing that all the time helps build good habits. If it hurts, I’m not doing it often enough. Doing it often enough helps overcome resistance one day when it actually counts.

2. I contribute something back. It’s not exactly curl, but who am I to judge whether my project will be too trivial to be useful for others? I prefer to leave that decision up to the visitor.

3. Future me is going to get a README for free a couple of years down the road, when the details are long forgotten.

Example: this repository [1] is for a 50-line Bash script [2].

[1]: https://github.com/claui/aws-credential-1password

[2]: https://github.com/claui/aws-credential-1password/blob/main/...

If I want to track version control across multiple machines without rolling my own git server or bothering to mark the repo private?

I don't think it's an old thing. I think it's a HN crowd not really understanding user experience thing

Github is a code repository and not a social network account, so yes many people use it for "half finished tutorials" and little exploratory non-projects up on the Internet?"

I would not want to work at a company where the tech people are not aware that most repos are precisely that.

Thanks you for bringing that up. That is one of the reason I don't use GH. Other being the acquisition by MS.

Only put your best work on the professional one.

After all, if my hiring manager can't correctly evaluate which code is toy and which code is real (I have both on my Github), I don't trust his competence and I want to not talk to him so it is important that he filter me out. This way, my time is not wasted with incompetents.

Won't even entertain interviewing with them.

I shouldn't have to spend thousands of hours a year working on shit outside of work to prove that I can do my job. If it's not obvious from the interview and whatever test I'm given, then we have nothing further to discuss. One of the reasons I don't suffer from burnout is that once I'm finished with my full time job and my consulting side-gig, I leave it alone.

I might dabble in some new technology from time to time, but there's no reason to announce that to the world.

I don't understand your complaint. We have free code hosting platforms which support private projects, such as GitLab. You only showcase the projects you want to show, as a public profile is also your portfolio. It makes no sense to showcase half-assed projects you care nothing or feel ashamed to show, as no one forces you to make a git repo public.

It's perfectly fine if you do not curate your portfolio, but you also get the same problem if you don't curate your CV.

Personally, I received job offers based on my GitHub profile alone, as I happened to have a pet project which uses a particular tech stack used by a company. I know people who were automatically excluded from job applications as they claimed expertise on tech stacks they showcased in their GitHub profiles, and their pet projects included blatant eggregious problems which can only result from incompetence.

Companies hire based on the skillset they can evaluate, and if you make it your point to showcase shoddy work then that's a problem you create for yourself.

Historically, public repos were just where you put code that didn’t need to be private, like hobby code and experiments, just as much as showcase work or supported open source projects.

Has the culture changed so much that this way of using GitHub isn’t familiar to you? How do others here see it?

Yes, you can pin repos to your profile. But you can also create a profile repo. See https://docs.github.com/en/account-and-profile/setting-up-an...

I wrote a blog post about this and the profile generator I made for myself - https://blog.urth.org/2022/03/28/yet-another-github-profile-...

> Above all, I try to hire people who I'd want to pair with tomorrow. People who are better than me, and people who I can learn from.

It seems the only way to get hired period is to have all the experience in the world, at least from the author's perspective. This mentality is far more dangerous since it disallows the idea that someone can get better at a job over time.

Also I feel like this conclusion is just a longform version of "we only hire ninjas and rockstars". The author openly disdains applicants who are so "full of themselves" that they send in overly detailed resumes, but conveniently omits the fact (which everyone here knows) that resumes have to be catered to the filters of your HR software to even land on a hiring manager's desk.

His conclusion is that stuffed resumes are for losers, and only he, the hiring manager with the Midas touch, can see the true value of an individual by glancing over their code and preparing some pitfall questions. This smacks of self-centered egotism and coder bro mentality.

Also as others have pointed out, good coding jobs exist in fintech, government, and 1000s of other industries that this guy sneeringly looks down his nose at.

I (started working in IT around the millennium) have learned stuff from juniors with a few years of experience - because their experience is in a different field from me. Most of the best practices in the Javascript ecosystem I learned from one young still-in-school JS savant. He didn't know crap about backend or databases, but the dude was a complete wizard with Typescript (and later Rust).

the general rule is that if i don't hire juniors, then as a manager i want to hire people who are better developers than me.

otherwise if i hire juniors, i obviously expect them to learn, but the paring point is still relevant, and even juniors may bring an interesting perspective to the team, not just their coding skills.

Better can mean better at learning or teaching, cleaner approaches to problem-solving, interesting combinations of ideas I wouldn't have thought of, more potential, or any number of other things.

I firmly believe in only hiring people who are better than I am. That involves looking for ways the candidate is better than I am instead waiting for the candidate to fail the entrance exam.

"The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means,..."

I really enjoy coding in my few hours (read < 1 hour) of spare time after my son goes to bed, and while I could spend that time preening immaculate projects to impress employers and keep my commit history alive, that would kill the joy of programming for me. I would seriously consider a career change if maintaining code as a second job was required to keep my career alive. Additionally, I have seen many job candidates attempt to make github accounts specifically for resumes and the results are mostly mediocre due to the lack of time and motivation required to build something informative enough to effect the outcome of a hiring. If anything the general consensus from looking at theses github accounts is on average more negative than positive when we see repositories of "bootcamp" exercises.

The author states a disclaimer "Doing open source is not a be-all and end-all by any means" which may be true in his case, but what he is doing is encouraging this behaviour in other workplaces. IMO resume-github showboating has lessened in the past few years, but I would hate for us to regress again.

I'm considering writing a small library that I've always needed at every job I've had (and always had to half-ass implement part of its functionality due to time/budget constraints). To have it slowly cooked, pristine, fully tested, reliable and a pleasure to use for people. Because that's what I wanted at those times in those jobs.

Not only I would love working on it, but would also help with an aggressive "if you like it, good, if not, good luck with your coding tests" approach to being hired. Disclaimer: I do poorly in tests.

But if I was required to have that, I wouldn't ever had a job until now, simple as that.

If you're going by some trivial standard (github repos, leetcode ranks, whatever the case may be) you're going to be talking to a lot of people who made it a priority to get hired, not to write good code or even work well in a business environment. I'd argue that high-effort resumé stuffing is even worse than the lazy kind, because you might be tempted to give the candidate the benefit of the doubt or skip over some of the validation questions that a resumé-based hiring process might demand. You might even end up hiring bad coders who are better at making stuff up and repeating textbook excerpts than writing or maintaining any real code.

The author states that during interviews he talks through the code the interviewee has written and the decisions they have made, but such a process could easily be reversed as well. Grab some company code with known architectural flaws or technical debt and walk through that. Ask what they would've done differently and why. Ask what they would do to improve it. This probably works best with some archived code from stale branches or sunset products so you don't give off the impression that you're doing this for your gain and you won't risk leaking any important company secrets anyway. Better yet, grab some of your company's open source projects (Your company has a public Github as well, right?)

Agree and this is a reason I selfhost my own git server and repositories. I still want to use git, but what I personally write is none of a third parties business. I have a bunch of scripts and a few programs in various language's, some side project websites and the like. But none of that is something a potential employer needs to see or start dissecting.

The good news is, it's probably not true anyway. Whenever you see these posts, they're almost always written by somebody with a weak resume who spends all of their free time maintaining open source, hoping to convince somebody else to read their github profile.

From an intellectual-property standpoint: it actually might be.

But I do think intellectual property laws need to change.

Be careful with this assumption.

Interviews generally measure how well a person responds to anxiety. This can overwhelmingly dominate and mask any signals about their competency.

I can talk about algorithms and data structures all day and have little difficulty solving fairly challenging problems.

Stick me in an interview and, depending on a lot of different factors, I can easily come across like this person. Sure I've built open source libraries, written countless articles, and have given talks at open source conferences but at the end of the day I can't handle 5 hours of talking with people and then do even the most basic tasks. Anxiety and exhaustion will over-ride everything at that point.

You may spend years learning about some field like systems programming, and then when you make a contribution to the Linux kernel it's only a few lines. There's no way to know from that how well you actually understand the kernel. You might have a lot of experience, but so did previous contributors, so it looks like you only did a little bit when actually you know quite a lot.

Also there's a lot of work in coding a few lines of code that isn't just those lines. You may have taken apart very large systems and grepped huge amounts of logs to understand something, while having written many intermediate versions of a solution, only for you to figure out the problem could be elegantly solved.

For me the smart way to interview has always been the open ended technical discussion. People who don't know the vocabulary show this very quickly. Imagine pretending to be a surgeon, you'll last one minute. People who are close to the work but haven't done it will last a bit longer but there are so many technical terms they will also drop out, typically when you ask for some sort of judgement on A Vs B. This still hasn't gone wrong for me, my only dud hires have been people who wanted to do something else rather than couldn't do it.

If that's the case, then that should be evident in the commit log.

My one commit in the Linux kernel mostly just moves a few assignments / variables around; but the commit message should make it clear the effort that went into it.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

There is a class of applicants who produce 3-4 page resumes filled with tedious details, with every technology they ever used bolded, and turgid prose describing internal software projects as if they should be common knowledge. It takes me probably 15 seconds to move on to the next candidate if I see one of those.

The next thing I filter on is choice of employers. If I see health insurer, big insurance, blah fortune 500 firm, government contractor, ... over and over again, then unless there's something in the first half of the first page of the resume that otherwise catches my eye, that resume is also going in the discard pile after 30 seconds.

Finally I'll scan for interesting projects. I generally want to find people who have done more than just CRUD UIs, and show some passion about the technology they've built and worked with. For somebody who makes it past this point, I'll have spent max 60 seconds with their resume. I then customize and send the message in the ATS and invite the applicant to check out the company and job posting.

FWIW I could describe my current role as "Building a cash management application to track $500m+ revenue for a global ethical cosmetics organisation" on my resume, which is 100% true, but really it's a React app with about a dozen pages of fairly simple CRUD actions. What the reality of the app is and how someone describes it on their resume are two very different things.

When I put together a resume, I figure I have about 3 seconds to get them to decide to continue reading the resume. So I do my best to put in whatever it takes to accomplish that (within the bounds of truth).

No one reads a resume straight through; they skim for the highlights they want to see.

The more skimming passes you get them to make over your resume because you've kept their interest up, the more likely the interview.

And if you're thinking that a resume is a poor format for getting this job done, you're right. :)

You also state that you want to see "passion" for the technology they have used. I don't really know how to put that in a resume. I have a lot of passion for most of the tech I use- I think that would show within minutes during a conversation or interview. But I'm not confidant my resume really communicates it. Putting "I Love Python!!!" in my resume seems a bit over the top...

Passion for tech - you are right that this is hard to boil down to a formula. I'm looking for people who exhibit signals like (for example) they read HN, have interests in learning languages beyond the ones they're comfortable in, have maybe messed around a little with hardware, were in technology clubs in high school or college, learned programming as a kid, have a hobby project, etc. It's not so much about the hours that people will put in, but rather their engagement / pride-in-work / creativity / ability to propose alternate-solutions, all of which are good things to have, and are easy to qualify for with "enjoys technology."

I suppose I should consider a way to indicate the I read Hacker News on my resume :) Thanks for responding, I may be able to improve my resume some by considering how to show more of those things. Right now, I focus a lot on Python in my resume, because that is my primary language of expertise and what I use every day. But I am very interested in Rust and various functional languages in general too.

CRUD stands for Create, Read, Update, Delete. Isn't every UI, at some level, a CRUD UI? A wiki is a CRUD UI. A recipe tracker is a CRUD UI. A custom CMS for a community organization is a CRUD UI. A custom web forum is a CRUD UI. Facebook is a CRUD UI.

Someone could reimplement Mediawiki, and you'd reject them because "it's just a CRUD UI?"

Frankly, I like that not everyone is conforming to the exact same hiring metrics. As somebody who's built dozens of personal projects (a few of which I've been able to monetize), this would have been precisely the kind of hiring manager that a younger version of me would have liked to see.

Look like his rationale is if you can't speak high level and you can't resist over-engineering solutions; it isn't going to work out. That saves everyone time and sounds reasonable to me.

That's way too much, even for a long career. Two pages is enough. The more resume there is, the more bullshit you have to read. The career history part should be a list of job-titles and dates, with a brief description of each role, noting any salient achievements. Many recruiters will set aside any resume longer than two pages.

One of the important skills I would be looking for in a recruit would be the ability to express themselves clearly, concisely, and persuasively. Clarity and conciseness are marks of the ability to think. Persuasiveness is actually something that makes me suspicious, but in many jobs the ability to persuade others is an asset (leadership positions, for example). So YMMV.

I've always struggled with conciseness; I'm in love with the sound of my own voice.

    page 1:
        general objectives
        current occupation
        summary of the most important or interesting skills and projects
    page 2:
        skills (that's the list of all tech i ever worked with. just the names, no details. only the most important ones are bold.)
        work history (list of companies, dates and titles)
    page 3:
        education
        detailed work experience (that's a long list of every project i ever worked on, and the role i had there, split up in multiple subsections that i can include as appropriate)
            software development
            sysadmin work
    page 4: 
            mentor and teaching experience
            presentations and workshops
    page 5:
            organizing events
            experience working with kids (that i only include for relevant ed-tech or training jobs)

do you think it would be better to just skip the project list? i think it's better than a list of projects on github (which wouldn't have any of the interesting projects)

- Skip the objective, they are often really generic so people have become accustomed to just skipping ahead rather than reading carefully.

- Presentations and workshops, especially if they are at bigger conferences, could be worth highlighting for more senior roles.

- Education is good to keep just in case there is some kind of automatic filtering.

Personally I have an extended version of my resume that has every job / project written out (that I plan to keep adding to over time), but when I submit a resume I pare down the items to only the ones most relevant to the role.

Hey, I'm not a specialist in this stuff - I've tended to stay in the same job until it became impossible for some reason or other, so I haven't applied for that many jobs. But I was hitched to a careers consultant for 15 years, whose core trade was advising students on how to write résumés. Its only purpose is to get you an interview; if you drop your pants in the résumé, then there's nothing left for the recruiter to be curious about.

A résumé is a concise overview of your education and career. If you feel you need to describe your objectives and attitudes, or expand on some major achievement, I think that belongs in your covering letter - which can be an essay of sorts (but I keep mine short). The covering letter is tailored to the firm you are applying to. The résumé can then be boilerplate, so you can use the same résumé for each firm you apply to; only the covering letter is customised.

I treat the résumé as a sort of teaser. The covering letter has all the stuff about "If I can't get a job with your firm I'll have to kill myself, because no other employer will do" (no, please don't say anything like that!). But even the covering letter should not be more than two sides of paper. I'd stick to one side. If your concise pitch doesn't get you an interview, then doubling the length isn't going to improve your chances.

Self-testimonials are a waste of space, if your recruiters are any good. For example, "I am a good team player" is worthless, unless you can provide evidence, such as "In my present position I mentor new recruits, and provide training courses for my colleagues". And I think that kind of stuff belongs in the covering letter.

Again, I stress that I'm not a master of these matters. And most of my experience is based on UK hiring; I think puffing yourself up is more expected in the US tech marketplace. I've had one job in the USA, and I think I probably undersold myself that time.

hiding the list of projects for the sake of having material in the interview seems to contradict the idea that people want to see my projects on github.

either they do want to see projects or they don't. the project descriptions aren't detailed, and definitely less than a github project. so there still is plenty to talk about.

and i prefer interviews to be about things that can't easily be put in writing. spending the interview talking about historic facts feels like a waste of time. obviously as a candidate i can't choose what the interviewer wants to know, but by getting the facts out of the way, i feel like getting the freedom to talk about things that are actually interesting.

worse, if i am asked to share something about an interesting project, i might not know what to talk about because i don't know what the interviewer wants to hear. but if they have the list of projects they can skim it, pick one they find interesting and ask about that. at least that is how my thinking goes. i haven't actually been interviewed for some time, being more on the opposite side of the table.

as an interviewer i value these details because they allow me to find things to talk about. that is especially important with candidates who are not outspoken and may not be doing well answering open-ended questions. or they may just feel nervous, and not know what to say. the more i know about them up-front the easier it is for me to find something to talk about that they should be familiar with and ease them into the situation.

i agree that a long prosaic CV where it is difficult to find the things that the hiring manager is looking for is not helpful, but a list of projects which is effectively a kind of portfolio as an appendix should not be that.

maybe i should explicitly separate the project list from the CV, so that it doesn't look like the CV itself has 5 pages.

Only put down skills and technologies that you want to work with. I used to put Pentaho on my resume, even though it was the most frustrating thing I've ever worked with (before or since). A recruiter messaged me once about a Pentaho role, which I declined. I dropped Pentaho from my resume immediately.

> summary of the most important or interesting skills and projects

Aaand you can stop right there. Pages 2 and onward can be safely omitted.

That's where 95% of the software jobs are. Where are people supposed to work if not the places that employ the majority of software engineers?

There are simply too many candidates to give everybody a fair chance, and a good number of candidates left over post-filters who will require fewer interviews to narrow down to a hire. Resumes are about marketing yourself to get to the initial screening call so that you can make your case that you are qualified. It sucks, but if you haven't been dealt the lucky cards and you want to break into startups, I think it's probably useful to know the filtering that you're up against.

Ah yes, gatekeeping at its best.

Because every skilled person has time to build stuff in public.

Meanwhile, I have been blocked from applying for a position multiple times because the online form required me to enter a LinkedIn profile, which I don't have. It would require a lot of time to create a profile and message all my relatives and past co-workers to build a nice looking network.

I just treat this as a sign that we were probably no a good match anyway.

Could be a project you built to learn a language or framework, for example.

Or some library you wrote for your own personal use. If there's nothing sensitive, you can publish it under an open license or even without any license at all...

For this purpose, you only need to show authorship, which is different from ownership rights.

In general, your employer can't stop you there. Some exceptions would be if it conflicts with their products or if you disclose technological knowledge that could jeopardize competitive advantage.

Amazon has that provision in its employment contract. The problem is that Amazon has its fingers in so many pies, no matter what you write, you could potentially get in trouble with legal. One person I knew there had to wait six weeks for approval from legal so they could work on a Lisp interpreter.

Would you expect a little game jam game created in a weekend to lead to an ownership dispute with an employer? - Probably not, but I'm aware of a case where it has happened...

Why not publish an university project, a learning exercise, or something you built for fun? Surely there is more reason to create something than you're getting paid to do it, right? Or are artists just silly?

I don't begrudge others that do, but I don't code in my free time, I have other hobbies. Thus getting back to the original point made:

> Because every skilled person has time to build stuff in public.

If the candidate can show code and you're willing to look at it because it saves everyone's time, then sure, go ahead. But there are plenty of very good reasons a candidate might not be able to do so.

Furthermore, he didn't say it was his only metric, he said it was a possible metric.

What if I use having a bachelors degree in computer science as a strong metric? I could just as easily turn the tables on that requirement: some of the best programmers I've ever known didn't even have university degrees at all and were completely self starters.

And there are plenty of diploma mills that hand out degrees in IT like they're candy.

CVs are easy to bullshit as the OP points out and ascertaining performance on a technical interview comes at a high cost.

Search costs matter. Other than "I worked with this guy" (which doesnt scale) I dont know of a quicker method of uncovering an obviously decent programmer.

A lot of the best (technical-wise and ethic-wise) collaborators I've had had and have no public profile, some even not on LinkedIn. You won't find them there.

Having a decent profile is rare enough that it cant be your whole hiring pipeline but IMHO it's a great reason to let somebody skip an assessment stage or prioritize them for interview.

When you ask the candidate to see some code and they tell you every single thing is under NDA.

Brah, if you're a programmer, you have at least some tinker code lying around that you can show.

I am still a really good employee and I always get excellent performance reviews.

It probably won't have elaborate CI/CD tooling with a clear branching strategy.

It probably won't have a comprehensive test suite.

It probably won't have systematic error handling.

It probably won't have carefully written comments to help other people find their way around it.

Most important of all it probably won't be designed or cleaned up to the standards of good professional code, because I wrote it for fun or to solve some specific problem and not to be a portfolio piece and I stopped once the code had served its purpose.

If anyone I might work with insisted on judging me on code like that they'd never get a realistic view of my level.

If I wanted to show someone an example of code that did faithfully represent what I can do I'd want to show them some of the many projects I've completed to a high professional standard at work. But of course that code really is usually confidential and at least in my case that tends to be because it's important to the business and might not be public knowledge yet so it really would be very unprofessional if I went around handing it out to anyone who asked.

The only reason I have any open source code is because my company has a very easy open source process. I extract reusable non customer identifying code from projects and it usually takes at most 3 days for approval.

There is also a company sponsored open source project I contribute to.

This means working on open source, staying up to date with new technologies, learning interview techniques.

Everybody is entitled to a job but nobody is entitled to a fancy job.

Except most highly-compensated professional jobs don't expect people to get continuing education on their free time. The state bar and medical boards not to mention engineering certifications all require continuing education. Everyone I've known in those fields is paid for the continuing education credit time.

And then in the interview, I ask them to teach me how it works, what could be improved, etc. I might not know anything about it, but I can tell when someone's pretending to teach a thing.

Once had someone bring in a device driver in C for a JavaScript position. Now, I've never written a device driver, but I know the general concepts, and the applicant's description was cogent. They got the job, and they were a great hire.

The last interview I did, I was asked to find and fix a bug in a small code fragment. On my own, I'd have fixed it in a jiffy; with two interviewers looking over my shoulder I was nervous, and it took longer.

But if you're interviewing on the basis that the candidate claims in their resume to know language X, then a brief test of that is essential; and an online test doesn't cut the mustard - it could be anyone doing the work.

From the naive "GitHub profile is relevant" take, through the "a developer MUST know the ins-and-outs of their techs anytime or they're just not worth it", through the "code is the one thing that matters" (sheeesh...).

I would happily fail and laugh out from an interview with that kind of employer profile.

Some people think it's OK to ask the candidate to dedicate 2 hours, then send an automated email rejecting. I don't think this is polite, let alone respectful.

At least have the decency to dedicate 10 minutes to writing down three bullet points for why they were rejected.

There are differences between "code this weird thing on a whiteboard" and "show us some code that you're not terribly embarassed about" (instead of searching on github)...

I once got sent an automated email after applying to an org with a coding challenge before the first filter. Before even any recruiter/HM or anyone actually at the organization sent me an email acknowledging they received my application.

I initially bristled, and reached out to the generic "recruiting@" email that was present in the HackerRank email for the company, asking if I could at least have a screening call at minimum before committing time to a coding assessment.

They said no.

In the position of "needing work yesterday", I did the challenge.

And was promptly ghosted.

- Short and fully automated, for instance to skip an initial technical screening;

- Longer, but leading to a follow-up interview.

It's a tool, it can be misused. Be respectful and both parties can benefit from it.

It's like whiteboarding: I don't enjoy companies that expect me to have seen the problem already and regurgitate the answer, but it can be a pleasant experience too.

As the contrary. It's up to your options and your choices.

And that's irrelevant to your employment/work capacity.

A decent recruiter is aware of that. Others are optimizing for something else than a balanced contractual work relationship.