It's also worth thinking about the timeline inclusive of hiring delay. More detailed requirements makes hiring slower.
I know 2 startups both hiring their first set of non-founder engineers.
One startup took 4 months to hire 2 senior engineers who weren't in their stack and then gave both of them about a month to come up to speed on the tech. Literally running tutorials.
So 5 months in, they have two onboarded senior engineers.
The other startup is 6 months in and hasn't made either hire. They see deep experience in their tech stack as required and don't want to wait longer for onboarding.
But in retrospect, they would have gotten to an onboarded team faster if they had hired like the first company.
yes very interesting take indeed, sometimes it is worth knowing also if your stack is too complicated that you truly need someone already trained, I have had that situation where I entered a job where I already knew the stack but the code was organized in a way with so many opinions that took me longer to understand and follow them in order to make meaningful contributions
the staff developer had very narrow experience doing software and made almost everything he wanted in a "library" way or in a "micro service" way until he got bored and started doing mono repos
because of this the CEO or founder, had a very bad impression on hiring and of course it was unrealistically to hire someone who had experience in the stack and in dealing with the ego of a lone wolf programmer which I believe can be as high as a Hollywood artist some times
The more the company sees developers as a cost center (e.g. legacy companies who put developers in the IT org), the more they're looking for specific technologies.
"I need a dev with 7 years of Spring Bott!"
The more the company sees developers as a crucial input to innovation and building a more valuable company, the more the emphasis is on capabilities.
"I need a senior developer that's great at solving problems. I don't care what tech stack"
But in the second case, a core capability needs to be passing a typical developer interview. So you'll need to practice writing code in a time limit with someone watching you. You'll also need to practice designing a system.
^ it is dumb that this capability matters, but it's the reality today. There are some companies that interview differently where you actually build real-world things without someone looking over your shoulder, but it's not the norm yet.
Written, async interviews give candidates who are better at the job an advantage from those who are just better at schmoozing and exaggerating their resume.
So a C+ for effort, but this is a great example of what NOT to do.
1- This is hiring by committee. They sent out a call for questions to a bunch of people and then didn't curate it. Everyone's question get in
2- Too long for the candidate. The best candidates will bail. Companies targeting ~10 minutes on a phone get great response rates
3- Too long for hiring committee. NOBODY is going to read this for most candidates. The reasons resumes win is because they're short for the hiring team, not because they're high-signal
This story would make a great culture test! "Would you hire this candidate?"
You only want to work with team leads who agree with your answer, whatever that might be.
Personally, I love working with folks who enjoy playing with technology, so I'm a Hell Yes. I don't see a lot of risk that this candidate would actually try to ship that regex to production.
I've worked with a few folks who are very talented, but only motivated by learning and working with new technologies. Even if they are enjoyable to work with in the short-term, they'll lose steam and saddle the team with doing the last mile and maintenance work. It may be okay to have one or two of these folks depending on team composition and sentiment, but generally I steer away from them.
I think you nailed it that it's a team composition question. Too many folks like that is a problem, just like too many folks who hate the pain of bleeding edge/messy/unstructured work is a problem.
I would be a "hell no", because I know people like that are infuriating to work with if you're trying to get shit done. I love programming and discussing programming trivia and etc, but on a team you also need your coworkers to work with you towards a common goal in a rational manner, keeping in mind performance, maintainability, stability, team knowledge, time constraints, customer expectations, etc. These are not skills this hypothetical candidate displayed.
While that 1-week (or longer) ramp-up is generally true for companies, it's clearly not true for most (successful) open source projects. The things that a good open source project has (good documentation, onboarding, tests, etc.) are also the things that a good work sample will have.
I know 2 startups both hiring their first set of non-founder engineers.
One startup took 4 months to hire 2 senior engineers who weren't in their stack and then gave both of them about a month to come up to speed on the tech. Literally running tutorials.
So 5 months in, they have two onboarded senior engineers.
The other startup is 6 months in and hasn't made either hire. They see deep experience in their tech stack as required and don't want to wait longer for onboarding.
But in retrospect, they would have gotten to an onboarded team faster if they had hired like the first company.