Hacker News Reader

Comment by Derpdiherp | Hacker News Reader

Maybe it's the jobs that I've worked, or the country I'm in ( UK ). But I've really not seen this shift towards looking at portfolios of open source work rather than CV's. Every company I've worked for has requested a CV, and often does some form of test or in person interview centred around programming problems. The tests vary in quality and depth.

I wouldn't think of myself as a passionate developer. I have a family, I value my free time. I spend work time growing my skill set as it's required, anything else I do is rarely related.

I have a feeling that there's a silent majority of developers such as myself, that do enjoy programming and have a "passion" for it, but do not let this passion dissuade them from family time, or having more varied down time.

I think for a lot of people it's a dangerous game to be spending every waking moment working for a company, then spending your down time scraping together stuff for open source contributions etc.

I salute those that can and do though.

View on HN

On the hiring side, it’s rare to see someone come through with significant OSS contributions. A small bug fix here or there is about the most I see from 90% of resumes.

Every once in a while we see someone with a lot of open source contributions, or even full leadership of a popular project. These people would really prefer if we believed that OSS contributions and GitHub profiles replaced resumes or CVs, because it’s where they shine. Unfortunately, doing so would exclude many great hires who have done a lot of great work at private companies that doesn’t show up on their GitHub. We’ve also had trouble hiring prolific OSS contributors who spent their days working on OSS contributions instead of doing their job. One candidate wanted their contract to state that they could spend half of their paid time working on their OSS project. We passed.

In my experience, anyone claiming to have a single dimension credential preference for hiring (usually GitHub portfolio, Ivy League education, ex-FAANG) is simply hiring for people who look like themselves. They’re not a good fit for unbiased hiring.

Taking that a step further, we often actively discourage looking at OSS contributions during resume review for the same reason we don't offer take home interview assignments: it's biased against people who don't have a whole lot of extra time at home. When we have done either of the above, the singles who work part time have a bunch of time to perfect their work suddenly have a lot to show over the single parents who may be working full time or more.

I say "often" because OSS contributions can still be an indicator of something, but it's not really clear what. Maybe it indicates drive to contribute to OSS, maybe technical ability, maybe no hobbies or commitments outside their day job. In our experience it's often the latter, but even so, it's biased against people who don't have the time to contribute even if they desired to do so.

So we typically just stick with the resume for actual experience and college coursework, if any, but not the college itself. Using these heuristics we've managed to build a pretty strong pipeline of people with all backgrounds of education or experience.

Thank you!

When I was single I had a lot of free time to tinker and go through coding tests, etc, etc, and cater to whatever hiring shenanigans were in place.

First marriage, then a kid, and I find myself grabbing my laptop after work maybe once a fortnight. I'm always "open for new challenges" and I regularly apply to positions in interesting (to me) projects, but more often than not, at some point in their process they gimme some "take home assignments" that are a literal week of unpaid work. I've heard of companies that pay for those assignments, but I've never stumbled upon one.

I always drop out of that, thinking, "good luck with that particular choice of candidate sampling". I might not have been the best candidate, but most seniors I talk to are turned off by these things as well.

Timed coding tests are fine, up to 2-3h, I can squeeze one of those in most weeks. But, and I'm not making it up, "implement this subset of the MQTT spec in your language of choice" as just a step in the hiring process? Hell nah.

So I am married with kids and I have two separate careers in unrelated industries to balance, only one of which is full time though. Still I find time to spend with the wife and kids and I still contribute daily to open source. It is all about budgeting and balance. What are you willing to sacrifice. I don't have social time outside the family and I don't watch much television unless I am traveling away from the family. I balance open source against things like gardening and house maintenance but gardening and house maintenance only take so much time.

The biggest killers to my open source contributions are general life soul sucking killers. For me the worst is long driving commutes to an office. I can feel my soul bleeding away.

That's wonderful! You sound like a very driven person to be able to do all of that. Of course, your experience and ability shouldn't be considered the norm with everyone or expected of anyone, especially because with finite time in the day and differing situations, we must strive to judge everyone on the same plane.

> Of course, your experience and ability shouldn't be considered the norm

It is the norm in my line of work. I mean in my other line of work that isn't a software development.

Oh sure, sorry I should have clarified, I was talking about software development. I thought that was implied, but happy to be explicit.

I also find it strange how some people are so incredibly emotional about this subject like being punched in the face or having their car stolen at gun point.

I like programming as hobby so I choose to program outside of work. By no means is that sentiment meant to suggest any form of hostility. There isn’t even any competition implied.

I doubt I would be able to juggle 2 jobs with my current pandemic induced schedule. Basically, my time is spoken for during the week from 630am until 8pm. And that gets me 6 hours of work. I need to find 10 hours outside that time to get myself up to a 40 hour workweek.

I'm pretty lucky in that my wife is a stay at home mom. My sister in law has a dual income family. They basically never see eachother, because one has to work during the day during the week, and the other works nights and all weekend. They're lucky one of their jobs is so flexible.

During the pandemic many developers are working from home, so scratch off transportation. Most developers in the corporate world work 40-45 hours per including lunch, breaks, and distractions. So normally that could be something like 9am to 5:30pm. If you have flexible office hours you can push that to 7am-3:30pm.

If you are into open source you can spend 2 hours per night. Where you put that two hours is up to you, but you need to break for a scheduled meal. A scheduled meal ensures better nutrition and mental health plus some dedicated family time. This mean you program open source from 4-6pm or 8-10pm. Which ever you choose the other is dedicated time with the kids or chores around the house. Then you can spend about an hour before bed watching a show with your spouse.

You still need time to exercise and I find it’s better to do that in the morning with less mental fatigue so I will wake at about 5am.

When you need to participate in a side job that is structured time dedicated in a scheduled way, one or two weekends a month and occasional emails and a rare phone conference during the week in the evening.

Does your wife do all the cooking, housework and childrearing?

My wife works a part time job and chooses to do most of the cooking. She does most of the laundry but other house hold chores are spread out amongst everyone including the children.

I wrote open source initially because I wanted to skip those assignments but still be fair to the hirers and because it took less time and was WAY more fun than take home tests.

What I discovered was that they'd be willing to make me work 5+ hours on their assignment but wouldn't spend 5 minutes reading my code.

Though it wasn't my intention it inadvertently gave me a quick and easy way to filter companies which actively disrespect candidates' time.

It takes more than five minutes to review code, especially when it's of a volume you describe. You're also really trying to replace the metrics against which a company measures candidates and insert your own metric and then complaining that they don't use your metric. I wouldn't expect you to use my metric when interviewing me for your company, so don't think it's fair to try to insert your own metric for others (though you're welcome to vote with your feet).

It takes more than 5 minutes to thoroughly review code but you can learn a lot from only spending 5 minutes.

Ignoring it completely also sends a signal to the candidate. IME this red flag is usually paired with 5 or 6 other red flags.

We're having a bit of a debate about this internally as the company I work for is struggling to hire good candidates. For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations, but we've had many people in the past who've interviewed very well but turned out to be completely incompetent when assigned to a real project.

Maybe we're just really bad at interviews? It probably doesn't help that management here is almost entirely non-technical. There's usually a developer or two sitting in on the interview to try and balance it out, but I don't think any of us would consider ourselves particularly good at interviewing people.

>For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations

These are mutually exclusive things. Candidates who have more free time to code are more likely to be better at it than those who don't (all else equal). Candidates who have OSS maintenance / leadership experience are more likely to work well in teams (all else equal).

If you choose not to weight those things, to balance the playing field for people who have more obligations outside of work, then you'll also have lesser quality candidates (again, generally).

So if you're struggling to hire good candidates, maybe it's a good idea to weight these things (and bias against people with less free time outside work). Once you have good candidates, and this is no longer a pressure on your business, then it might be a good time to try and balance the playing field for new hires.

But you cannot balance the playing field and also hire the best candidates. The best candidates will have unfair advantages in general. You can either lean towards having the best or lean towards balancing the playing field.

We should try to eliminate irrelevant biases in the hiring process but we are fundamentally trying to select people to hire who will join our company and write good code. That quality is not evenly distributed in the population.

Some of the gymnastics thinking that I see seems to suggest that we’d seek to hire fluent English speakers by interviewing evenly across all populations. By all means, I’d be more than happy to hire someone fluent in English from China, but if I’m looking for a fluent English speaker, I shouldn’t spent 18.5% of my recruiting efforts/budget in China out of "fairness".

People in China often don't speak fluent English because they grow up in a country where it's not a spoken language.

People who don't contribute to OSS typically don't do it because they don't have the ability (some OSS code is held together by duct tape) but because they don't have time, interest or think it's harder than it is.

If you have better tools to determine if someone is good at writing code for your company, why use a proxy measure that's different in many ways?

Unless I’ve worked with you or someone that I deeply trust has and will vouch for you, I don’t have any stronger signal of your coding and teamwork abilities than a strong OSS contribution history can provide.

It’s rare for an interview process to provide more than 6 hours of content, some of which is non-evaluatable. Reference checks are all but useless compared to seeing actual work over time.

About 1 time in 6, you’ll interview a full standard deviation above or below your “true” ability. About 1 time in 50, you’ll turn in a +2σ (or -2σ) performance. That’s largely eliminated with personal experience, a trusted vouch, or a strong OSS portfolio.

> we've had many people in the past who've interviewed very well but turned out to be completely incompetent when assigned to a real project.

Unpopular opinion on HN: This is actually quite common when you hire based purely on resumes or credentials. Some people are really good at interviewing and being charismatic enough to convince people to hire them. There are a lot of candidates who can talk the talk but really just want a job where they can browse Reddit and Twitter all day while writing a couple lines of code every once in a while. There are a lot of companies that are big enough for these people to blend in for years.

Take home tests in the range of 1-4 hours shouldn’t be an undue burden on any applicants, if you give sufficient time to return the test. Many candidates wouldn’t bat an eye at taking a day to interview on site, so asking them to spend a couple hours of their free time on an interview isn’t really a disproportionate ask.

Giving someone a 20-40 hour take home project would be ridiculous, of course, but reasonably sized problems are perfectly reasonable.

We spent some time on making up a quite simple project with a readme about the tasks to be implemented. It's something that can be done in half an hour when you are fast and we always thought we need to make it a bit harder. Turns out it's good enough to weed out quite many people who can't keep a deadline or don't get their shit together in other ways. From reviewing the code you can judge how people think, if they keep their files and code in order, use git etc. We also prompt people do document their process in finding a solution.

Interesting, could u share a bit more pls?

We made up a problem with technologies that we use at work targeted at frontend engineers. So we set up a project with a Symfony backend and made the candidates create Twig templates and SASS styling based on Bootstrap. Then we put that up on Github with a README. So the candidates could focus on the frontend stuff without caring for the backend. Still they had to figure out how to set up SASS compilation and modularization of Twig templates.

As I said it's not very hard but you can get bonus points if you come up with considerations for responsive design or stuff like that. Overall the aim is to create readable idiomatic code and not come up with something clever that no one but you can understand.

I guess that's a very specific task that's of no great use to others but the point is to have a specific problem with some blanks that can be filled out with a reasonable amount of work by the candidates. Plus the general workflow using git and such.

What you may be missing is how hard it is to actually create a good take home. Every take home test I’ve seen was rife with potential for the problem to explode in complexity. Even things that seem simple like names and dates have so many potential pitfalls that it can be impossible to tell as an applicant whether they intentionally laid a trap or not. Then there’s the incidentals, should I send them a docker image to increase the odds it’ll work on their machine? Oh, they’re going to want me to extend this in real time, should I include other nice to have services that this problem could dovetail into needing, like redis?

As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes and largely biasing against experienced devs who aren’t as likely to waste their time. And worse with a take home, is that they have no skin in the game. With an in person interview they lose at least as long as the inverview. With a take home they lose nothing except short email exchanges.

Take homes are easy to iterate on. If multiple candidates can’t understand the problem or waste time with over-complicated solutions, you update the instructions.

If you’re constantly worried about “traps” then you might not want to work for those companies anyway. Take homes should be straightforward and similar to solving real problems.

> As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes

Take homes are contrived problems, not real work. Every candidate receives the same problem so they can be compared.

No company should be giving employees actual unpaid work to do as part of the interview. That’s more of an internet trope than a real problem because no rational company is going to be sending their codebase to applicants to add features to.

A code comment saying “Here’s a potential pitfall we could discuss addressing” is often more valuable than a solution. Every software project has more problems than it has people-hours available. Every team has the engineer who spends a week fixing an edge case in their ticket that no customer cares about. Demonstrating awareness of this makes you an attractive candidate.

> What you may be missing is how hard it is to actually create a good take home

The biggest issue I see are people underestimating the setup time for "simple" projects. You're a big software company that doesn't start new projects regularly, I'm a developer at a big company that doesn't setup new projects regularly, why do you expect me to remember how to setup "professional quality" projects in a couple of hours?

A simple console app might test if I can code, setting up a new MVC project with authentication, unit tests, IoC, etc is testing how well I can google shit I haven't had to setup for years.

> Some people are really good at interviewing and being charismatic enough to convince people to hire them.

Totally agreed. Traditional interview processes select for people who are good talkers. That doesn't correlate well with technical skill: you over-hire glib people and under-hire people who aren't. E.g., the shy, awkward, and anxiety-prone.

When I run an interview process, I focus on making it as much like real work as possible. Some pair programming, some technical discussion, some joint product collaboration and systems design. It's my firm belief that if we want to know if people can do a thing, we should try doing the thing with them. It's not perfect, but it's way better than asking people about their 10-year career plan or having them solve Mensa puzzles.

>Traditional interview processes select for people who are good talkers. That doesn't correlate well with technical skill: you over-hire glib people and under-hire people who aren't. E.g., the shy, awkward, and anxiety-prone.

This is true: but "technical skill" is not the ONLY hiring criteria that should be considered. (I say this as a fairly shy, awkward and anxiety-prone person, who has had his share of interviews-gone-wrong).

I'd posit that you DO want to hire people who are good talkers, and are glib. They help build teams. They help with information flow. The greatest ideas in the world are worthless if they can't be executed by a team that doesn't understand them, and the person who came up with it can't communicate that idea effectively. One might say that that is what code is for. But that's not true. If code were to communicate between the developer and the machine, we'd all be writing in machine language. Code is a communication tool for developers to collaboratively tell the machine what to do. And that has to be supplemented by human, interpersonal skills. (especially when you have collaborators who are not coders, like business and finance people who organize the teams and manage projects and programs).

I like that you focus on pair programming. One horribly toxic factor I see at way too many places is where management pits programmers against each other like it's some kind of competitive sport, and collaboration is frowned upon because "if you can't figure it out by yourself, you're a burden on the rest of us".

I am certainly not arguing for only hiring based on technical skill. Perhaps you didn't get the chance to read all of my comment, but I make it clear collaboration is important. I'm also not totally sure you know what glib means, so I'll just quote the definition here: "fluent and voluble but insincere and shallow".

Basically, I think workaday collaboration and communication is a pretty different skill than on-the-spot glibness. If I'm hiring a PR person or a press secretary, glibness is a valuable skill, because an important part of their job is to talk over people, to favor sounding good over consideration or substance. But for a software team, I value more substantial engagement and communication. So no, I'm happy to hire people who are not glib. Have done before, will do again. And for those who do happen to have the gift of gab, I want to be sure they have it in check and only deploy it when necessary. A colleague who can say, "I don't know" is way better than one who glibly avoids that out of pride.

> A colleague who can say, "I don't know" is way better than one who glibly avoids that out of pride

An interesting interview question could be to study the job applicant's background and then ask questions that, given the background, s/he doesn't know -- then, will s/he tell you this, or make up nonsense

It depends on when in the interview process you give the task, and if they're interviewing with any other places. If two places do this, a person now needs 8 hours or 12 in the week you give them. Ask for the task to be done before properly interviewing them and that presents more problems I hope that last one dies.

I would find 4 hours a lot. It is basically wholw afternoon.

Ever been to an onsite interview? It'll take you the same amount of time. Or longer. While being far higher pressure. And probably involve writing code on a whiteboard instead of an IDE.

I was not on over half day long interview that would primary involve whiteboard coding.

Does a take home eliminate the onsite interview? Or is it just additional time?

Even if it is additional, it's not consecutive. The OP merely said 4 hours seemed like a long time. My point was not that this 4 hour block would or wouldn't obviate the need for the other; just that the other means 4 hour blocks are standard.

Although, if you wanted them to do a longer project, Basecamp’s method where they pay the applicant to do the project seems like a good way to do it. And you’ll get the most complete picture of their expertise (of course, you wouldn’t want to do this until the last step of the process).

This can get sticky with employee contracts, that may (and likely do) forbid an employee from doing contract work for another company, at least without permission.

I don't know how receptive your management would be to this, or what it costs, but at my last job, all interviewers were required to take interview training. It made a real improvement in my ability to suss out a candidate and understand what they could actually do vs what they claimed they could.

> We're having a bit of a debate about this internally as the company I work for is struggling to hire good candidates.

What's the compensation like? Stock?

> For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations

You'll also find out that the people you really want to hire are not on the market for a long time. So if they are interviewing at several places and you give them a 4 hours take-home, they'll put it on their to-do list but by the time they get to it they might be in the final rounds at 2-3 other places that brought them on-site immediately.

> It probably doesn't help that management here is almost entirely non-technical

That's a much bigger issue than most assume.

> There's usually a developer or two sitting in on the interview to try and balance it out

That's a huge no from me. Final approval of a technical candidate should only be in the hands of the technical staff.

I've heard horror story of a "senior" engineer from "his country's top school" being interviewed for a technical position by several non-technical managers and HR reps. They only included an engineer in the final round, which was basically supposed to be rubberstamped anyways. He was then asked to implement something trivial like fizzbuzz or wordcount on the whiteboard. The candidate then became extremely defensive and tried to argue that such task was "beneath him", arguing for a good 15 minutes why he shouldn't have to do it.

Then the dev just left the room and said that he used this question as a warmup with new hires and it typically takes them less than 10 minutes.

A lot of senior engineers would refuse to do a fizzbuzz. I'm really not seeing the problem here.

On the contrary, I think this is a huge red flag. Just go along with the interviewer, maybe highlight that this is typically and entry-level problem, but solve it. You really don't want to hire someone who not only can't solve fizzbuzz, but also refuses to hear about it and complain that it's 'beneath them' (what a annoying attitude!).

Depends. It could be an indication that there's been a miscommunication and the interview is for a much more junior position than expected, so I would expect a more senior person to push back. Fizzbuzz tests "can this person program at all?" For a more senior position, best to start with something harder and more job-related; back off to fizzbuzz if the interviewee can't do the hard stuff.

FizzBuzz typically gets raised eyebrows from folks who never had to do it because they assume there's a trick somewhere. It can't just be a one-liner they assume.

https://blog.codinghorror.com/why-cant-programmers-program/

Of course it's not, there's always a better way: https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/

100% of those who can't code would refuse it indeed!

Imagine you're a senior developer with over 10 years experience. You're happily employed and make good money. You're contacted by a recruiter for an interview. Perhaps the company even uses some software you wrote.

"Ok this problem is called fizzbuzz. We just need to see if you can really code."

It sounds like the situation was of course different, but situations like above have happened.

I don't need to imagine it: It happened.

I laughed and wrote the solution on the board.

> we've had many people in the past who've interviewed very well but turned out to be completely incompetent when assigned to a real project.

There is absolutely nothing wrong with coding test. Timed with internet. The one that does not tests for algorithms, but for basic competency. For example, ask them to parse some data out of xml file and give them tons of time. That will check competency without being burden.

Yes, non tech managera sux at recognizing who is good programmer in discusion. But, so do programmers and technical people. It is easy to pretend competence if you read enough blogs and can project right attitudes.

> Maybe we're just really bad at interviews? It probably doesn't help that management here is almost entirely non-technical. There's usually a developer or two sitting in on the interview to try and balance it out, but I don't think any of us would consider ourselves particularly good at interviewing people.

This seems to be the issue, in fact it's quite baffling to me. If you are interviewing for a technical role, why would you not perform a technical interview led by technical staff?

I'm not saying the other stuff is not important as well, but this reads to me like you are essentially leaving the core of the role out of the interview (I'm not sure what "usually a developer or two are sitting in as well" means).

Our take-home obviously isn't a trade secret, so we have three trivial problems in ours:

1. Write code that takes in a rectangle, coordinate, and distance, and tells if that coordinate is within the distance of the rectangle.

2. Determine whether a string has permutations which are palindromes. (I'm of the opinion this one is too simple, but it's been fascinating seeing what mental gymnastics some developers will go through to solve this problem)

3. Write a CLI dice game (we provide the rules) in which the computer player wins 70% of the time. Make the method by which the computer cheats undetectable (of course this is impossible, but candidates just give it a best shot and we talk about their approach in the interview).

Assuming the test passes muster, we have three interviews right now, I think. One with managers to talk about the role, one with senior devs outside the team to perform the technical interview, and one with the devs in the team to talk shop.

In the technical interview, we primarily go through their test solutions (we do no whiteboard coding aside from reviewing the test and even that's very loose - not actual code). We have hired candidates before who have failed some of these tasks (mainly our candidates have trouble with #1) but who showed a capacity for being able to think on their feet and correct their mistakes during the interview. Of course a candidate who aces the test is going to have an advantage, but absent having the right answers, quick thinking/adaptability is probably the #2 trait we look for that seems to be a good predictor for developer success.

Every candidate we've hired through our process has been a success (which could be dumb luck, since none of us are super experienced/knowledgeable interviewers either, but we wing it best we can) and the take-home (and, equally importantly, the technical interview) has absolutely helped us weed out candidates with impressive CVs whose test results did not measure up.

2. Determine whether a string has permutations which are palindromes.

If I understand this correctly, it's the sort of problem that's simple if you see the trick and hard if you don't. I'd expect many candidates to think that you actually want them to generate all the permutations and then get bogged down in recursion.

#1 is good, and #3 sounds interesting.

> I'd expect many candidates to think that you actually want them to generate all the permutations and then get bogged down in recursion.

Ideally the candidate should realize that this is computationally infeasible and quickly come up with a much more efficient solution, right? Perhaps they believe that this question filters out people who 1) don't have a feel for what is computationally feasible 2) will just dive into coding without spending 10 seconds to see if there's a significant optimization.

Closes IDE and feels relieved to have dodged that bullet.

> 1. Write code that takes in a rectangle, coordinate, and distance, and tells if that coordinate is within the distance of the rectangle.

Distance from the center of the rectangle? Easy. From the closest corner? Easy. From the closest point on the rectangle? I'm not clear how to do this.

And will the sides of the rectangle be parallel to the x and y axes?

Break it down into cases. Is the coordinate closest to a corner, or to some point on an edge? You can determine that without actually working out any distance - play around with pen and paper and hopefully that will become clear. Then calculate the distance to either the relevant corner, or the relevant edge.

It's easiest to think about an axis-aligned rectangle, and you can convert any problem to have an axis-aligned rectangle by rotating everything.

I see. Thanks!

Quite a few pitfalls there, though. If I was doing computer graphics often, the geometry wouldn't be a problem I guess. But I've not done any such thing in decades.

If the job needs the geometry, then it might be a useful question to ask.

Oddly, the last technical interview process I went through was the best and in some ways, the most old fashioned.

There were three "rounds":

1. Phone screen with actual lead developer. There were some quiz-y questions here, which I'd previously thought of as a silly outdated approach, but it honestly was a low stress filter for basic technical knowledge.

2. 90 minute pairing exercise with the same lead developer. We built a small example app together. Resources were sent over ahead of time so my environment was good to go, and the expectation was set from the start that the goal was to assess how I thought and approached code, not to see how far I could get in 90 minutes.

3. 4 hour "on site" where I talked to each developer on the team I'd be joining. No technical exercises. Each person came with their own questions, and expected me to ask mine.

What I took away from the experience was that companies are seriously overthinking and over-engineering the process. There isn't a magic heuristic you're going to discover that will identify "10x engineers." You can vet if someone is technically competent enough for the role, approaches software in a way that gels with your org, and if they have any red flags in fairly straightforward fashion that doesn't require enormous amounts of prep for them or your team.

I've written a fair bit about hiring processes on my blog. My most recent post about is at https://blog.urth.org/2019/07/11/a-technical-hiring-process-...

We use this process at my current employer, and we've gotten mostly good feedback about it (including from people we didn't hire), though some candidates don't like it. The people we've hired using this process have been quite good, though I can't say if that's the process or something else that leads to that outcome.

I prefer to look at everything the candidate has to offer.

Don’t penalize people for not having OSS contributions, of course, but it doesn’t make sense to ignore them. Whatever credentials the candidate brings to the table should be taken into consideration.

Not everyone has the opportunity to go to colleges or get a first job at a well-known company. If someone chooses to prove themselves via OSS contributions, let them.

>I say "often" because OSS contributions can still be an indicator of something, but it's not really clear what.

It's a fairly clear signal of skill quality and attitude.

Reading open source commits/PRs and issue trackers tells you quite a lot about a developer which you can't see without some sort of a test (often not even then).

>it's biased against people who don't have the time

Surely any career that requires a high level of skill and practice honing that skill is biased against people who don't have the time?

What's special about open source?

It's not about merit but about bias

You generally become better with more practice though, right? Whole 10,000 hours thing? Surely someone who spends more time developing will be better at it.

Now of course this doesn’t matter past a certain point — people could spend all their time working on something that doesn’t help them grow.

Then once you have those 10,000 hours of actual growth, you are probably close to a Senior developer level. Which after 5 years in an office job working 40 hour weeks, you’re there anyways.

But at the earlier levels of developers, it seems that working on projects outside of work would definitely help you improve faster!

I trust that all that practice would make someone interview really well, no need to look at how much practice they've had as a metric.

> You generally become better with more practice though, right? Whole 10,000 hours thing?

Except that 10000 hours thing is non scientific nonsense.

To improve, you have to practice right way. If you code for 8 hours at work, coding 2 further hours wont make you improve more. Similarly, if you want to improve in music or running, just playing songs or jogging means you will hit plateau pretty fast. After that, you have to train on correct selection of exercises.

At that point reading some theory will have much bigger impact, because yoi are doing something new. And even exercising will likely make you improve more due to what it does to body then further 2 hours of the same.

>If you code for 8 hours at work, coding 2 further hours wont make you improve more.

A) I'm pretty sure almost nobody actually codes 8 hours at work.

B) Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.

> I'm pretty sure almost nobody actually codes 8 hours at work.

The non-coding parts of work are necessary on oss projects too. In any case, programmers work being mostly coding + code review is pretty normal.

> Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.

That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software, it will be more of the same after a while.

>The non-coding parts of work are necessary on oss projects too.

IME a far greater % is coding. There's also a lot of OSS people involved who don't code who help out with the other stuff.

Moreover, a lot of the stuff that "isn't coding" is a strong quality signal - how the developer interacts with bug reports for instance.

>That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software.

It'll still be different to what you do at your day job and will necessitate picking up a different set of skills and a different perspective.

> IME a far greater % is coding. There's also a lot of OSS people involved who don't code who help out with the other stuff.

It was not my experience. In work, the proportion of coding was bigger then when I maintained open source one. Mostly because company paid people to do other stuff. In OSS, afaik, it is was more of rare to have dedicated tester or to get already analyzed input. Also, the planning, organization, documentation, keeping tickets clean, decision making and so on are all on you. The ratio of project work is the same.

> It'll still be different to what you do at your day job and will necessitate picking up a different set of skills and a different perspective.

Maybe yes, maybe not. And after a while of maintaining the same software, you already maxed out what you learned. Moreover, you can learn new stuff without having side project. It has advantages, because then you dont have to finish and polish stuff. You just learn or try what interests you.

Lastly, side project is really not that dissimilar then working on the job - meaning job+side amounts to 10 hours a day work basically. It means your hourly effectivity will go down exactly like all studies on crunch predicts. You will get tired and slow.

as someone heading towards 5 years developing, I'm not sure it's as straightforward as you think (and if it is, I'd love advice on how to improve). In my career so far my work has roughly gone in phases of backend, frontend, devops/infrastructure. I've been able to improve my soft skills of learning how different organizations work, learning how to network and collaborate, learning how to learn, etc, and improve my technical skills of development, learning about best practices, etc, based on the particular technologies I work with at a given time. But I haven't had the chance to just spend 5 years progressively leveling up my java backend or javascript frontend skills. As a result I don't think I would qualify for a senior developer level quite yet. But by that token, perhaps I'm also not the best person to say whether or not this is the typical path for a sr dev or not

I've seen this on Reddit a fair bit too but there's this sort of anti "10x-er" attitude. It makes logical sense to me that if someone spends more time practising a skill, then they would be more proficient and thus worth paying more. Yet there's a lot of pushback against that thought process because it is biased or something. Obviously there's more to a candidate than purely 'coding' skill but I find it weird that a company would want to explicitly avoid an indicator of time spent honing skill X purely because it discredits other people. I guess in an idealistic world it makes sense but the real world never quite lives up to the ideals.

I've found that a lot of hiring is explicitly biased against skill. The root cause is mostly the hirer wanting "people like me". Or, at least, not discriminating against "people like me".

I'm sure a lot of people who hire developers think of themselves as people who could write open source but don't have the time.

This also accounts for why stuff like leetcode persists (the hirers were successfully selected by that process), why top colleges are often preferred and even why the profession is predominantly white/male.

So you'd consider it anti-meritocratic?

Yes it can tell a lot about people who have the bandwidth to be able to be able to contribute to such. Others may and do have the same level of skill but didn't have the bandwidth to contribute to PRs, so by looking at PRs as an extra we're effectively penalizing those without time, which has the practical effect of biasing us against people with kids, people with a full time job and in grad school, or you name it. We shouldn't be biased against those people.

Any career, especially in our field, requires a high level of skill. We try our best to level the playing field for everyone while still getting a lot of signal in the interview process so end up eschewing things like school attended, talks given, OSS contributions in evaluating candidates. Anecdotally we've seen little correlation with these sorts of things and interview ability or ability at the job after being hired.

>Others may and do have the same level of skill but didn't have the bandwidth to contribute

And even more have the potential to become excellent coders but didn't have the bandwidth to develop it.

It seems peculiar to single out one quality in particular that sends a clear signal that a skill has been honed on the basis that it took time to hone that skill.

All skills take time to develop.

All skills to take time to develop, well said. I am confident that looking at how a candidate interviews will no doubt show the fruits of that time spent without weighting too much the time spent, regardless of whether that time spent comes from contributing to open source, from their full time job, or just studying and honing their skills efficiently under harsher time constraints. We don't want people to target the metric of "time spend coding on OSS projects" do we? I don't.

Besides, having a diverse experience base and pipeline (parents, non traditional developers, non traditional paths to SWE, and even single people with a ton of time and fortune to be able to do things like robust side projects) has served us particularly well in having a team with a wide breadth and depth of experience and viewpoints. Specifically weighting side projects in lieu of technical/EQ interview performance would ruin that in favor of the latter group.

>We don't want people to target the metric of "time spend coding on OSS projects" do we?

Nobody said that we did.

This is about ignoring OSS contributions vs. reading them taking them into account - i.e. deliberately ignoring a signal of quality because it might, for instance, discriminate against people who chose to have kids.

I find it particularly ironic coz part of the reason I wrote open source was to save time - to skip wasteful technical interviews that it ought to be obvious are unnecessary if I have public evidence I can code well.

We don't ignore them completely, we just weight them very, very low, as I've indicated. They do provide context. Your phrasing "chose to have kids" betrays some of your underlying beliefs, I suspect. We'll likely just agree that we weight things differently and are willing to forego some otherwisee excellent candidates to index more heavily on being fair to everyone in the process and judging them to the same standards. This is a conscious choice, and so far a very good one.

To your second point, I can't think of a single thing I would let be a proxy for technical skill in an interview process -- certainly not some commits to open source. (Maybe if I had worked side by side with the person in a previous life would be weighted) Even if we did use that as a proxy, it doesn't really save time because people would have to inspect the work and still doesn't really tell me anything about the candidates approach to problem solving or framing of issues that I can get from pair programming or walking through some code for an hour.

I applaud all your open source contributions and appreciate them, but I wouldn't consider them in whether to hire you except perhaps at the margins. Others may disagree and that's their conscious choice or they're indexing on something different.

>Your phrasing "chose to have kids" betrays some of your underlying beliefs

I did suspect that underlying your opinion was a desire to discriminate in favor of parents/against non parents.

This would fit in with the double standard I highlighted in my first comment.

This was also because you mentioned "parents" in the context of diversity (which is weirdly unique). I threw that phrase out there to see if it triggered you.

>To your second point, I can't think of a single thing I would let be a proxy for technical skill in an interview process -- certainly not some commits to open source

I've not worked with a huge number of developers who have made > 3 significant pull requests to a serious OSS project but every single one has been stellar.

I've worked with a lot of developers who can do the cracking the coding interview dance who sucked and even more who interview well in other ways.

I don't discriminate in favor of or against any particular group and am not a parent myself, though I have parents. I do recognize that many parents are often particularly overworked and can't jump through the same hoops you have time to jump through, which is why the example came to mind. That's all, no offense or "triggering" (???) intended and apologies if it came across like I was trying to rile you up. Per HN guidelines, you should be taking the strongest form of any argument though, to be fair. Regardless, I think you've gotten your point across and I believe I understand your motivations.

We OSS contributors with kids are in the worst spot! :)

You need time.

A full time job and small children for example don't leave much space for extended coding sessions on side projects, unless you're lucky enough to need little sleep.

I've worked around this by learning at my day job : read books/papers at home (this is relaxing), and look for opportunities to apply this knowledge at the office. Unfortunately, it stays at the office though, and can't be shown as proof of your skills outside of the company.

> for the same reason we don't offer take home interview assignments: it's biased against people who don't have a whole lot of extra time at home.

This is just another single dimension hiring credential, that will result in limiting your hiring pool to people like yourself. My code ran on 70+ million machines last month, but I've come to decline any timed or proctored technical interviews.

It's not that I'm too good for whiteboarding or timed tests, or that my options are so open that there isn't significant cost in doing so - quite the opposite: I'm come to find the process so traumatic that going through with it isn't worth it for anyone involved: those jobs just aren't open to people like me.

We look at CV and then have an interview process. We don't do proctored timed interview coding questions in the usual sense, though we may walk through code. I understand the reluctance of a senior engineer such as yourself to go though any interview process, but to be honest I've interviewed plenty of engineers with decades of experience and many have completely fallen flat. Interviews aren't just about technical knowledge, but also to make sure people will get along and are reasonable to work with.

I think we'll agree that there has to be _some_ interview process. iirc node's Left Pad package is downloaded like 20M/mo.

Yes, that's very different, and much more reasonable than most places that don't do take home technical examinations.

There's obviously a fundamental necessity to evaluate a candidate's technical skills directly, rather than relying on credentials - my issue is with the false expedience and conflationism of timed and artificially performative technical evaluations, and my personal difficulties with the social requirements inherent to them.

Agree

> we often actively discourage looking at OSS contributions during resume review for the same reason we don't offer take home interview assignments: it's biased against people who don't have a whole lot of extra time at home. When we have done either of the above, the singles who work part time have a bunch of time to perfect their work suddenly have a lot to show over the single parents who may be working full time or more.

Or their company ships a product that has a huge dependency on that particular OSS project, so they are doing the work on company time.

How do you interview people who are changing industries then? The only way a cook or a librarian can get out of that and into software could very well be side projects and open source contributions. With your heuristics, you'd only consider their cooking experience and say "well that's not software" and pass.

Specifically I don't hire entry level people, so that hasn't been an issue. But if I did, I would likely look at projects and such, general aptitude, etc. because that's all there is.

This is bad for applicants who may be at dead-end jobs that don't provide much meaningful development experience, so instead choose to self-learn and/or contribute to OSS to fill the void.

Not saying your strategy is bad, just that you might miss some good candidates.

I've seen a lot of candidates put their GitHub link in their CV. When I go to check it out its usually full of half completed Django tutorials.

Oh no you actually looked at it??!

> On the hiring side, it’s rare to see someone come through with significant OSS contributions

Do you mean it's rare to see someone hired, or rare to see someone in the hiring process?

Because if it's the latter, that's exactly what I'd expect too. People with very significant and visible portfolios aren't sending their resumes because they don't have to.

Companies should have different hiring processes for prolific open source code contributors and folks that don't do open source (presuming they want to hire both).

There are plenty of amazing developers that don't to open source and are great employees.

Other devs have extensive open source code. It doesn't make sense to give popular open source devs coding tests. Open their GitHub account, see their popular repos, see how they communicate on issues, etc.

The most powerful teams I've worked on have a mix on OSS devs and folks that only do closed source work. Hiring both is the best from what I've seen.

> One candidate wanted their contract to state that they could spend half of their paid time working on their OSS project. We passed.

I like the dudes honesty. He would not be doing OSS while pretending he is working for you. He is also leaving himself time for other things.

It seems to me like fair way of doing things. Company like yours passes and maybe another one will take it.

> ... it’s rare to see someone come through with significant OSS contributions

Because these people rarely apply for a posted job opening.

My favourites are people who have some personal projects (finished or not) to show. They're usually more interesting and telling than open source contributions, though I definitely respect that.

I'm hiring a few engineers right now. I agree that some companies exploit "passion", and that companies doing that tend to over-weight weight things in a way that encourages having no life. I think that's a mistake.

That said, I do think some sort of "passion" is really useful. I've been coding a long time. I'm on something like my fifth major language. My first computer had 4K of RAM; now my phone has a million times that. I can't even count the number of business domains I've had to learn. I can't imagine people keeping up with the pace of change in our field without finding ways to love the work.

In contrast, I've worked with people who learned enough to be employable and then just kinda stopped. I remember one guy, a great manager, who kept giving technical advice based on his Vax BASIC experience at least a decade past the point it was sensible to do so. Or programmers who had basically become fused with legacy systems, only employable until the old code was replaced. It's not impossible to make a career of out that, but it's risky.

Especially given the release cadence of modern frameworks and tools, I think continuous learning is vital. And I think keeping up (or better, keeping up and getting ahead) is much easier to do if people really enjoy the hour-to-hour details of the work.

I know exactly what you mean, people being proficient in some very specific legacy domain (Vax BASIC is a good example, another might be AS/400/IBM i by now). Often going above and beyond in their niche expertise.

Though it's hard to get a full picture. Maybe past gigs or other circumstances have given them enough financial stability that they don't strictly need to work anymore. They then continue consulting out of passion for their particular niche, or somewhat opposite because they don't have any drive to learn anything else, but still don't want to retire completely. I feel like the people I have in mind there seem to be in a more good than bad situation.

But I've also encountered the other category you're hinting at, people who are fused to a legacy system (i.e. a particular project at a particular company), not a technology in general. A few friends of mine do that, and they are much younger and much further away from feasible retirement than the aforementioned "gray beards". I sometimes do wonder about their prospects, but, again, no full insight.

Definitely. If somebody is winding down their career, I totally get just sticking with the thing they know. A couple years back I decided I wanted to try my hand at building a mobile app. Starting from square one kinda sucked; suddenly being bad at something I am used to being good at was a drain. The ROI on a switch like that depends a lot on how many years you expect you can be putting the knowledge to use.

And yeah, I too worry about people who do that early on. Some things will probably last. E.g., I'd bet that Salesforce admins will still be employed 30 years from now. But the odds are not as good for most technologies in use today.

I find passion and fascination leading to a drive to learn better, faster or quicker, depending on the personality. But I harvesting passion in commercial settings is quite disingenuous. Some people don't have that passion and do quite well, they are in fact very rational and calculated and that is a good thing in some ways as well as those who are more passionate about more abstract things, there is room for quite a variety of types of people and they should all be given freedom to use their own qualities and not be forced to fake qualities that they don't have or are unwilling to share with others.

I think perhaps words are getting in the way. I don't think passion and reason are contradictory. I think they're complimentary. Competitive chess might be a good example. And plenty of people here are both passionate about various technical topics, but still are very rational about them.

I agree that people shouldn't fake qualities. But neither do I think everybody will be equally good at every job. E.g., I can do sales, but I just don't like it. I'll just never be as good at it as somebody who really enjoys the work.

Same here in the US. Forums like HN and /r/cscareerquestions overrate how many people do OSS or care about it. I think maybe 5% of devs I've worked with do anything beyond the 9-5.

There's also a chunk of us in the middle, who don't do open source, but still learn and have our own projects outside of work hours.

cscareerquestions is heavily weighted towards graduates fighting tooth and nail to secure a first job with companies that mostly view them as an undifferentiated commodity. There's way more supply than demand.

It probably is a better way for graduates to differentiate themselves than experienced engineers.

I never quite understood that advice. I've worked for multiple FAANGs and have no OSS or really any online presence tied to my name. Just practicing interview-like problems in an interview-like setting is a far more efficient use of time than doing random OSS work if the end goal is to get hired. Those companies really don't even look at your commits to their own codebase when they are considering promoting you - they aren't going to delve through your open source projects to hire you.

Just do things like implement a heap or boyer-moore in pseudocode or python on pen and paper without referring to google.

In Australia, and I concur. No one expects you to have OSS contributions and it's enough to have work experience.

Thank goodness. I didn't spend all these years working for it to be ignored in favour of a few hours a month patching people's shit for free. My work experience is also 9-5 week after week of solving real business problems, which can be messy and requires pragmatism. Just working on OSS doesn't prepare you for work, it's a great start, but OSS projects are often very clinical, perfectionist and academic. Work has messy business requirements, legacy code and the need to deliver good work in a timely manner.

If I had to start as a new developer again, I would still just do pet projects, not OSS. You can be very targeted in your demonstration of skill with a pet project intended to get you a job.

I can probably give the impression of a passionate developer because I'm self-taught and one of the things I like to do in my free time is write code.

Still clock out at 5, though, and you can be sure I'm not going to put work Slack on my personal phone. My time is my time.

I look to my art manager colleagues (I work in video games) with some envy, because their interview process is easier due to art candidates having portfolios.

We just don't have that in the software industry, at least not portfolios that we can legally share or that other employers would trust, so we end up essentially torturing each other with coding tests.

I don't think everyone having a portfolio of open source code is a reasonable ask, but the idea of portfolios, if we could create them, would bring some sanity to our industry's interview practices.

I have been a workaholic all my life and always worried sick about my job to the point of making my family feel neglected. We have all suffered together for years. I am good at what I do for a living, but I have been on tenterhooks all the time to see if my company will show me the door or close down, and now, since neither was ever the case in my roughly 20-year career, I don't know whether to laugh or cry! Currently, I am on a sabbatical to get things in perspective and mend my fences.

> I have a feeling that there's a silent majority of developers such as myself, that do enjoy programming and have a "passion" for it, but do not let this passion dissuade them from family time, or having more varied down time.

I think you're absolutely right. For me (he said, ironically, whilst responding to a post on Hacker News) it's just not that healthy to spend even more time sat in front of a computer programming away than I did at work.

As it happens nowadays I don't spend that much time at work programming so this does tend to make me more inclined to do so outside of work. But everything has to be in balance: I have family, I have friends, I have other interests. I need to spend time with family, with friends, and pursuing those other interests, otherwise I start to go nuts.

So no: I do not have a plethora of OSS contributions, nor will I ever have. My side projects aren't OSS and, at present, I have no intent to make them OSS. I'd need a motivation that I simply don't have in order to do that. Moreover my side projects are things that I find fun, that probably aren't very generally applicable, and that some would see as frivolous - but I deal with enough serious business at work.

In any case the thought of entitled internet randos getting in touch to demand free support because I've written an OSS library, module, or tool that's accidentally become somewhat popular and is now included in other modules and is used by corporations around the world who make tons of money in some tiny part off the back of using it is deeply unappealing.

Not that if you want to spend your free time on OSS there's anything wrong with it - far from it. If you love doing it then have at it and more power to you. But we need to dispense with the idea that this is for everyone any more than photography or collecting vinyl is for everyone.

> I wouldn't think of myself as a passionate developer. I have a family, I value my free time. I spend work time growing my skill set as it's required, anything else I do is rarely related.

Clearly you've never met devs that have no passion. They will actively refuse to learn new things and have absolutely no interest in doing so.

If you look at other professions, growing skills and staying up do date is supposed to be done during working hours and is budgeted for. A lot of 10x I've met were parents and had a pretty strict schedule. Whatever time they had in the office was 100% dedicated to shipping results or growing and they had to be efficient at it because there was no way they would spend less time with their families.

I’ve applied to hundreds of jobs and I can count on one hand the number of times my GitHub was looked at.

Reply on news.ycombinator.com