[HN Gopher] GitHub does take home technical interviews
___________________________________________________________________
GitHub does take home technical interviews
Author : todsacerdoti
Score : 24 points
Date : 2022-03-31 17:01 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| axg11 wrote:
| 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.
| azemetre wrote:
| 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/
| dolni wrote:
| > 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.
|
| This sort of stuff makes it so obvious to me that companies
| like GitHub "caring about inclusion" don't, actually. You, as a
| candidate, are reduced to a pull request.
|
| There are so many attributes that a great employee can bring to
| the table which will not come through in a pull request, like:
|
| Are they excited about the work?
|
| Do they have a positive demeanor (maybe boost morale of other
| employees)?
|
| Are they a big-picture type?
|
| Are they a self-starter?
|
| Are they constantly looking for improvement opportunities?
|
| Can they provide mentorship?
| yosito wrote:
| 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?
| dolni wrote:
| 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.
| legerdemain wrote:
| How long until Github Copilot can autocomplete their standard
| takehome coding exercise?
___________________________________________________________________
(page generated 2022-03-31 23:02 UTC)