I interviewed at GitHub last year for a Frontend role, I went through this process then at the time.

I have to say as a candidate it was extremely off putting being asked to create a CRUD API for a Frontend role. It wasn't a hard ask, but I feel like the skillset being tested is not the same. After reading this blog, it seems it would be easy to automate the exercise toward creating a CRUD API versus a drop-down menu component for example.

Another downside I disliked about this approach is that I never spoke to a hiring manager or an engineer from the company. It went from Recruiter straight to automated tests. I understand it saves the company time, but it felt very dehumanizing. How far along the process do I have to make it to before I know if it's a team I even want to be on? I didn't bother and focused on companies where I spoke to someone technical first. Got a better sense of the company culture immediately and knew which interviews to focus on.

At least with other companies like Facebook/Meta they stick another Engineer with you when doing their technical assessment. Felt like they had skin in the game when conducting interviews at least.

Aa an aside, companies that use Karat [1] for interviewing (basically outsourcing the technical interview to a 3rd party) get a hard pass from me. If you read around other SWE communities, it's a common sentiment. If you can't even conduct your own interviews, what does that say about your culture?

[1] https://karat.com/

> At least with other companies like Facebook/Meta they stick another Engineer with you when doing their technical assessment. Felt like they had skin in the game when conducting interviews at least.

There’s a small number of engineering hours available for interviews. GitHub must pass on a huge % of applicants. How should they select candidates for those slots? Automated resume scans, automated coding tests, prefer name brand schools/companies. GitHub’s approach seems fairer.

I think it's the opposite. Reducing the candidate to a pull request means that gender, race, etc. become completely irrelevant, as it should be. It also means you can assess many more candidate and don't need to sift based on CVs. It's the most inclusive option, with the trade-off that it makes the candidates feel worse and may mean you lose some of the most sought after candidate who have many other options.

All of the attributes you mention are subjective and will inevitably lead to bias influencing the process.

Have you ever had to work with a toxic person before?

Those subjective attributes have a very real impact on the workplace. It takes only ONE toxic person to sink morale for an entire team.

Not filtering out toxic people turns your "most inclusive" into "least inclusive" pretty damn fast because suddenly nobody wants to work at your company anymore.

Personally, I haven't (I hope that doesn't mean I'm the toxic person).

I think those people are rare enough that they can be filtered out at the very end of the process when there is already objective evidence that the candidate is competent. In many workplaces, I think they may even be best filtered out in a paied trial period with some kind of commitment to hire them unless there is a problem. That way the decision can also be made by the people who will work most closely with the candidate.

I'm against the idea of testing for cultural fit because I think that leads to less diversity (including less diversity of thought and opinion) which I believe is harmful for teams. I think we work best together with people who are different from us, as long as we are still nice and respectful to each other.

> Personally, I haven't (I hope that doesn't mean I'm the toxic person).

I wonder if that's because there are interviewing processes in place that weed these people out. Possibly even ones that have been standard for decades or longer?

> I think those people are rare enough that they can be filtered out at the very end of the process when there is already objective evidence that the candidate is competent.

This sounds like a real good way to open yourself up to legal liability for exactly the type of discrimination you are worried about. Even if there isn't any discrimination.

> I think they may even be best filtered out in a paied trial period with some kind of commitment to hire them unless there is a problem. That way the decision can also be made by the people who will work most closely with the candidate.

Suppose you hire a candidate who benefits from the interview process you describe (maybe the "deferred culture fit"?) You seem to mostly be concerned with non-white people, so let's assume they're that. In 2022, who wants to put themselves out there and accuse a non-white person of creating problems in a progressive workplace? Nobody, that's who.

> I'm against the idea of testing for cultural fit because I think that leads to less diversity (including less diversity of thought and opinion) which I believe is harmful for teams. I think we work best together with people who are different from us, as long as we are still nice and respectful to each other.

I'm against the idea of assuming that anybody who isn't a "straight, white, Christian male" is going to be discriminated against at every turn during the hiring process. ESPECIALLY not in Silicon Valley or NYC.

Somehow everybody in these coastal cities is highly aware of and sensitive to ism/phobia, and still very ist/phobe.

Totally agreed. Especially when you're as popular of an org as github, assessing the technical level in a completely indiscriminate process can very easily reduce the pool of candidates that need to be assessed by the actual team that the candidate would be working with. I love people, but i hate interviewing people, and would rather risk losing one that MAY have been good if we started out more human than risk wasting my time interviewing completely unqualified candidates. Until i started reading comments it didn't even occur to me what they are doing at GH for interviewing could be seen as a bad thing. It's all about economics though, and results may vary. Make it easier or harder to hire based on how hard it is for you to fill the role.

In a tough hiring market, making the first interview automated is a bad idea. It might be a bad idea during any kind of market, but I find it particularly off-putting today, when there are many job options for a software developer.

The cost of an automated interview is asymmetric. It will take the candidate a few hours, whereas a reviewer may look at the submissions for <5 mins. This is starkly different to technical interviews at other companies. A whiteboard technical interview requires equal amounts of time to be spent by the interviewer and candidate. That's a great signal that the company is willing to invest time ($$$) to find the right candidate.

I think Github's intentions are pure. I take what they are saying at face value. There is no such thing as a perfect technical interview process and I admire that they are trying to align their technical interviews with the actual day-to-day work process. However, I think it would benefit both them and candidates if they came up with a process that focused more on the _human_ component.

If you think a little deeper about that 5min vs 3hrs between reviewer and reviewee, you may consider that the reviewer is likely to have a great deal many of reviewees to review. In the choice of initial friction and evaluation before human interaction, it always depends on economics. Engineers don't generally enjoy interviewing people. We want to solve problems. But once there is a candidate that has caught our attention, we love meeting our potential new work mate.

Simply no, unless I am getting paid to do the test, I am not doing until I don't know what I am gonna work on exactly and for how much.

GitHub is only getting away with this because they are too big, and people assume the best about them. This won't fly elsewhere.

Engineers don't enjoy wasting time either.

You kind of making my point for me about economics playing a part.

No, a mom and pop shop, or even some boring established company that has no 'status' would not be likely to get many applicants w that much friction.

The popularity of the company and the perceived 'prize' that the engineer gets by becoming part of that company determines how much friction they can (and rightly should) add to the employment process to weed out the majority of applicants and focus on the ones that really want it (and really deserve it).

If you're a small startup you absolutely cannot do this in the current market.

You can maybe start with a 10-15 chat with a founder to build rapport, and then move to 1:many.

I like the idea, but I do have a nit to pick. Anonymizing the pull request title is kinda stupid.

That bit reads to me like a cheap attempt to say "look how not-racist we are." In fact, that "bias" will easily come through via comments in the code.

Succinctly summarizing work (i.e. via PR title) is an important communication skill and removing that from consideration is pointless virtue signaling.

I actually think the time constraint is a much bigger issue. Some people may be less efficient, but willing to work more. Time constraints bias against those types. Some types of engineers spend a long time thinking about a problem, then quickly produce a solution that is bulletproof. Those people would also be disadvantaged, I think.

I hadn't considered that choice, you're absolutely right! A well summarized commit, and even a potentially detailed body, is absolutely within the realms of what i would review, and trying to anonymize by pull request title seems silly at best.

Beyond thorough commit messages and clearly-communicated PRs, don't forget the power of the project README.

An engineer who takes the time to document a thorough README, with screenshots and diagrams, proper use of markdown, etc.? Wow. A thing of beauty.

Also someone who is a complete wizard at TDD might not come across well if there is no test framework in place.

This is a really interesting look at an obviously well thought out interview process. If anyone at GitHub is reading this, I have a question: you mention that submissions will be graded with automated tests and a rubric. Are these visible to the candidates before submission? If not, what is the thinking behind that? In a real world situation, you would know the acceptance criteria of your work, and invest time up front in writing extensive test cases. My preferred way to work is with tests running in watch mode so I get constant feedback as I work. Are you asking candidates to write tests themselves and comparing which cases they tested to the ones you had expected them to test? Or due to time constraints are you asking candidates to skip testing and only using the tests as an internal gauge for how well they solved the problem?

How long until Github Copilot can autocomplete their standard takehome coding exercise?