5 ms·

> can just ask for relevant projects or commits on GitHub of a major open source project and that eliminates the 90% of candidates in the pool Not everyone spe

> can just ask for relevant projects or commits on GitHub of a major open source project and that eliminates the 90% of candidates in the pool Not everyone spends their free time contributing (to major nonetheless) to open source projects. There are a lot of great engineers that have enough work on their desks with their day job and there are also plenty of idiots in open source. Asking for relevant projects or asking for GitHub profiles to gauge relevant projects yourself is what people were already doing years ago and it wasn't a great hiring strategy. Turns out judging a software engineers skills is extremely hard.

angarg12 3y ago
This. Focusing your hiring on open source contributions biases the process and misses huge slices of the software engineering population. I made the best work of my life (by a long long shot) to private companies closed source.
thwarted 3y ago
Not everyone spends their free time contributing (to major nonetheless) to open source projects. and elsewhere in these comments, we see: I would expect candidates for programming jobs to demonstrate first class ChatGPT or other code copilot skills. Not everyone spends their free time learning first class ChatGPT or code copilot skills. It's interesting that this age old mantra about open source contributions being inappropriate for a hiring manager to expect because of what people do or do not do in their free time now does not apply to random other skill/experience that one must also acquire in their free time. If a company has, for example, "git experience required" on the job posting you'll either need to actively demonstrate that you know how to use git or passively demonstrate by having a on-line accessible corpus of git-related work that shows your experience. You don't get a pass on that requirement just because the companies you've been working at don't use git and, well, you don't want to spend your free time learning git. And it is appropriate for the hiring manager to list that as a requirement despite claims that they'll be disqualifying some percentage of the candidates by including that as a requirement.
- mythhabit 3y ago
  I think part of the issue is also the complete lack of thrust. If you state that a candidate must know git, and the candidate say they do know git for basic committing, branching, merging ect, then fine - let's move on. I've learned that prior work history, talk and basic problem solving is in no way indicative of performance at all. I've found that the only guaranteed process to find excellent candidates, is hiring interns and part-timers currently finishing education, and pick the ones with the right mindset and intelligence.
zelphirkalt 3y ago
That is a fair view. Of course there is also a tendency of great engineers doing project in their free time, since they love what they do. There is also the fact that there is a higher chance of someone having learned a lot more, if they continuously worked on projects in their free time. There is also a higher chance to find people, who are not just into software development jobs, because they pay well, but because this is what they want to do. So for hiring engineers, I can understand when they hire with a certain bias. Sure, no one should be expecting us to do extra rounds, and sure, one can be a great engineer even without extra rounds, but the tendency is for that to take more years without that drive to explore in ones free time. And that's OK! I think it is fair though, if a company wants to hire a more driven/curious/exploring person.
deanrtaylor 3y ago
Isn't the general mantra around leetcode that you should be spending a few hours after work in the lead up to joining the interview process to get into the swing of it? What would be different from spending that time making a few PRs to an open source project or just building something from scratch to demonstrate your skills? A lot of engineers that I've worked with have never spent time on leetcode and struggle to answer the common interview questions that aren't easy or low medium, so personally I don't see it as that much different, there's time required either way. One is productive, one isn't.
- kjkjadksj 3y ago
  No other fields work like that. Computer science hiring managers need to figure it out. You have engineers in other fields who have long careers working multiple companies not even allowed to talk about what even occurred and its just routine.
  - wakawaka28 3y ago
    Actually they do work like that. Engineers can be asked to solve problems in interviews. But the pressure doesn't seem like in software, where many people complain. There's no LeetCode equivalent for other kinds of engineering I think. But some of them do have licensing to deal with.
  - ric2b 3y ago
    Those engineering fields have exams and certifications. Software Engineering is still too immature for that, I think.
    - BeFlatXIII 3y ago
      Software engineering is too easily self-taught for certifications to become the norm. The moment you have a cohort of people with demonstrable skills without such certifications, the value of the cert is undermined.
    - kjkjadksj 3y ago
demurgos 3y ago
Asking to be a regular maintainer for some Open Source project may be too much, but I expect an engineer to track down root causes of bugs. And if the root cause is in some Open Source lib, then they should do their best to fix it there. Even if they don't provide a full PR/MR, reporting the issue and engaging with maintainers is already great.

angarg12 3y ago

This. Focusing your hiring on open source contributions biases the process and misses huge slices of the software engineering population. I made the best work of my life (by a long long shot) to private companies closed source.

thwarted 3y ago

Not everyone spends their free time contributing (to major nonetheless) to open source projects. and elsewhere in these comments, we see: I would expect candidates for programming jobs to demonstrate first class ChatGPT or other code copilot skills. Not everyone spends their free time learning first class ChatGPT or code copilot skills. It's interesting that this age old mantra about open source contributions being inappropriate for a hiring manager to expect because of what people do or do not do in their free time now does not apply to random other skill/experience that one must also acquire in their free time. If a company has, for example, "git experience required" on the job posting you'll either need to actively demonstrate that you know how to use git or passively demonstrate by having a on-line accessible corpus of git-related work that shows your experience. You don't get a pass on that requirement just because the companies you've been working at don't use git and, well, you don't want to spend your free time learning git. And it is appropriate for the hiring manager to list that as a requirement despite claims that they'll be disqualifying some percentage of the candidates by including that as a requirement.

mythhabit 3y ago
I think part of the issue is also the complete lack of thrust. If you state that a candidate must know git, and the candidate say they do know git for basic committing, branching, merging ect, then fine - let's move on. I've learned that prior work history, talk and basic problem solving is in no way indicative of performance at all. I've found that the only guaranteed process to find excellent candidates, is hiring interns and part-timers currently finishing education, and pick the ones with the right mindset and intelligence.

zelphirkalt 3y ago

That is a fair view. Of course there is also a tendency of great engineers doing project in their free time, since they love what they do. There is also the fact that there is a higher chance of someone having learned a lot more, if they continuously worked on projects in their free time. There is also a higher chance to find people, who are not just into software development jobs, because they pay well, but because this is what they want to do. So for hiring engineers, I can understand when they hire with a certain bias. Sure, no one should be expecting us to do extra rounds, and sure, one can be a great engineer even without extra rounds, but the tendency is for that to take more years without that drive to explore in ones free time. And that's OK! I think it is fair though, if a company wants to hire a more driven/curious/exploring person.

deanrtaylor 3y ago

Isn't the general mantra around leetcode that you should be spending a few hours after work in the lead up to joining the interview process to get into the swing of it? What would be different from spending that time making a few PRs to an open source project or just building something from scratch to demonstrate your skills? A lot of engineers that I've worked with have never spent time on leetcode and struggle to answer the common interview questions that aren't easy or low medium, so personally I don't see it as that much different, there's time required either way. One is productive, one isn't.

kjkjadksj 3y ago
No other fields work like that. Computer science hiring managers need to figure it out. You have engineers in other fields who have long careers working multiple companies not even allowed to talk about what even occurred and its just routine.
- wakawaka28 3y ago
  Actually they do work like that. Engineers can be asked to solve problems in interviews. But the pressure doesn't seem like in software, where many people complain. There's no LeetCode equivalent for other kinds of engineering I think. But some of them do have licensing to deal with.
- ric2b 3y ago
  Those engineering fields have exams and certifications. Software Engineering is still too immature for that, I think.
  - BeFlatXIII 3y ago
    Software engineering is too easily self-taught for certifications to become the norm. The moment you have a cohort of people with demonstrable skills without such certifications, the value of the cert is undermined.
  - kjkjadksj 3y ago

demurgos 3y ago

Asking to be a regular maintainer for some Open Source project may be too much, but I expect an engineer to track down root causes of bugs. And if the root cause is in some Open Source lib, then they should do their best to fix it there. Even if they don't provide a full PR/MR, reporting the issue and engaging with maintainers is already great.