4 ms·

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

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

halfmatthalfcat 6y ago
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.
- vsareto 6y ago
  >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.
  - matfil 6y ago
    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.
- dntrkv 6y ago
  > 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.

halfmatthalfcat 6y ago

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.

vsareto 6y ago
>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.
- matfil 6y ago
  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.
dntrkv 6y ago
> 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.