I never understood why people cared so much about company "name" until a handful of years ago. It's not about "status" in terms of what kind of fancy clothes you wear, but it absolutely signals an ability to clear a certain kind of bar, produce a certain kind of work, and experience things on a scale that you wouldn't at a smaller shop.

It doesn't mean one path is right or wrong for a job (I know many people who switch back and forth between bigcorp and startups), but if you only see BigCorp experience as status seeking/soul sucking experience, you're missing a huge part of the picture.

I suspect "clear a certain kind of bar" is the biggest part of this.

Imagine you're a recruiter at Facebook. You reach out to thousands of candidates, convince hundreds to come in for interviews, and almost all of them fail because the interviews are hard and test skills that need to be specifically trained. If you convince a Googler to come in for an interview, they probably have a nearly 50% chance of passing since they've already done it at least once.

The recruiters are not exactly incentivized to bring in people who will be great hires. They are incentivized to bring in people who can pass the interview.

My favorite econ professor at my (private) university often pointed out that our eventual diploma was far more about signaling qualifications rather than education; that you won't necessarily get a better education than at the state school down the road, but it proves you can play the game; get the good grades in secondary school, do the things you need to do to get into the university, get the grades, do the work. It's far less about what you actually learn or the 'quality' of the education, whatever that means.

I know when I see a fellow alumni of my almamater, I think, well they are probably not much dumber than I am.

Doesn't it also mean the opposite? This person was at a better company now this person wants to work here. Why? What went wrong? Did big company make a mistake hiring. Vs this person seems to be on the rise. Each company is a bigger and each position is more senior.

If you can speak to the processes involved and have demonstrable knowledge about how to implement things learned from side-projects, what's the difference between having done it at work versus personal time? None in my opinion.

> If you can speak to the processes involved and have demonstrable knowledge about how to implement things learned from side-projects

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.

The counterpoint to this is the amount of resumes I've had to read and subsequent interviews I've had to sit on from "seniors" or "principals" that they themselves haven't gone fully into the weeds on whatever technology they've been practicing for 10+ years. The amount is staggering.

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.

>The counterpoint to this is the amount of resumes I've had to read and subsequent interviews I've had to sit on from "seniors" or "principals" that they themselves haven't gone fully into the weeds on whatever technology they've been practicing for 10+ years. The amount is staggering.

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.

There's an argument for valuing ten years of Silverlight experience -- especially if it includes some gnarly projects where the framework isn't really holding your hand that much -- over ten years of flitting between web frameworks but never really getting much beyond implementing the stuff that shows up in the tutorial.

I think "going into the weeds" (and not being afraid to do so again, in another context) has some value independently of any specific patterns or tricks that apply to a particular technology.

> 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.

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.