3 ms·

> You have to be mentally sick to ask people to code review their side projects. Could you expand why? We allow people to substitute a tech interview round wit

by yreg 3y ago

> You have to be mentally sick to ask people to code review their side projects. Could you expand why? We allow people to substitute a tech interview round with side project showcase. Don't see why it doesn't make sense in your view. > "Average developer tenure is two years, company is three years old." Got it. I don't think this statement says what you think it does. So what does it say?

lolinder 3y ago
> Could you expand why? We allow people to substitute a tech interview round with side project showcase. Don't see why it doesn't make sense in your view. As an option to replace a different interview segment I think that's quite fair. But both choices have to be clearly presented to the interviewee, and they should understand that either option is treated as equally good. OP's interview format seems to assume that everyone does the side project and the tech interview round isn't an option.
ikura 3y ago
> So what does it say? It depends on the definition of tenure... if tenure is defined as a closed interval (i.e. defined only for developers who've joined and then left) then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign. If tenure is defined as the length of time the developer had worked, OR, has worked so far, then it means they have a core group of developers and aren't growing the development team particularly quickly. Again, this might not be a good sign for a startup.
- yreg 3y ago
  > then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign. What. Of course that "of the developers who have departed" all have left/been fired, that's a tautology. How is it "not a good sign"? Or is it supposed to be a bad sign that there even is a person who is not working there anymore?
  - joelfried 3y ago
    I think parent meant: Assuming tenure is defined ONLY for those who have already left, 2 years is a bad sign. For a 3 year old company, if that definition is used, it is indeed pretty bad. It means that _of the people who are leaving_, people stay a couple of years, then bounce. This means people stick around long enough to get past the warmup of new employment, get used to your stack and tech, then bounce for greener pastures. The very important metric this leaves out though is what percentage of the company actually left. If there's 7 people in this 3 year old company and only one person left last year . . . that says almost nothing. Any single person can leave for a great variety of reasons. You'd need a decent sample for this to matter. The flip side definition of "tenure" is worth considering though: if the average tenure of 2 years includes people still working at the company, there are a lot more variables to content with before you can know anything. A 3 year old company could have an average employee of it have been working there for 2 years and not a single person who joined the company having ever left (e.g. if at year 1 there was a decent amount of hiring). I think this is probably why parent wanted to restrict the definition (and why it's worth thinking about this angle) - because otherwise the company ramp up and trajectory and hiring patterns become hidden variables and you can't glean anything out of the tenure numbers on their own.
    - yreg 3y ago
      I still don't get what's bad about that. So what would be a good tenure for a 3 year old company if 2 years is bad? 2.5 years? 1 year? 6 months?
KallDrexx 3y ago
It creates an extremely subjective comparison between candidates. Part of it is like a sibling comment said, if an interviewer's interests lie more in line with devops, then a devops project that solves a problem he's acutely aware of will be given much higher praise in his mind, and allows him to engage with the candidate more. If the interviewer rarely does any devops and isn't totally sure of the problem space, he may be biased towards thinking it's overengineering a problem that doesn't exist, or may not fully grasp the problem in the time allotted. The candidate could articulate the side project exactly the same but have completely different interview outcomes in both outcomes. And an argument could be made that "it's a test to see if the latter candidate can articulate a problem and peak the interviewers interest" but in this case the former didn't even have to do that, and thus you are judging candidates by different subjective metrics. And it's especially an issue if the side project isn't directly related to the role (e.g. video game vs cli tool vs database vs website, etc...). It also means that some candidates will be judged on system design (if a side project is wide scoped) while some candidates will be judged based on algorithmic design (if the side project is very narrow scoped with the details in the implementation). It just adds so many variables to the interview project that you are no longer comparing "which candidate is the best fit for the job I am actively hiring for" and instead "which gave me the best vibes", specifically because you did not actually measure all candidates by the same measure.
- ngc248 3y ago
  very clearly said, this is such a subjective process.

by yreg 3y ago

lolinder 3y ago

> Could you expand why? We allow people to substitute a tech interview round with side project showcase. Don't see why it doesn't make sense in your view. As an option to replace a different interview segment I think that's quite fair. But both choices have to be clearly presented to the interviewee, and they should understand that either option is treated as equally good. OP's interview format seems to assume that everyone does the side project and the tech interview round isn't an option.

ikura 3y ago

> So what does it say? It depends on the definition of tenure... if tenure is defined as a closed interval (i.e. defined only for developers who've joined and then left) then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign. If tenure is defined as the length of time the developer had worked, OR, has worked so far, then it means they have a core group of developers and aren't growing the development team particularly quickly. Again, this might not be a good sign for a startup.

yreg 3y ago
> then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign. What. Of course that "of the developers who have departed" all have left/been fired, that's a tautology. How is it "not a good sign"? Or is it supposed to be a bad sign that there even is a person who is not working there anymore?
- joelfried 3y ago
  I think parent meant: Assuming tenure is defined ONLY for those who have already left, 2 years is a bad sign. For a 3 year old company, if that definition is used, it is indeed pretty bad. It means that _of the people who are leaving_, people stay a couple of years, then bounce. This means people stick around long enough to get past the warmup of new employment, get used to your stack and tech, then bounce for greener pastures. The very important metric this leaves out though is what percentage of the company actually left. If there's 7 people in this 3 year old company and only one person left last year . . . that says almost nothing. Any single person can leave for a great variety of reasons. You'd need a decent sample for this to matter. The flip side definition of "tenure" is worth considering though: if the average tenure of 2 years includes people still working at the company, there are a lot more variables to content with before you can know anything. A 3 year old company could have an average employee of it have been working there for 2 years and not a single person who joined the company having ever left (e.g. if at year 1 there was a decent amount of hiring). I think this is probably why parent wanted to restrict the definition (and why it's worth thinking about this angle) - because otherwise the company ramp up and trajectory and hiring patterns become hidden variables and you can't glean anything out of the tenure numbers on their own.
  - yreg 3y ago
    I still don't get what's bad about that. So what would be a good tenure for a 3 year old company if 2 years is bad? 2.5 years? 1 year? 6 months?

KallDrexx 3y ago

It creates an extremely subjective comparison between candidates. Part of it is like a sibling comment said, if an interviewer's interests lie more in line with devops, then a devops project that solves a problem he's acutely aware of will be given much higher praise in his mind, and allows him to engage with the candidate more. If the interviewer rarely does any devops and isn't totally sure of the problem space, he may be biased towards thinking it's overengineering a problem that doesn't exist, or may not fully grasp the problem in the time allotted. The candidate could articulate the side project exactly the same but have completely different interview outcomes in both outcomes. And an argument could be made that "it's a test to see if the latter candidate can articulate a problem and peak the interviewers interest" but in this case the former didn't even have to do that, and thus you are judging candidates by different subjective metrics. And it's especially an issue if the side project isn't directly related to the role (e.g. video game vs cli tool vs database vs website, etc...). It also means that some candidates will be judged on system design (if a side project is wide scoped) while some candidates will be judged based on algorithmic design (if the side project is very narrow scoped with the details in the implementation). It just adds so many variables to the interview project that you are no longer comparing "which candidate is the best fit for the job I am actively hiring for" and instead "which gave me the best vibes", specifically because you did not actually measure all candidates by the same measure.

ngc248 3y ago
very clearly said, this is such a subjective process.