Ask HN: What do you look for in an applicant's GitHub? | Hacker News Reader

Ask HN: What do you look for in an applicant's GitHub?

59 pointsbmpafa56 comments

I'm a self-taught JavaScript guy / solo-preneur & have been thinking of seeking part-time / contract work.

Skill-wise I consider myself (FWIW) between 'mid-level' & 'experienced', but having never worked professionally as a dev, I'm uncertain about hiring expectations, particularly wrt code samples. Most of my code is closed source, so I'm looking to build-out my public stuff.

When you review an applicant's publicly available code, what's important for you to see? My assumption is that reviewing a repo is akin to reviewing a portfolio / resume (i.e., very quick), so how have applicants "wow'd" you in the past? (I mean short of obvious rockstar qualifications, like 'React core developer,' etc.)

View on HN

I don't use github content as a criteria, at all. Not everyone uses github as a portfolio. Not everyone uses github at all. Some people just store stuff there, not worrying about the quality it may communicate to the world. Other people work primarily in private repositories, so their public data doesn't tell you much. Someone could just have a bunch of forks of other people's work, which they dabble with. And newer coders are often learning quickly, so their code from even a few months ago is not representative of the effort they would put in professionally if hired today.

I agree with your comment, just wanted to point out that:

> Someone could just have a bunch of forks of other people's work, which they dabble with

is quite easy to spot: those repositories will have "Forked from user/repo" below the repository name (on top of the page, and also in the list of repos of a user). If they committed their dabbling, that is almost certainly on top if you go to the commits screen.

> If they committed their dabbling, that is almost certainly on top if you go to the commits screen.

If they committed their dabbling right, and the default branch is still master, it will be in another branch, possibly with a PR attached. It's certainly possible to use a fork master directly, but I think it's a quickly learned lesson to only use a fork master for upstream tracking. (How far behind a tracking branch like that is can be informative, sometimes.)

A few years ago I remember being asked to sit in on an interview with a senior-level developer. Our lead seemed really impressed by this guy, and he had a ton of specific questions written out on various tools, which was fairly strange as we tried to make it a fairly light process.

She said that it was an opportunity to ask a core developer of a lot of open source projects some questions. After looking at his GitHub profile a few minutes before he arrived, it turns out that she believed that all the forks on his account meant that he was an active contributor, when in reality this guy was using forks to save repos he found interesting.

In all fairness to my boss, this guy tried to lead us down that road, since he had contributed a typo fix to a README file a few months ago, and used this as a way to say he was an open-source contributor. Strictly speaking, he is, but there's a big difference in what he's done and what my boss thought he had done.

Given that many developers don't really deal with GitHub all that much, outside of as a link to documentation for hosted code, it wouldn't surprise me if some hiring managers had hired people based on what they've forked, rather than actually checking to see if they've written any code on the account, or whether it's any good.

Great answer. Especially because it's a) so logical and b) so against "generally accepted practice".

I never provide or look at anyone else's code before getting to know them for these and many other reasons, but mainly because a repository is in such a vacuum, without context or correlation to what the person really can do.

To paraphrase an old mentor: "Someone with a perfect repository is either faking it or has never taken enough chances."

Is it against "generally accepted practice"? Everything I've ever heard from recruiters and hiring managers has been that they typically have about 30 seconds to review any given resume, and zero time for code review. Do you have a source which says this is common or recommended practice?

So rightly said. I have my best work as private repos.

Not everyone can post their work on GitHub, so I only look at their profile if they list it on their resume. I figure if you put it there, you want me to see it.

For early-career people (with limited work experience in the field) I look to see what tutorials they've done. I don't expect high code quality, but active engagement instead of copy-paste is nice to see.

If they've contributed to any OSS projects I look at things like:

- How they interact with maintainers and other people

- The quality of their PRs if any

- How well they communicate issues and file bugs. Attitude

matters a lot (offering helpful ways to reproduce it and suggestions rather than attacking the project for faults)

If they have any of their own projects I look at code quality. I deal mostly with Python and it's pretty easy to tell from a glance how experienced the person is. Things like following lint/style and style guides but also readability in general. You can smell out a C/JS programmer who just learned Python pretty easily (lots of for loops with indexes, for example).

If they collaborate on projects with others that's a huge plus. I look for signs of active collaboration, like PRs with good code review.

Basically I want to make sure:

- They're not exaggerating their experience (though GitHub profiles can be out of date)

- They work well with others

Again, just because a GitHub profile is sparse or missing some of these things isn't a signal. Not everyone does their work on GitHub. But if you list it in your resume, expect me to read it.

> How they interact with maintainers and other people

> The quality of their PRs if any

> How well they communicate issues and file bugs. Attitude

That information is extremely valuable when available. When looking at profiles, if I see a person can't parse information provided by other maintainers, or put in a due diligence into narrowing down or solving a problem when filing bugs I will reject them without even a first phone screen (exceptions when the PR/comments are old, etc.).

But it's rare to come across this information.

I look for signs of understanding.

I want to see an understanding of git - they have repos with appropriate commits, good commit messages, awareness of licensing, decent READMEs or info for collaborators

I want to feel like they understand how open source works - they've filed or participated in issues/discussions, they've starred/forked repos, they've opened PRs, they've managed issues/PRs on their own repos.

I want to see how they manage their projects/repos. Do they use a package manager? Do they have linting or build tools? Do they use CI? Have they kept the repo clean and ready for others? Do they use automated testing?

I don't expect to see all of this - but if someone has none of it, it's clear they have a lot to learn and aren't ready for the job.

This comment reads like argument for not putting most of random personal code people write on github. It can harm you.

For me, it would be signs of a sensible structure and use of commits. It is extremely offputting to see some obvious code dump, with like 2 commits in total (one of which is “fixd typo lol”), no real directory structure, etc.

A repository is an opportunity to show off how good you are at organizing a project, breaking down your commits, etc. Only after any of that looks promising, will I bother to read any code (after all, it takes time to understand something and the harder it is to grok the less likely I’ll spend the time).

So what? I use Github for any code that I want to share. I’m sorry my weekend project only has two commits. I didn’t realize I was being scrutinized for every tiny detail. Would you like every social media post as well to make sure I’m perfect 100% of the time, even in informal situations where perfection is not expected?

I would not want to work with/for you.

If you're presenting what you have on Github to a potential employer as a shining example of what you're capable of, then yeah, it should be polished as hell, because you are literally presenting it to someone as an example of the heights that you're capable of and why they should hire you.

If instead it's just a casual place where you mostly just plop random stuff to share with friends, that's fine too, but don't show it to a potential employer, any more than you would send them links to all those social media posts that you don't want them to judge you by. It's pretty simple.

If you're going through some company's hiring process and slip in a, "hey, by the way, check me out on Github", they will naturally interpret its contents as an example of you at your best, because otherwise why would you want them to check it out? Job seekers don't go out of their way to publicize their Github output on their resume if it's just a place for brain dumps and code snippets. Nothing wrong with using it that way of course, but it's not a useful thing to show to hiring managers, in the same way that I wouldn't go out of my way to show them my class notes or old tests from college. It's not relevant, and may even give them the wrong impressions.

> I’m sorry my weekend project only has two commits.

This is like being a graphic designer and saying, "I disable the undo feature in Photoshop for all my personal projects."

It makes no sense to people for whom source control is second nature, and I'd be reluctant to hire someone for whom source control is not second nature.

I agree with this, but if you have some projects you're proud of, Github lets you include/arrange six "pinned repositories" on your profile page, so that prospective employers/clients see those rather than your messy weekend hacking. There's no reason you can't have both clean and messy!

The difference being that you don't submit your social media profile as part of applying for a job. I agree with grandparent though, looking for structure of commits showing organization is important.

No one is a perfect coder, but it is discouraging to look at a candidates GitHub and see that the majority of it is a mess since they included the url on their application, which generally indicates it's something that they want to show off. Not every repository or commit has to be perfect, but if you submit a public GitHub profile, expect it to be scrutinized in detail.

>The difference being that you don't submit your social media profile as part of applying for a job.

Github is a social media platform. Last time I applied for a job, I gave the company an account and URL to access my self-hosted kallithea instance instead.

There are a world of benefits to this. I only gave them view access to the projects I considered to be portfolio pieces, and locked them away from the scratch projects.

It also allowed me to see how many times they logged in, which is how I know that they never actually looked at any of my hobby code before offering me the job.

Lets be real here, companies want your github profile for the same reason they look you up on facebook: everyones at least a little bit into voyeurism. Give 'em something that they know will be logged and scrutinized back, and you'll see what a chilling effect looks like.

You view "commit hygiene" as something that does not matter. I view it as one of the most important aspects of a software developer's workflow. If you don't see the value of atomic commits in any software you're creating, I doubt you would properly apply it to our teams' repos.

It should be like this:

well-organized github > chaotic github >> no github

instead, when employers evaluate github profiles, they reason like this:

well-organized github > no github >> chaotic github

>It should be like this:

>well-organized github > chaotic github >> no github

I don't like to share my random projects on github, just like I don't like to share my life on facebook, fuck me right?

Anecdotal of course, but in my experience, when hiring professional engineers, neither I nor anyone I know would judge someone for not having a Github page to look at. If they have one, great, I'll take a look, but if not, no big deal. It's not an expectation at non-startup tech companies.

I've heard some people here on HN occasionally say that if an applicant doesn't have a Github page to look at, they will think less of them and maybe not even give them an interview. I always imagine the people who say this as being guys in their early-to-mid-20s who are fresh out of school, never worked anywhere outside their comfort zone, are still within a comfy bubble of friends and family, and went directly to the startup path where they are learning about stuff like recruiting and management in real time (if not outright making it up as they go along). I don't know if that's a fair characterization- it probably is unfair and inaccurate. But that's the stereotypical person my subconscious imagines those posts come from.

The silver lining is, if someone doesn't give you an interview because you lack a Github page, you probably don't want to work for them anyway.

>It's not an expectation at non-startup tech companies.

Not true in the slightest. Before you get to talk to the engineers like this, you must first pass the HR filter.

HR are not engineers, but they think they see a parallel to their own work.

In HR, all HR applicants are expected to have a linkedin page, because linkedin makes HR's life a lot easier. I have Strong Opinions about this state of affairs, but none the less, there is a hovering perception in most HR offices of "if you don't have a linkedin page, how good at your job can you really be?".

So then HR hears the engineers talking about github and profiles and sharing code and they dig a bit, and they often decide that github is basically linkedin for engineers. Lets be real, they're kinda right in some ways.

But they're dead wrong in others. Lets not get sidetracked, but just say there are valid reasons some people don't use it. Engineers have the full picture and know this. Like you say, most professional engineers won't judge you for not having github.

However, HR lacks the context to understand this, and so they increasingly throw out engineering CV's that don't include a github link. It's a growing problem.

Ya, because no project of any value has ever been developed somewhere other than your personal favorite hypocritical platform, right?

You can use GitHub for code dumps sure, but I guess grandparent was assuming we were talking about legit open source repositories, not another hello world.

I'm a frequent game jam participant, that's my little weird hobby. My GitHub now is an ugly mix of my well-done free software projects, forks of thinks that I contribute to, small little utilities/hacks/old student projects I upload just in case it's useful for someone someday, and tens of ugly code dumps of things I made from scratch in 48 hours with varying output quality and constantly bad code quality.

And I don't feel bad about it at all :P

That scary because in all the repositories I've made public so far, I always have a private version with the full commit history and start a new public repository when I'm comfortable publishing it.

I don't even know if I could do it another way because at the early stages of a project I tend to leave a lot of junk in the commits that I wouldn't want to be public :/

As someone that has interviewed hundreds of people. Nothing unless they really want me to look at it.

As someone that still loves to code even tho I'm in management, I've found out that writing beautiful code get's in the way of getting shit done!

When I code for myself, it's either to explore or practice. Beautiful code is not the goal. If I'm exploring a new idea, then one thing I like to do is to make it happen as fast as possible by any means necessary. I don't care about comment, duplication, abstraction, tests, optimization.

That's what you will find in my github, I don't do resume driven development where I write code hoping to get hired because of it.

It depends on the person and my expectations for the role. The best people have everything, including jobs! So I make it a rule not to expect perfection, helps prevent disappointment.

When I'm evaluating candidates from a resume, if they have a link to a Github or personal website I'll visit it about a fifth of the time. I'll open up a couple repos and make note of what they look like.

Are they school projects? That's fine but not necessarily indicative of anything since most academic code is write-once, run-once for an assignment.

Does it look like a personal project? Great! This is what I'm most interested in.

Is it easy to understand what the project is before reading the source code? README files and a clear directory structure/file names can go a long way here.

If I look at the source code, how is the readability? Do they have good variable names (i.e. not a, b, c,..,z) and use the idioms of their programming language?

Bonus points for good comments. Triple word score if I can understand the code without comments.

I'll go through a couple repos this way and use whichever one is best to inform my initial bias. I think it's always a good idea to assume best intent when interviewing someone. I've had some people I wasn't that excited about in an interview become my favorite coworkers over time.

PS - Here's a project of mine I'd consider a "good" example. Mostly the number of unfinished {- TODO -} comments in src/Lib.hs would hurt me here, were I evaluating myself. https://github.com/cbzehner/word-frequency

I want to be able to understand what the project is about, and get a high-level understanding of how it works.

Our hiring process starts with a phone interview and there's a quick technical discussion (mostly there to avoid wasting time if the candidate's skills obviously do not match what we need). A live coding exercise is hard to set up and takes a while to perform, if only because the candidate needs some time to understand the question and gather some elementary insights. So, instead, I ask the candidate to explain some code that they have written, and I expect them to be articulate and knowledgeable about it.

So I want to be able to find a commit or file that can serve as a basis for an in-depth discussion relevant to the kind of work that the position involves. If I'm hiring for web front-end, then client-side JavaScript will have to be involved. If I'm hiring for Big Data, then high-performance code, low-level code, or distributed/parallel code will be good. If I'm hiring for Compiler Design, then a toy (or non-toy) compiler is nice.

I will tell the candidate ahead of time about the commit/file that I find interesting (or even ask them for pointers to help me pick one). That way, if they join me on the phone interview and have no idea what their code is doing, that's the end of the line.

I don't really care about code quality. Obviously, if the code is so bad that it's impossible to understand, that's bad news, but most of the time the code is readable, it's just missing comments, or has variables like `item2`, or functions that are too long, or other stuff that you would expect in an open source project. That's fine, because it leads into two very powerful questions in this type of interview: "Are you happy with the quality of this code?" (the correct answer is "no") and "If you had a few weeks just to improve this project, what would you do ?" (I expect insights about refactoring, or improving test coverage or even improving testing/validation strategy, or adding comments).

Things that set off alarms:

+ Lots of unmodified forks or tutorials. A few is fine but too many is suspicious.

+ Tons of empty repos

Things I like:

+ Lots of messing with different projects even unsuccessful work

+ Side projects, even incomplete ones

+ A mix of languages/designs/idioms

Super awesome things:

+ OSS contributions

+ Working well with others

+ Good branching

I use github to track repos I'm interested in. I'll fork it. I've seen projects just disappear.

I fork tutorials for the same reason or even good tutorials I want to keep for those I mentor.

:-)

I set up a separate organization (“milesforks”) specifically for this purpose. This way my main profile is not polluted with forks.

Different projects have different needs certainly, but its nice to see a readme that gives me some context to what the project is, and how to actually run the code, install needed dependencies if it's not obvious. Also probably worth acknowledging shortcomings or places for improvement in the readme, so your reader is aware that you're aware of any deficiencies.

I occasionally interview candidates for a small software team (less than 10 developers). When evaluating a candidate's GitHub account, I look for any non-forked projects (projects that they created/own), then I look at the structure, code, documentation, and commit history of those projects.

At that point, the quality of the project can either help or hurt the candidate:

- The most important thing is that whatever project content they have, it is understandable. The ability to write sensible code that follows conventions and is well-documented (in code and commit history) is highly desirable.

- Ideally, they'd have an open source project with recent releases, issues, milestones, contributors, PRs, etc. (basically all the signs of a healthy open-source project). If they had this, then they'd be way ahead of most candidates.

- It's easier to evaluate docs and commit messages than it is to evaluate code quality, but I do try to pick out a few files and have a look to see if they make sense.

Honestly, the main thing I'm looking for is that they have a Github account that's more than a couple of weeks old and has some sort of content in it. That shows me that the applicant is interested in programming for its own sake and not just checking a box to make their resume look good. Everything beyond that is just a nice-to-have.

I went through a round of resume filtering and interviewing for interns recently, but I'd use a similar process for FTEs (just less lenient probably). I mainly used the Github profiles (for those who had them) as another seed for questions besides the resume itself, and it could give me a feel for how well they'd do on our simple coding challenge. For example one candidate checked some API keys into his projects, those are generally supposed to be non-public. I asked about the dangers of accidentally committing private keys in general and he talked about AWS keys and relayed a story of compromise that happened to a friend, then I asked what a main problem of checking in API keys could be and he mentioned rate limiting denials. So he understood the problems, I asked why he had API keys in some of his repos, turned out to be he thought he had disabled the ones that were checked in (at least one I tried wasn't) and they were for hackday projects anyway. With some context on it, and other discussion, all in all I was happy with him.

I try not to let presence or absence of Github matter (and in general I try to differentiate on common information rather than lucking out to see a very negative / very positive trait in 1/10 candidates that I wasn't explicitly looking for), but I have to admit I like to see a link and like to see at least one project on it of any size and not just a sea of forks with no clear individual contributions. Resumes seem to correlate with coding performance terribly, at least if there's public evidence you can code (I'm not too picky on code quality, that's what reviews are for and drive-by open source reviews are non-existent) I don't have to spend as much effort verifying such in an interview.

I'm not looking for rockstars. Using the classic trade ranking system, there are apprentices, journeymen, and masters. Journeymen are essentially interchangeable for most normal tasks starting from scratch, that's what I want to hire and work with most of the time. I can live with a sharp apprentice, especially if the apprentice is pretty skilled in the usual domain we already work in. Since I'm not a master myself, and I can think of no more hostile and futile way of attracting them than standard software interview practices I'm forced to somewhat conform to, I don't try to get them.

Something that's important to me is code that is commented. Well-commented code (documentation for each function, explanations behind complex if statements and loops, etc.) earns bonus points. Conversely, when I see screens and screens of code without a single comment that sets off red flags.

Due to the nature of my current role, writing documentation is necessary so that other team members can pick up where you left off if something happens to you (or you just go on vacation).

Interviewers like yourself are great red-flags everyone need to look for in a company during the interview as well as during initial screening.

If a company relies on (outdated, in most cases) comments and not the code itself its an immediate signal for an interviewee to re-evaluate this company and decide whether or not its the place he or she actually wants to be a part of.

Very important to mention that it goes both ways: if I need to read your comment in order to understand your code, there is something wrong with your code.

I hardly ever write comments for code I write. My philosophy, which I took from Uncle Bob, is if code is so complex it needs commenting at a statement or method level then it's too complex. Simplify the logic, put complex clauses or statements into meaningfully-named functions (which you can test too, so win-win). But don't rely on comments to explain your code. Your code should explain your code.

Only "overview" comment blocks for entire files, which describe the overall purpose of the class or module, are useful to me and my team.[1]

1. https://softwareengineering.stackexchange.com/questions/2857...

There's a difference from writing code for yourself and writing code for other's. If I'm writing code for myself in a domain that I'm very familiar with, comment get's in the way and clutters up things. I've looked at code I wrote 10-15yrs ago and understood everything because of strong familiarity with the domain. Based on the domain, I might have naming convention that is specific to that domain and I'm not going to name in Enterprise fashion. It's a strong assumption to think that code some people publish are for consumption of other's. Most of my after work hour code is for my own and the computer's consumption.

I generally only look for the 'bigger' projects, and only really bother if it is explicitly mentioned as a thing to look at (e.g. used this open source project/language). Even then my criteria is the same I would approach to a source code review:

1. Is the code well formatted? If you haven't been someplace where it is bad, you might not understand how bad can be. I'm not going to give someone on a pass on something even the worst editor can do great.

2. Does it look awful to build? I have seen projects presented to me that have no Makefile or appropriate mechanism to build the code successfully but 50+ source files. The exception here is obviously templates or ~1-2 file projects to solve a real problem. I don't want to hire someone who can't build software, or make their software nice to build.

If those first two criteria aren't covered I'll skip to my last criteria:

3. Lack of input validation/error handling/logging errors.

4. Knowing common language constructs. Even in learner projects I want to see that you know how code should feel in that language. Python is one of the ones where this is most obvious, Java is one of the ones where it is least obvious so this is a subjective piece.

5. Does it feel like original work or tutorial spam? Where's the artistic flair or the completely engineered and mechanical thing that made this more than a 2 hour project, and worth your time?

The main thing is that your resume should strongly reflect that you want to change careers as a dev and you want to demonstrate your skills via GitHub. I would not go fishing unless you ask. I'm going to look at your technical experience and general work history and ask you just as many questions about those kinds of things.

An empty, boring, or bad GitHub account never hurts, but a good one can definitely help. Things I'm looking for are interesting projects, contributions to other projects (perhaps ones I know about), good discipline in git commits, well organized code, attention to detail (as in code style), and good interactions in tickets and code reviews. I'm not interested in whether or not your GitHub projects use any particular languages or technologies that are relevant to the role.

There's this idea that no one should be expected to spend their spare time working on open source, which is fair. However, that are many candidates that do, and it helps a lot with the screening process. We might waste more of your time and ours if we have to coax out the kind of insight that I can get from a GitHub profile over the course of several phone screens and IRL interviews.

I primarily look for signs of the ability and interest in self-teaching. A front-end developer exploring the backend? Great! A backend developer playing with probabilistic systems? Super!. A java developer branching out into Scala/Clojure/Rust/Haskell etc? Even better!

For those that won't look at Github because not everyone has an account. That doesn't make sense. Whether or not the candidate has a Github account is not a litmus test, its just additional useful information. If they have an account that may tell you something useful about the candidate. If they don't have an account, then you have to rely on other approaches to get that information.

I have a pretty active Github. When interviewing I talked about it and put a link in my resume. People very rarely check it, but it gave me talking points when the tech of some old project matched the company's stack.

Multiple projects of interest (not just commercial), ideally with significantly different languages and problem domains. The ability to write clear documentation. Definitely not a pile of cloned repos with no contributed changes.

A well-developed README that promotes the project. Screenshots, explanations, an FAQ, release notes, info for collaborators, links to download or test.

Basically, the github repo as a homepage for a product rather than just a dump of text files.

This shows that your thing is a finished project or under ongoing development rather than just a dump of some source code that you once wrote. It's the equivalent of having an app on the app store vs. having a half-baked Xcode project on a computer.

I try my hardest not to do any 'grading' based on someone's github, but instead use it as a reference of what I can expect when the candidate gets to the interview. There's always a feeling out point at the beginning of the interview. I don't want to waste time hashing out things they clearly understand and likewise I don't want to throw them something over their head. Looking at their Github helps give me a starting point.

First, I want to see contributions to flagship opensource projects. If you are using opensource stacks and pushing the envelope, you will eventually have to fix bugs or implement new features. Landing patches means the applicant is able to meet the high bar for contributions (code quality, documentation, tests).

Then I want to see side projects using the same stack that will be used internally by the applicant. You can tell a lot about someone by his code style.

I look for many things but don't hold it against you if your GitHub/Bitbucket/GitLab/etc doesn't reflect it.

Your profile can give me some evidence that you know how to code, use version control, write documentation, etc. -- but just because your projects don't have CI/CD (or whatever) doesn't mean you don't know how to use it just that I don't have evidence that you know how to use it.

If I'm investing the time to look at her/his github, I have probably already invited the candidate over for an interview, or am seriously considering doing so. I'm looking for anything that gives me an insight into the way the candidate approaches problems, than I can then use to further the interview.

Any github that contains more than just course work is fine for that.

I'm not sure I've ever bothered to look at an applicant's github account. I wouldn't expect to learn much from it. I am amused to imagine just how strange someone's impression of me would likely be, were they to derive it from the random collection of experimental hacks in my personal github account.

Here in Toronto I always ask, have you looked at the source code I shared? And the answer is no.

I have lots of source code open to private to share, and its just because I'm a workaholic, though I find having source code doesn't matter, at least not here since they don't put much value in it.

Do the people here preaching github being a useful tool for candidate evaluation realize there are private repos? I use github everyday but none of the outsiders looking at it are going to get a sense for my coding style because they can't see the content of the commits.

Yes. I am guessing they are taking that into account and expect you to do the same.

Getting some code public now and then will the outside world get that 'sense' easier than other methods.

I've ran into this where both my day job code and side project code are proprietary. I looked at my github profile and felt underrepresented. Now I have the goal to push something public here and there.

Realistically, pretty much anything sane is a plus, because most applicants don't even have github account. AlSo realistically, have a good readme because that is the thing most hiring managers will read (unlike codebase).

Reply on news.ycombinator.com