Yes, Ladybird is facing a wall of slop... no... A tsunami of slop overwhelms core maintainers. Probably safe to generalize to other popular open source projects.
The project is important and the code is beautiful! I spent many happy hours trying to understand the code, browser-specs and tried to adapt to their coding style. After 18 months I ended up with a few merged PRs. Some were pure joy to write. I got to work directly with most of their core maintainers in the review cycle. They're great!! From the outside, it seems like their responsiveness to submissions slowed down in the last few months... slop.
Of course, it would be great if there was another way, but here we are.
Love <3 to Andreas and the core maintainer group! Keep up the good fight! Maybe we'll meet again.
Mucho respect to the OP who was part of such elite fellowships as the "Bar Raisers" and "Hiring Committees" (and I'm sure he would totally have made it into the prestigious "As Appropriate" group at Micro$oft if he only applied for it).
My record is comparatively humble: I hired around 300 people in tech for small-to-medium size companies, in the small tech backwater of Vancouver, Canada.
My conclusions:
(1) Interviewing is an intractable problem. Start by recognizing that.
- You don't interview the best candidates, but the ones with the best resume.
- You don't hire the best candidates, but the ones that do best at interviews.
- Screening by HR (phone or zoom) is at best useless.
- Timed coding assignments are a waste of time. They are used because they're cheap + provide a [generally wrong] "quantitative signal". Noone's job will consist of solving 8 "leetcode" riddles/day.
(2) "Technology fit" is a dangerous illusion:
- It is very, very, very unlikely that any candidate will be able to pick up right away your tech environment. (ok; exception: you're hiring permanent an existing community contributor for your open source project)
- Your best new hires will be 0% productive in their first month (negative; training will use resources); 15% in their second; 50% in their third.
- Rejecting e.g. "Java" when screening for "C-sharp" is stupid.
(3) The interview process is about building relationships.
- People you don't hire will remember your company from the interview + disseminate.
- Someone you didn't hire today (one of your top rejections) may be super-attractive 2 months later, or next week if your top candidate accepted another position.
- Ownership of the process or at least buy-in from the team (vs. just the hiring manager + opaque "corporate committees") is the first step in a working relationship. Your "superstar" may end up being toxic in the team and you could find that out in the interview.
(4) Five simple rules:
- Treat phone/zoom screening like an advertisement for your company. Ideally do it yourself (hiring manager). Largely ignore feedback from HR :)
- Hire candidates who are: smart + hungry. Programming languages; frameworks; environments are secondary.
- Try to get a sense of the fit with the other humans in the team they'll be working with.
- Take "3-month probation" seriously. Explain it to the candidate + team. Sell it internally. Candidate compensation for a botched probation is reasonable + just money, after all.
- Treat candidates as humans: Send a personalized rejection (from you, the hiring manager _not HR_) to everyone who made it to the interview. Call or zoom everyone who made it to the final round. If you can, provide them actionable feedback on ways to improve their interview process. Leave a "human" door open.
All good points... I'll touch on some of them in future posts.
Planning a series of 8-16 on the future of software, incl. a call to action (2-3 months total).
Stay tuned.
Meta:
- Sad to see how well thought out + well written stuff like this only makes it to the HN front page by a fluke. (Below: https://news.ycombinator.com/item?id=48758048#48759391)
- @davidbessis: maybe look for an open alternative to Substack? (avoid bullshit, proprietary, gated access for quality content by humans).