Resumes are dangerous? | Hacker News Reader

Resumes are dangerous?

blog.alexmaccaw.com

150 pointsallenleee295 comments

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, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly.

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.

You can do that or you could also put a readme on your GitHub that it's a place where you explore hobby projects and you are interested in "x, y, and z".

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

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

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

Giving as few reasons to deny your application before an interview just seems like good practice. The whole process is arbitrary anyway.

This depends on how many options you have. If you have many options it can be a good thing to filter out companies that would not be a good match for you.

As a general rule of thumb, if you don't want to be evaluated at least in part based on something, don't put it on your resume.

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

This strikes me as unnecessarily bitter and cynical. Application is a two way street. Would you even want to work for a company like that?

Not bitter at all, not sure where you got that impression from my post. If I have something that does not present me in my best light, why should I volunteer to show it in a hiring process? I am just being practical.

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.

A company doesn't necessarily begin and end with the person hiring.

Most people work where they find work, not where they want to work. It's less true in IT, but I'm still betting it's mostly true there

If they pay well – absolutely.

There are risks either way, and this is one of those processes where you just want a single good hit. So I guess the optimal course here is to maximize your risks (unless they are biased into not-hire), not to minimize them.

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.

Good point

What’s more common - hiring managers who see the inclusion of a GitHub as a small positive signal but don’t scrutinize heavily (or even more likely don’t bother to click into it), or those that dig deep and scrutinize open source contributions as a primary decision factor?

Or maybe the managers will decide to only interview people with a GitHub link?

Could go either way.

I've seen applicants with lots of Github repos, which all turn out to be forks, and all the applicant did was make a trivial change to the documentation (not fixing a technical error or expanding the comprehensiveness, but adding periods at the end of list items, capitalizing some proper noun that got missed, etc.)

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

Too bad, because "fixing a technical error or expanding the comprehensiveness" of existing documentation would be a very strong signal to hire!

Yeah, honestly seeing someone add a big chunk of fresh, useful information to a project's documentation would be even better than seeing code go in, because most people hate doing docs! Unfortunately what I've seen is absolute lowest-level "get a commit into the tree" stuff.

You mean, when it's meant to signal that a given person fixes every little thing they come across, and not 'hey, this guy contributes to LLVM!'

I didn't know why people fork repos arbitrarily on their GitHub. I thought they were doing that unnecessarily before cloning or something. So this is the reason?

No. The reason is because when I and others investigate some code we like to make small refactorings as we go along. Change a variable name here, redefine a type here, and see what breaks. If you think those changes could ever be pushed upstream you save them in a github repo. That it looks "random" to hiring managers is something I've never thought of.

We are talking about different repos then. The ones I am talking about have no commits or refactoring going on, usually they are even with upstream or some commits behind. I was puzzled why they were forking these repos while a git clone will perfectly do.

Maybe a location thing. I am from India.

Quite often people will fork so they can tinker locally. It's not odd to see forked repos without any changes, it's just someone being curious or wanting to make a contribution but not having time to go through with it.

I'm sure it's not the only reason. Maybe some people fork repos they depend on just in case the original owner decides to take theirs offline, etc.

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.

100% this. Show me you’re actually interested in this stuff.

I could show you, but my github account is not representative of my actual interests. That is precisely what resumes and motivation letters are for.

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.

I’ve been interviewing candidates for ~5y across two companies and have yet to see a motivational letter. And most the resumes I see are either overly verbose and don’t tell me what you actually did, or are simply a soup of buzzwords.

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.

Your example is excellent. I agree with you in that choosing a developer in basis to a github profile is not much different from choosing a handyman in basis to what he does in his garden on the mornings. What if there was a much cheaper and more efficient handyman living up the street, but he always works in his backyard so you have never seen him outside?

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

The soup of buzzwords is because of the shitty algorithm/outsource your org uses to pre-screen for candidates.

why do you care?

This was also my reaction, the way I write code when I have a 20 minutes of free time after work is really different from the way I write code for production. The author is lying to themselves if they think that most people Github projects are any more representative of the work they'll do once hired than their resume is.

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?"

I agree with the conversation starter part, but I think there's still something to be said for seeing how someone's code looks when they're writing it not-for-production.

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.

> other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used

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.

Okay, understandable. I do feel there's a pretty big difference between doing something a bit different for the sake of preference or taste or experimentation vs doing it because you just didn't know, or you don't have the familiarity with the ecosystem to even know what's out there. And this difference is usually fairly evident in the code itself.

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

This smells of career stage myopia.

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.

One of the nice things about open source, and modern development tools, is the ability to easily go beyond the documentation to explore the library code itself. While I wouldn't consider that as a substitute for implementing your own, it is another means of figuring out how a library works and can be seen as more results oriented. Yet it is nowhere near as interesting, in my opinion.

Imagine you’re hiring a structural engineer to work as part of a highly skilled team on a skyscraper project. They previously worked on a bunch of major building projects around the world.

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?

Sure. But not because you're expecting the treehouse to be at the caliber of a major building project. Rather because it's an opportunity to witness:

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

The difference with software is that you are not allowed to look at the skyscraper, because it is the intellectual property of another company.

So you're saying that, if skyscraper engineering designs were considered confidential and proprietary, preventing you from being able to directly investigate them, it would be perfectly reasonable to fall back to evaluating structural engineers for skyscraper projects on the basis of how well they put together treehouses?

Nah, you could just have them come and build something at your office while you watch them, and ask them leading questions when they get stuck.

I thought that the commenters who were sheepish about including their GH repo were being unreasonable until I read this comment. I could not disagree more about the purposes of side projects. In fact, if "reinventing the wheel where a well known library could have been used" is a deal breaker for people _in a side project_, I must be one of the least hire-able people on earth.

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.

I like re-implementing things too! But usually there's a pretty clear difference between "I'm doing this deliberately differently from established-solution X for reasons Y and Z" vs "I'm doing an unrelated task and am using urllib because I'm blindly copying in SO solutions from ten years ago and have never heard of Requests." This kind of thing is the fizzbuzz of ecosystem-awareness.

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

The thing is, reasons Y and Z for me very often are "because I want to". I don't even really want to fluff it up and call it something nauseating like "professional growth". I just followed my curiosity. My personal projects are a safe space from stiff professional judgement (or at least were).

You're my favourite kind of employee/colleague. Someone who knows something about what they're doing because they took it apart and put it back together.

Thank you fartcannon. May we hack into the long night

> like the person reinventing the wheel where a well known library could have been used

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.

I think it's a difference between: "reinventing the wheel because I didn't know better", and "reinventing the wheel because I feel like trying to make it better". There's usually a distinct difference in how the code shakes out between the two.

Overly long function names and lazy symbols, fair enough. Linter violations, Im not sure sure, standardised code style is most important when working in a team, working on your own it doesnt really matter as much, but fine. Lack of tests, theres no way I'm writing tests for a fun weekend project not meant for production. I'm not even sure I'd write tests for any project not meant for production or anyone elses uses (obviously what production is in that context differs, if your writing a library for dev tooling, their dev is your production).

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

> I'm not even sure I'd write tests for any project not meant for production or anyone else's use

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.

Yeh, that makes sense, I just doubt I'd even think to add unit tests for a quick and done project. Even if it did cross my mind, I think I'd just add exceptions and print statements. Its dirty, but its also very quick and painless.

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.

> 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

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

What if I wanted to reinvent the wheel to increase my knowledge?

Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.

> Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.

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.

Sure, if you don't want people to look at your code, don't make it public?

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.

And what if I’m not tracking that in such detail or even thinking about viewing it like that because it’s a side project?

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.

> And what if I’m not tracking that in such detail or even thinking about viewing it like that because it’s a side project?

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.

Why should I have to defend the imperfections of what I do for fun? I wasn't getting paid to make it good.

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.

> other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used

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

I don't even code professionally any more, but when I gin up some code to solve a problem for myself in 20 minutes, I'll definitely try to clean it up before I throw it up on GitHub. I don't get any competitive advantage or economic benefit from my code, so maybe it's different for me, but if somebody finds my stuff and wants to use it, I feel like it's basic courtesy to not hand them something I vomited onto the internet.

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 disagree but want to explain why.

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.

> Github projects are any more representative of the work

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.

I disagree profoundly with this assertion.

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.

When I see undocumented project that doesn't build, I know that the developer doesn't care about the quality of his work.

> They are, that's the moment you see how the person code when she/he is responsible

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.

So some people, when having full responsibility, produce poor quality products. You don't understand what it means? You prefer to live in denial?

If you don't have much to show on your GitHub profile, simply do not provide the URL. It's just one data points among others, but it's true that it's useful to see the candidate's coding skills in advance and the easiest for that is open source code (since anything else probably can't be shared).

+1. Additionally, in general, I personally prefer to keep work and leisure separate. Things that I bring to the awareness of potential / future employers are selected and curated, and distinct from places where I keep the half-baked stuff I do for fun for my own consumption.

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.

> it's useful to see the candidate's coding skills in advance

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.

That's what pinned repositories are for. It's your opportunity to highlight the projects you're actually proud of. Any half-reasonable prospective employer will look at those first, and probably only those.

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

I've googled people's names + github if their GH wasn't provided, just out of curiosity.

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

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 my Github too

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.

Why should some specific people (employers, recruiters in this case) should have a relevant authority as to pretense what a GitHub is supposed to be for.

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

Use github for what you want. However, when you put the link on your CV, you chose to use it as a portfolio.

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

If you put the link on the CV, sure, you just assume that it may be relevant to your profile.

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.

As an employer that does the same thing as the person who wrote the article; I do, of course, look at the seriousness of whatever is on that Github profile.

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.

Could you list some things that are red/green flags when perusing someone's public code/projects?

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!

Just a few things I usually notice when going through a potential hire's GitHub:

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.

> GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.

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.

That's a good point, but it does raise the question of how best to transmit notes or information with anyone who stumbles on the repo. I understand these platform-specific features to be a way to show you do your homework and can integrate third party tooling or workflows into your own things.

Adding a README.md isn't just GitHub specific, it's a good idea to add it to any project you do.

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

This is true, README has a long history.

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)

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

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.

I mostly interact with github via a standard git cli, which does NOT bug me about it.

Which is something I would think someone who assesses people based on how much they know Github.....should probably know

How ironic ;)

Your points make sense and they're on The Checklist, thanks! I probably won't sweat CI/CD integration for the demo yet but ship (as the other commenter mentionned, also thanks!) something readable, mostly testable and usable (but limited) on day 0 and go from there.

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

You don't have to go whole-hog on CI or anything, but GitHub Actions is pretty easy to just knock together a thing that runs `make test` or equivalent.

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

Honest question: If someone uses, for example, sr.ht, will you scrutinize it as much as a Github project? Would you check out the project and look for its equivalent of GH actions?

To be honest I've never seen a single project on sr.ht :)

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

These are some very low bars for a project to pass.

It is the point though. My public github projects are either empty (i pushed nothing cause everything was bad) or are half-baked projects. They would still pass those bars, which i can feel gratefull for.

For me, there are no "red" flags when looking at someone's public code.

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.

As a programmer (with a busy professional and personal life), I don't really care for the fact that it's like this but I acknowledge that it is and I also understand that it can be a strong signal in the right hands.

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.

In the Soul of a New Machine Tracy Kidder relates how toward the end of the development of the Nova that Data General started rejecting applicants who had anything computer related as a hobby or spare time interest. If memory serves, they believed on the basis of experience that people with a broader range of interests were better team players and more resilient to burn out.

While this may be technically accurate, the rest of the descriptions on how they interviewed & hired was brutally narrow-minded and biased. You're missing the part where they basically didn't hire anyone with a life outside of computing because you were being hired for an all-consuming death march.

No, I didn't miss that point. That was the reason they finally changed their opinion.

So don't put your github URL in your resume? If you don't want a potential employer to look at something and judge your ability based on it, it doesn't belong in your resume.

Lots of resume aggregators and ATS require or at least present a Github URL field whether you like it or not.

In such cases, I stick with the tried-and-true 'N/A'. I still get offers, so it doesn't auto-delete my application!

Please don't delete your GitHub account because of this one person's article. I have interviewed over a hundred of developers over the years, and I have actually adopted the habit of _not_ looking at their GitHub profile because I find them to be very non-representative of the person's skills and abilities 9 times out of 10. The article isn't bad, by the way, and OP is making very true points, most prominently that resumes are mostly bullshit and shouldn't be relied upon by themselves, but that's what the interview process is for.

If all a person has to evaluate me on is public Github contributions, it'll seem like I only work one day every 3 years or so. With all the other things I do with my life (sport, art, socialising), I very rarely have any time (or motivation) to program in my free-time. Having all of these "extra-curricular" activities is probably good for my mental health and makes me a better engineer than I would otherwise be if I spent all my time both at work and in my own time working on software.

Agree. I do have a GitHub account, but I do not link it in my CV (nor I link my personal website).

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.

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

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

Private repos are great for those half-baked projects you don't want people to see.

I think this is forcing me to choose between two evils - do I want to look like I can only write half baked weekend projects, or do I want to look like I don’t write any code in my free time at all?

Fair point, for me its the latter. I cant put on my CV brief descriptions of side projects I'm working on, during an interview I can give more details on those, etc... Still not ideal because they'd probably want to see the code, but its the lesser of two evils for me

I'm never going to work for a company whose hiring managers require me to post hobby projects on Github.

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.

That is one person so I would not read too much into it.

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.

This.

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"

Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for? That stuff normally does not need to leave your local harddisk. Maybe exceptionally, if you want to explicitly share it with someone you have been discussing it with.

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.

I publish as much as I can, and deliberately so. Not so much for internet points but because:

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

> Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for?

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

> Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for? That stuff normally does not need to leave your local harddisk. Maybe exceptionally, if you want to explicitly share it with someone you have been discussing it with.

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?"

Thanks for the answers, everybody. I guess I am the weird one, as I still think it's mostly just adding useless noise to an already noisy public web, and therefore kind of rude.

Your initial comment really annoyed me (and it shouldn't have), that's why I was hostile.

But your followup shows you to be a gracious person who was just curious. I'm glad we got to swap ideas

That's a strange thing to do, in my opinion. That makes me want to put my Github (which is half half-baked nonsense, including this stupid `hello.S` from when I was barely learning amd64) on the resume. I do anyway, but it is now a reason to double down.

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.

I do not want a future employer judging me on the basis of the half-finished amateurish experiments

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

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

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

He's talking about the case where the applicant explicitly provides a github link in their resume or profile. In that case, they could have been expected to pin their favorite projects or remove the ones they don't want seen. Plus they are merely suggesting it be used as a jumping off point for conversation with the candidate.

A good employer will not judge you based on your half-completed personal work. The point isn't to see perfectly executed programs, it's to get a sense for the kind of interests this person has. Seeing a couple half-finished Go projects is better than seeing nothing at all.

Also, my public repos are all code I've done before I started working. My code has improved a lot since I've been coding every day for my job but it's all private.

Perhaps consider a personal account and a professional account.

Only put your best work on the professional one.

unless they changed it githubs terms of service do not allow multiple accounts. you'd have to split them over multiple hosting services, which, depending on the project, may not always be practical or possible

Why include your Github URL then if you think its only awful code?

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.

Has GitHub introduced some “showcase” feature, because this is the first time I’ve heard that a normal public repository should be a treated as a showcase.

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?

> Has GitHub introduced some “showcase” feature, ...

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

GitHub is not a portfolio website. It's a code sharing platform.

Too many people here are crowing about the GitHub thing, and not enough about:

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

well it depends whether you hire a junior or a senior position.

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.

Totally agree on jr vs sr. Another point that is conveniently overlooked in the article so the author can have his holier-than-thou moment. It seems he's hiring seniors, and only wants stars.

"Programming" isn't a monoculture. People can be "better" than others in multiple ways.

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

Not the author, but . . .

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.

*I'm only upvoting this article in hopes that people will read the comment section.*

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

Yep, fully agree.

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.

The nice thing about this method of hiring is that I probably wouldn't want to work for a company that trusts someone with such silly biases to pick candidates anyway. The code I write and push to my self-hosted Gitlab is none of your concern.

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?)

>The code I write and push to my self-hosted Gitlab is none of your concern.

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.

> I probably wouldn't want to work for a company that trusts someone with such silly biases to pick candidates anyway

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.

> The code I write and push to my self-hosted Gitlab is none of your concern.

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

But I do think intellectual property laws need to change.

> Then, come the interview, the guy can barely code, much less know the ins and outs of variable scope. It turns out there is very little correlation between how good a resume is, and how the interview actually pans out.

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.

I wonder if that's why I tend to do better at job interviews with a mild bit of entheogens in me.

Huge problem with this, apart from not everyone has a GitHub, is that code and expertise are not the same thing.

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.

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

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

As a hiring manager for a tech startup, I find resumes useful as a filter.

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.

I generally want to find people who have done more than just CRUD UIs..

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.

This is horrifying to read. So much bias...

I think the only really uncommon thing here is that they're spending a full 15 seconds per resume. :)

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

Why don't you have a recruiter paring down the number of resumes dramatically so that you can actually give each one that passes that review adequate reading?

1. Recruiters are expensive. 2. It's hard to find a recruiter who doesn't increase your incoming resume volume without a corresponding increase on quality or fit. As far as I can tell recruitment has settled into a stable equilibrium of being a volume game.

Tell me one you find horrifying and I'll explain the rationale for doing it.

The Fortune 500 one is a bit disconcerting. I know there are a lot of Fortune 500 developers that would not fit well in a startup, but there are plenty of interesting projects within many Fortune 500s where you would find great developers who would be great startup employees. You do say that you look for something else that catches your eye... but its hard to know what that may be and is probably a lot of chance.

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

The fortune 500 one I qualified (as I mentioned to a couple other people who objected to this.) I understand why it's disconcerting, but in my position (small startup, small team, need to not waste 3-6 months on a bad hire) I need to increase my chances for a successful hire. Lots of bigcorp devs are used to having everything laid out for them. Early stage startups are unlikely to give the same structure.

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

At least at my current job at a "boring" Fortune 500, we don't work that way at all. I'm sure there are plenty that do though. I guess if you are getting enough hires using your current system, there is certainly no reason to change it.

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.

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.

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?"

What kind of projects are the people you hire working on, and is it more than just CRUD UIs?

Everyone is biased, they just happen to be a little bit more upfront about it.

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.

What is so horrifying? He's hiring startup developers who need self-direction.

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.

He's flat out rejecting people for corporate experience. You don't know the reasons people take jobs or why they're looking for a change.

I qualified that by "over and over again" and "first half of first page". If you're switching from nothing but bigcorps to startups, you need to give me something on the resume to make me think that you can adapt to the cultural change.

it also depends on the companies. where i am now, big corporations work their engineers to exhaustion and teach them a very competitive attitude. that's not something i want in my small company. i need cooperation and mutual support, where developers back each other up and not try to gain favors with their manager at the expense of their teammates.

>If I see health insurer, big insurance, blah fortune 500 firm, government contractor, ... over and over again

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?

Not to mention there's a regional bias here. There are plenty places around the continent that just don't have many cool "startup" type jobs. (Or if they do there's a feeding frenzy for them because everything else in the area is insurance/finance, etc.)

I'm aware of that, and have done a lot of hiring from the midwest, fwiw. I've been in a position where I don't have a ton of time for mentoring, so I tend to hire senior engineers who are used to running with looser requirements than they may get from a bigcorp, and don't mind juggling a main project with a small backlog of cleanup or bugfixes. I learned this filter after not doing it, and having candidates used to a more structured environment flail. That said, like I mentioned originally, if you can demonstrate in your resume (perhaps even with a "What I'm looking for" section) that you have the skills necessary to thrive, I'll overlook this point.

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.

> 3-4 page resumes

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.

I once had a candidate submit a 20 page(!) resume. They were so full of themselves. That one I actually did spend 5 minutes with to see what they found so fascinating about their history, but it was otherwise an instant reject.

A 20-page resume bespeaks someone inexperienced in job applications.

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.

That may be a cultural/experiential difference. You may not be familiar with CVs as opposed to resumes.

Was it this guy? - https://en.wikipedia.org/wiki/Impossible_Is_Nothing_(video_r...

In some industries (or academia) a 20 page resume listing every project, publication, patent, etc. is considered normal and desirable. If could be that case.

I feel like one page is enough unless you have a truly remarkable career. At this point my earliest roles just don’t earn their keep; no one cares any more that I was a Micro Computer Support Specialist in undergrad.

all right, i am guilty of that. my resume has 5 pages, but it is split up in clear sections that i can easily remove if appropriate:

    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)

so technically, you could stop reading after page 2. and only scan the rest if you want more details.

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)

From what I've seen, a few things that could be helpful are:

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

> do you think it would be better to just skip the project list?

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.

well, the first page is more or less the cover letter. and i do adapt that depending on the job.

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.

> skills (that's the list of all tech i ever worked with. just the names, no details. only the most important ones are bold.)

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.

I spent 30 seconds reading your message here and another 30 seconds in this response. You sound like a plain awful manager.

"first thing I look for in a resume is a GitHub URL"

Ah yes, gatekeeping at its best.

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

It can be worse. As I understand it, this person just wants to see code. I'd imagine that sending a zip file, or express willingness to do some small assignment would suffice too.

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.

And here I thought I was the only one. Glad I'm not the only one without a LinkedIn profile.

Honestly I'm not sure you need one for programming. In accounting it's kind of required.

Wow, that's awful! What a thoughtless requirement. On the other hand, it's helpful of them to filter themselves out of consideration so quickly. Who'd want to work at a place like that?

It doesn't have to be a real-world open source project.

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

Some employment contracts claim ownership of anything you create even outside of working hours, so even publishing those little learning projects could potentially be problematic.

This is another problem.

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.

Some exceptions would be if it conflicts with their products

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.

How are those legal anywhere? Thankfully they aren't here in France.

Even if it's not legal, I'm not going to sue my employer to stake ownership over an evening project.

You don't need ownership here, just authorship.

Even if they're not likely to win in a court battle, most people don't want to risk a dispute over something trivial.

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

https://www.joelonsoftware.com/2016/12/09/developers-side-pr...

American exceptionalism at its finest.

My employer doesn't allow publishing code that was written during working hours.

Why would you publish code that was written during working hours?

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 think some of my university projects are published. But they're quite old by now, and not representative of the production code I write. I do learning exercises quite frequently when getting into new libraries/frameworks/languages, but again, that's on company time.

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.

I publish practically everything I write in my free time, whether it goes anywhere or not, but I would never link to that playground on my resume!

tbh would prefer someone look at my code instead of some leetcode test.

I see this attitude everywhere and I swear it makes no sense at all. Interviewing and selecting and hiring candidates is gatekeeping. Thats literally all it is.

I guess the implication is that it's elitist or somehow unfair gatekeeping?

If you ask the question "is it a more elitist form than gatekeeping than looking at your fancy university credentials or experience at a FAANG?" then I think it's not so much.

IME it's less time consuming than leetcode and take home projects and about 1000 times less soul sucking than both.

It's not unfair gatekeeping, it's incredibly dumb gatekeeping. You're definitely going to miss out on interviewing good candidates.

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.

Point me to a metric that you think is fair and it would probably take me 10 minutes to systematically demolish it as equally stupid gatekeeping.

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.

For sure, but I cant really think of another low friction way to detect high quality candidates.

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.

Search costs matter, and GitHub browsing is low friction, but extremely low signal on a very narrow bandwidth.

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.

shrug this is the exact opposite of my experience. All the really great people I've worked with have had at least something there and I've never worked with somebody with a great github profile that wasnt also a great programmer.

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.

You know what kills an interview really fast?

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.

The point is that you might not want to show toy code. Toy code I've written for fun is rarely written to the same standards I'd use for anything important, including code written for work.

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.

I don't... I haven't written any code outside of my 9-5 job since I graduated from college almost 20 years ago.

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

I haven’t written a single piece of code outside of work since I started working - in 1996.

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.

The only thing I have is project Euler in haskell. What insights will you get about that corporate java job

If you're slinging Euler in Haskell, the insight is that you're probably overqualified for most corporate java jobs.

That you can write code. That's a positive signal. There's a reason FizzBuzz exists.

If that were even remotely true then almost no Apple employee would ever manage to find another job.

Software engineering is a highly-compensated professional job. It’s a given with such jobs that professionals are expected to spend some of their free time on their own career development.

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.

> a highly-compensated professional job. It’s a given with such jobs that professionals are expected to spend some of their free time on their own career development.

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 not everybody (as a personal statement from me) is at all interested in a "fancy" job...

Of course a resume could be full of lies. That's why nobody hires blindly based on the resume but always has an actual interview. During the interview, talking about code, you'll notice soon enough whether the candidate knows what they're talking about. And that doesn't have to be (whiteboard) coding challenges or questions about obscure language details. Just talk about how they code, what coding style they prefer, how they organise their code, etc.

I've found this works to great effect. I ask the prospective interviewee ahead of time for an example of some code they wrote that they're proud of.

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.

Not sure what a "whiteboard" coding challenge is.

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.

A Whiteboard coding challenge is the exact thing you describe. But instead of interviewers looking over your shoulder, they look at the whiteboard as you stand in front of them and write code on the whiteboard.

The whole article gives a strong "never work with this type of person" vibe, with a big NO to their own 3 closing questions.

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.

It's an interesting duality of engineers - love the coding challenges when they are the ones evaluating, while refuse to do them themselves :)

I'm usually open to coding challenges when the challenger is going to dedicate at least 10% of the time I've put for a feedback.

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.

You even get a rejection email?

We once asked someone for some sample code. Anything they'd done at university really. Let me tell you, the whole team had no idea that you could actually run Python code with such a formatting of tabs and spaces and whatnot, being a white space sensitive language and all. With all goodwill this still looked like someones first program that accidentally ran after fixing the interpreter/compiler errors. Imagine a printed out cover letter but you fixed the typo in your last name with a sharpie and it had coffee stains on them.

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

People use the take home tests the wrong way. They should be sent to a small number of candidates that are close to the final stage. But most people send them after the first filter. Then they waste both candidates’ and their time and also spend zero time to send any valuable feedback since the pool of candidates is big at that point. And this creates a frustration to experienced engineers not wanting to spend any time on such a process.

> But most people send them after the first filter.

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.

I really like coding challenges when they're done in a productive way:

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

I think (moderately difficult) coding tests are a great tool since they establish a clear, and mostly objective benchmark for performance, which is hard to fake. While they certainly don't give you a complete picture, I think they are one of the most efficient tools for establishing a base line of competence with regards to both the interviewers and interviewees time.

Resumes are not as dangerous as technical tests. 90% of top companies have terrible technical tests which select mediocre candidates and pass up on excellent candidates.

Technical tests with time limits are the worst; this is in part because if the candidate doing the test is more skilled than the engineers who designed the test, the candidate might take longer than anticipated to complete the task because they've thought to do some additional sub-tasks which the people who designed the test did not anticipate and which they would not appreciate or understand. For example, extra logic related to error handling and security will take more time to implement but are critical in evaluating a developer's skill level.

It's happened to me multiple times that I did a test but could not complete it within the allocated time. Then explaining to the engineers why it took longer to complete just doesn't register because they don't seem to understand how important this error handling logic is or why it's important to reset the state of the system between each test case.

I usually don't insist much because if they are like this during the interview process, I can be sure that they will be even worse if I start working there. It's sad because many of these jobs are highly paid and would provide credibility on the resume - At least until the industry figures out that the financial success of a company is usually not correlated with tech talent; certainly not the kinds of companies which solve every problem by throwing 100 engineers at it... That's just brute force; it doesn't require much skill.

Another issue with technical tests is that some developers with a background at a famous SV company will expect you to do things a certain, very specific way (based on how the famous company did it) and not realize (due to lack of other industry experience) that there are multiple valid ways to achieve the same (or better) results for the specific use case which is being discussed. They are overfitted to their past role at the famous company.

> ... 90% of top companies have terrible technical tests which select mediocre candidates and pass up on excellent candidates.

This is one of the confusing parts of interviews. They are not necessarily designed to select the best candidate, but rather the least risky candidate.

It is quite possible to have a technically excellent candidate who would be a very risky hire and the interview process is set up to avoid hiring that candidate.

This sounds like kicking the can down the road because the quality of technical tests seems to keep getting worse each year. All these supposedly low-risk hires have caused the quality of engineering to decline over the years which caused a decline in the hiring process which creates a vicious cycle. The risk actually builds up in the long run. It's not surprising why security is becoming such a big issue for big companies nowadays.

If you always hire below your current level of talent (I.e. the apparent 'safe zone'), overall talent will keep declining.

Unfortunately, developers in many companies feel uncomfortable hiring people who might be more skilled than them because they don't want to risk being displaced from their current position or introduce more competition for future promotions. I've seen it happen from the other side where I gave my approval for a candidate who was very good but they were rejected in favor of a different candidate who was below average. It was obvious that the second one was not as good but I suspect that my colleagues may have felt threatened by the first one.

I see a lot of comments here deriding githubs, but what if you’re breaking into the industry? Surely in this case its a good thing to have a github link on your resume? For me, being one of those people trying to break into tech, I curate my github with projects, whether success or failure, to show the sum of my own initiative and research, whether borrowing code structure from a given online course for a bigger project, or practicing a concept on my own (I got much better at this recently). While I may not have a degree or previous work experience, I think my github can be a useful indicator for a prospective employer; whether I’m at a place they are fine with and/or I’ll be someone they could get up to speed with if need be. Maybe I’m wrong…

This'll probably get me downvoted but I suspect the comments come from a position of insecurity as older tech people with kids and without much spare time are afraid a line on their CV might not be competitive with 20 somethings with a shiny github profile.

There's part of that, and that's a good thing: having kids, not having much spare time for work-related stuff _is a good thing_.

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.

it's entirely irrelevant to work capacity. It's a popular thing to look for because where it does exist and is good it's a strong hard-to-bullshit signal of a good developer.

That doesnt mean that the candidates who dont have it arent equally good. It just means that you cant easily tell it without investing resources into interviewing them and others who look as good as them.

People "without much spare time" are actually fine. Their github profile is actually empty or non-existent. So, this whole thing is not threat to them at all. OP will continue to read their CV without finding something bad on github.

But, people who do use github a lot as a place to mess in are threatened.

I have these things called hobbies and a life outside of coding. When I was single, my hobby was teaching fitness classes, personal training, weightlifting and running.

Coding has merely been a method to turn labor into money to support my addiction to food and shelter for over 25 years.

Whats more absurd is I may end up like these people rather soon since I’m a 30 something :)

There is difference between judging people based on what they claim to be their portfolio and based on everything they have on github. What you describe sounds like a portfolio.

But for many people, their github is more of free backup space. They dont curate it. The whole "stop reading what they done seriously and look only at what is in their github" is the issue.

Oh, I have a portfolio too, which is a distillation of the “complete” (enough), mostly front end projects I’ve worked on. My github has those as well as attempts at fullstack projects for whom I get hung up with affordably and practically hosting… I think both can help create a picture of where someone is.

The person that wrote this won’t hire anyone unless they are better than themselves. So only experienced and top notch candidates will be hired. I find the criteria stated to be more about an ideal hire rather than a typical hire. Pie in the sky expectations that do not really provide much insight into general hiring in my opinion.

And that's perfectly fine.

The issue is to set/have the expectation that necessarily "github = portfolio" and "no github or messy github" = not a good fit" and that candidates not fullfiling this expectation would not be relevant.

I wouldn't call them "dangerous," per se, but they are mostly done to fool AI screeners, these days, and are nothing more than a few data points and buzzwords.

> 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, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly.

My experience, is that interviewers don't look at this stuff at all. It's downright crazy. Instead, they rely on leetcode tests.

These are short, academic tests, using algorithms that are seldom seen IRL (I have been coding for over thirty years, and have never seen one single binary tree. I've seen one or two roughly similar structures in some image processing algorithms, but only in a couple of ones that weren't very performant, and we ended up removing these).

But they can be practiced, and are quite familiar to folks just barely out of college.

I've not bothered to practice these. I can do OK on them (they are usually just common sense exercises), but some kid that has spent most of the last month (of their current employer's time) practicing these, will absolutely kick my ass. It's not worth it.

Also, I have noticed that interviewers are looking for rote answers, which also applies to more practical exercises, like take-home tests. They don't like unusual approaches. They are controlling for conformity. That's interesting, as some of the companies doing this, are crowing about "disruption."

> "Then, come the interview, the guy can barely code, much less know the ins and outs of variable scope. It turns out there is very little correlation between how good a resume is, and how the interview actually pans out."

I think that this is more of an argument about how inaccurate and dangerous interviews can be compared to how dangerous resumes are. You can practice interviews and get better without actually becoming a better developer. Same with algorithmic coding tests. Developers who are happily employed rarely get to practice interviews.

I'll second this.

It is more likely the interviewer has misjudged the ability of the candidate for any one of myriads of potential reasons in the interview proper, than that the resume was somehow deceptive.

There's like half a century of IO psych literature showing resumes to be very poor predictor of job performance. Good to see this guy's own experience confirms what everyone (besides managers) already knew.

I prefer to ask the applicant to either submit code that they are proud of, or to do a small toy problem if they don't have anything they can readily share. Then we talk through their code during the interview, asking them questions like: what problem were you trying to solve, did you solve it, what problems did you run into along the way, how would you design this code differently, and of course any specific questions if we find glaring technical issues in their code.

I've found this approach to have a very high signal-to-noise ratio as it's virtually impossible for someone to talk at depth about their code if they don't know what they're doing. Also, you can't study for this type of interview, so you can't game the system.

I had an interview where this was the case. I had a bit of code I was very proud of and had fun writing. It wasn't more than 75 or so lines. This was the best interview since it allowed me to share a related interest of mine through the code sample I brought.

"The interviews are spent discussing code, and writing code. It's what we programmers do day in, day out. It's the one things that matters." - very true. That's also literally the idea behind interviewing.io and similar platforms that have been making this point for years* - so they get to coding with the candidate as quickly as possible. Maximizes information for both the hiring manager and the candidate on whether they want to work together.

* https://blog.interviewing.io/resumes-suck-heres-the-data/

I saw something here a few days ago in about "reading code for an interview". We were in the middle of hiring. And I decided to give it a shot.

It was eye opening.

Our stack is Elixir and I made the programmer tell me what a few functions were doing line by line and he aced it. I'm hiring him. (He does not know Elixir).

This is completely right. Resume's are a waste of time. They don't tell you about any of the capabilities of the candidate. If anything some candidates are smart enough to make a really beautiful resume to fool you.

I think the best alternative to the Resume is Q&A. I think job applications should include a long list of questions to get specific information from the candidate, which would (for example) show how much they know about coding, about working with peers, about what kind of company values they care about (if any).

Of course, filling out the same hundred questions for every job would be terrible. So there should be a website that collects all the questions and lets you resend them to each employer, and lets the employer pick which questions they require and which they don't.

The employer could also fill out questions from candidates, because the candidate should have a lot of questions for the employer. Candidate should be able to select the questions they want answers to.

If both candidate and employer answer questions, an algorithm should automatically sort for which candidate and employer had the same questions, and (assuming multiple choice and weight/priority) which answers were the same or closest. In this way you could simply fill out questions and immediately find the job that matches you best, and the employers could find the candidates that match them best.

> Of course, filling out the same hundred questions for every job would be terrible. So there should be a website that collects all the questions and lets you resend them to each employer, and lets the employer pick which questions they require and which they don't.

This is what I did with Obsidian.md, any questions for the applications will be copied and pasted to Obsidian with my answers. If I come across a different applications that have similar question, I look up in Obsidian and use my answer from there with small modification of my answer to fit their culture or mission statement.

It helps a lot because often the company I applied for usually asked for Cover Letter. Obsidian.md have my cover letters for various companies I applied for and it is easy to look back to those and find the one that fits best or create a new entry with a copy of the previous letter and modify it from there.

Would this just create a market for answers to the most common questions found at the large companies?

I don't think so. There are so many roles at a company, and each one could have potentially hundreds of questions, and each team might be looking for different answers. Select between 4 answers, add a 6-degree weight, plus additional comments for each answer. For 100 questions, that's hundreds of millions of possible combinations. And many of the questions should be subjective or based on personal experience, so that you can find the person who matches what the team cares about. If you see two people with the same answers, it would be almost impossible for them not to have been copied.

I guess the challenge would be to get companies to create good questions. A giant pool of community-curated questions for companies to start with would be good, and they should add questions from the team looking to hire.

My biggest takeaway from this article: this is why I deleted all of those projects from github never to be seen again (prior to private repositories).... the projects where I was just having fun for once and learning instead of being stuck in analysis paralysis and trying to think about 85 different OWASP recommendations at once.

My biggest takeaway from the comment section: thank god that there are more reasonable people than I first assumed.

I have an idea for a hobby/fun webapp I could build that maybe one or two people I know might get use from.... and I'm excited just thinking about it because its going to be low stress and a fun learning experience. Thats what my personal github is. I don't put the link on my resume and I don't really have a desire to either.

Hiring people comes with a high degree of risk. That is why you have a probation. Reading code is also risky. I usually forget why I did what I did and more often than I would like to admit the BLAME is mine - a resignated "..who wrote this?" often turns into - a-ha, it was me.

Resumes is good in the same way grades are good. They might get you to the interview, so don't knock it down just yet.

The hard skills are absolutely important! But the soft skills are equally so. When you talk to your candidate your first impression will be the most important indicator on wheter you will be able to endure working on varieties of task in the immediate future and far away future.

My favorite soft metric is to take them to lunch and observe how we can interact, talk and <sic> hygiene.

I think more organizations should have candidates (especially senior ones) give a job talk. It's standard practice in academia, but academic job talks tend to be overly long and high-stakes; basically an hour-long lecture about one's research. An industry job talk could just be a 15-minute presentation about a technical topic of the candidate's choosing, followed by Q&A. The candidate has full control over what the topic is, and the audience (i.e., the hiring panel) gets a good feel for that person's interests, communication skills, and soft skills.

This is what my company is currently doing. First step after a screener call is a 45 minute meeting with the hiring panel to present anything the candidate wishes - some presentations try to fill the full time, some are brief and there's more discussion.

We started doing this to get rid of the repetitive background summary the candidate has to give with each member of the hiring team in 1:1s. Overall, I think it's working well, and wish that places I was interviewing for myself would follow a similar process rather than multiple hours of 1:1 before a tech screen.

>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, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly.

We get well over 500 applicants per role. It’s absolutely unreasonable to ask our hiring teams to go through the applicants githubs

Much fewer than 500 would be left after the initial screening I would hope.

Finally the tables turn! Engineers cry "hiring is broken!" not undestanding the game is not optimized for the candidate. The OP: "Resumes are dangerous!" not understanding they're a gate-keeping mechanism that's gamed to get an interview. They were never intended to provide the interviewer with a complete representation & background material. That paper rockstar got an interview; would you have given them one otherwise?

This explains a lot about the state of the industry and why so many good developers have a hard time finding a job. This article does everything except consider the possibility that maybe, management uses the wrong metrics to determine the usefulness of a candidate and that resumes are flawed to the extent that you can't describe a humans experience on one side of one sheet of paper.

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

Many others have commented on this line so just throwing in my opinion.

I have long wondered if my lack of having public code on GitHUb has been an issue with getting hired. (Not that I really have issues, but you have to wonder what opportunities you did not get).

My lack of any code isn't out of a lack of love of coding (I in fact do, I have a few personal projects I have just never chosen to open source them... largely because I know that I made some questionable decisions since I had no code review). I also struggle with getting into working with other projects, not necessarily out of a lack of desire but it just feels daunting.

I do truly understand the desire for this, but if this is something the hiring manager was looking for... I would hope that once they do hire someone they encourage them to open source some of what they are working on or contribute to projects while working.

You don't need to open source your code to publish it on GitHub. You can just put the code there in a public repository, but not put an open source license for it.

The code remains your copyright and no one else has a license to use it.

Wouldn't hurt adding a (2012) to the title.

(Or editorializing to add an accented-e. I honestly thought I was about to read a story about resuming some process after it was interrupted!)

2012 with 2012 logic

A couple hiring managers and recruiters here still do it, thats cute

One things thats changed since 2012 are that private github repos are free

Every time something like this gets posted and even so much as mentions that they look at your GitHub, people come out of the woodwork with their fists clenched an impotent rage.

In the time that I've worked as a interviewer for some of the companies that I was employed at, if somebody includes a good hub link I always make sure to check it out. I'm not looking for necessarily best practices or the exact way that you code, but sometimes people put their personal projects on there which to me shows passion for software development, as well as the exploration of new ideas.

So sure, if your GitHub is just filled with half finished tutorials and unintentionally miss clicked forks, any interviewer worth their salt is going to notice this and then discard it as a signal.

If 90% of the people on hacker news had their way, We would discount any possible means of evaluation and just hire somebody by rolling a D20.

Mostly, resumes I see are just... lifeless.

A list of places you have worked, with dates, and names of systems or applications that will mean nothing to me, and the technologies upon which they were built.

A resume like that tells me nothing more or less than that you have remained employed as a programmer for X years.

I am usually sifting through multiple such resumes, all of which tell me that these candidates are... yup, definitely programmers. They have programmed stuff.

Please, when writing your resume, try to add one thing to each of the date-range jobs that you list:

Tell me how you grew and developed in that time.

Just a couple of sentences highlighting the main things you learned as part of that role. Why do you consider yourself a better, more hireable person now, than you were before you did that job?

That is worth so much more to me than exactly which version of .net that particular SaaS billing platform was built in.

As someone who was in college very recently - this is exactly what they tell you to do, at least at my college and with all the new grad resumes I've looked at as well. It's unfortunate.

This article is talking about seeing only aspect of the interviewee. In my opinion, although coding capability is obviously required, there are so many aspects of an individual that needs to be seen before they can be hired.

Also, Github is not the only code repository in the world!

I dont understand the point of these blog posts. Is he trying to say this is how everyone should hire? Because if we all only hired based on "would I want this person to be my boss" or "is this person smarter than me" then no one would ever get their first job in the industry.

I cant help but feel like this isnt even how this guy actually hires. This feels like a post intended to gain linkedin clout or something.

Edit:

I feel like it's worth noting that this guy is "Chairman of the Board" at his company and previously "CEO." So his expectation is that everyone he hires who is presumably paid less than him be more talented than him. What does he think this blog post communicates to potential hires?

"Tell me a story of when you solved a difficult bug."

"Tell me about a time you found yourself in conflict with your coworkers."

These two questions, in the hands of a skillful interviewer and interviewee, will get you all the info you need.

Resumes are dangerous, agreed - but only if you give them enough power to be dangerous.

The point is, resumes should only open the door to live interviews and be very rough notes about what a person can do. You always need a way to test what the candidate claims.

I'm not sure if this is obvious, but I work in the loan underwriting space now and any piece of data that the clients have the ability to control, we take but we must verify with other pieces of data that the client doesn't have access to manipulate. i.e. Accounting software like Xero needs to be back with bank transfer data.

Seems like a prudent route with resumes.

>Surely resumes are the only way to deal with the volume of job requests some companies get?

This is partly true. It is truly shocking to me how many resumes has spelling and grammatical errors. If there is one single document you will ever write that must be spelling and grammar error free, it is your resume. As soon as I come across a single spelling or grammar error in a resume, it immediately gets trashed. I don't care how good a programmer your are, details matter. If you are going to be sloppy with your resume, you are going to be sloppy with the company's code.

> It is truly shocking to me how many resumes has spelling and grammatical errors

fortunately i am at a place in my career where i can safely count that as a bullet dodged and move on. for my part i make a particular point of ignoring irrelevant spelling and grammatical errors (especially the latter, because not only does it discriminate against non-native speakers, but even among native speakers "correct grammar" depends strongly on your primary dialect of english, which may not be the same as that of the candidate), as long as the resume itself is clear and unambiguous.

> I don't care how good a programmer your are, details matter.

How do you know I didn't do that on purpose? ;-)

But, I don't care about your spelling and grammar mistakes in emails and slack messages (and hacker news comments) after you are hired. Its just on your resume where it matters.

I just assume anything I do will be seen as a negative. Don't list a GitHub - negative. List the Github - they assume that's my top quality code and that it wasn't mostly written 8-10 years ago.

Resumes are mostly useless in tech. Juniors have too little of note to put on them and Seniors only need to demonstrate enough experience to get a tech screen given the severe shortage in talent. Filtering out someone because they didn’t put enough time into their resume is silly. It’s even more silly when that resume may be a scrape from LinkedIn and may not even be provided by a first party.

> Would I want this person to be my boss? Would I learn a significant amount from him or her? What if this person went to work for our competition?

Sincere question I would have is, people who work at companies with intense vetting processes to find just the right person, fire fast, and avoid bad hires at all costs - how is that going? You're in, do you see yourself still there in 3 years?

resumes can be full of lies, github profile as well. that is why you have an conversation (interview) with the candidate and get to know them.

People keep saying that, but I have never encountered an untruthful resume.

Fraud is a crime.

People that lie on their Résumé's, may also lie on their Github profiles... but that's admittedly a bit harder to fake

It's pretty easy to grab some open source project from Gitlab, alter the commit history to pretend it's all you who wrote it and uploading it to Github. You can also grab some inconsequential JS library, change the name, and publish it to NPM.

If you're putting in the effort to take your resumé, you might as well fill out a fake Github. After all, the "hiring experts" only seem to care about the code you've pretended to write.

I also look for github links, especially for sysadmins, it can give an insight of how they solve things. Bonus points for pull requests.

However, if the person doesn't have a profile, or an inactive one, I don't put any weight on it, it's more an alternative way instead of asking interview questions for me.

Resume parsing is something I'm working on, see https://lxagi.com, it's in the examples.

Oh goody. Now I can anticipate an article in a week or so talking about the issues people are having relying too heavily on using GitHub trawling as a hiring signal.

> The first thing I look for in a resume is a GitHub URL.

Wow - that would narrow the field a bit (if the github account is a pre-requisite). For example, I don't interact with Microsoft online properties at all. I don't much care for git. And even if I did use git, I'm not in favour of entrusting important information to online service providers such as Github.

Lucky I'm not looking for work, I guess.

Reply on news.ycombinator.com