As I mentioned in my comment, no difference if the person is starting out or if the project gets traction.
But for experienced positions like the post author was talking about. You don't get additional signals on the developer, like did the product scale well, how was the uptime, the performance optimisations he needed to do, evolving the product with customer feedback etc. Also, bigcos love to ask around conflicts within a team, working with other teams because it matters a lot to them.
As an engineer I can admire the dexterity of a solution even if unproven but how do I verify it in an interview span. Easier to do this if I can attach it with a company name or some numbers.
I hate this and I spent early part of my career trying to come up with methods that can make hiring easier and reduce biases like company name but I realised how difficult the process is with different stakeholders, each having his own criteria and biases.
You know my hypothesis why, because they don't have side projects. They have silo'd themselves into whatever niche project or have been on maintenance mode on a piece of software for years and never evolve. Sometimes it's not their fault, their company has pigeon-holed them into whatever software and they can't escape for whatever reason.
They should have side projects (if they care to keep learning) or lest be left behind those in more dynamic companies or those that have side projects to evolve.
You know this is a risk. If you went deep on something like Silverlight, you'd have just thrown away all that time. And then people will casually dismiss your 10 years away as not being relevant. And now you get to pick a new technology to maybe invest the next 10 years on, risking the same thing happening again. If a product dies, you go back to square one as a junior again on some new technology.
Picking a long-lasting technology is hard. You're predicting the future.
I'm really tired of people who think they have this industry figured out like it's easy to predict what will be around in 10 years so you can make safe choices about what to invest time into.
I think your hypothesis is correct. In my experience, most of the devs I've seen in that position do it to themselves. They get comfortable in their part of the codebase and rarely venture outside. Instead of helping other devs ramp up in their codebase, they just close all the tickets out themselves since that's easier than actually getting someone up to speed. I've gotten close to that situation, but realized what was happening and worked with my manager to take on different projects. It definitely creeps up on you.
