3 ms·

> I mean, is that OK? To have a technology stack that you are hiring for You're aware that a senior engineer will take a trivial amount of time to get up-to sp

> I mean, is that OK? To have a technology stack that you are hiring for You're aware that a senior engineer will take a trivial amount of time to get up-to speed in a programming language paradigm they are familiar with. And, an entry level engineer will have the same learning curve--their core source of inexperience is not the programming language. So, no, the technology stack would be a very low signal for me if I were hiring.

gafferongames 3y ago
That's great, we're trying to filter out engineers who can't learn new things quickly, and who lie about their experience level and the sort of work they can do. People do this a lot, unfortunately. So... we actually ask them to demonstrate to us that they can learn new stacks quickly. That's the point of the question. If somebody doesn't know Golang or the stack directly, that's awesome. They can learn it quickly and show us.
- cryptonector 3y ago
  > That's great, we're trying to filter out engineers who can't learn new things quickly, and who lie about their experience level and the sort of work they can do. People do this a lot, unfortunately. I feel for you. It does happen a lot. A portfolio matters. References matter. But it's really nice that you give unknowns a chance too, and to do that you really do need a filter. And it's a fairly trivial filter, since you're asking the applicant to build a proxy. I don't think you'll get too many applicants who don't already know the stack though because... think it of from their perspective: if someone is applying who knows that stack already, then they can beat the others to the punch, so taking 2x as long to learn the stack is likely to be a waste of time. I'm not sure how to make this "fairer" so that you really do measure learning time rather than comfort level. Your filter is likely better at finding experienced Golang devs than experienced devs who can learn Golang quickly. In the short term this is probably very good for you, but the latter are probably better in the long run because people who learn quickly and well are more valuable than people who know a tool well.

gafferongames 3y ago

That's great, we're trying to filter out engineers who can't learn new things quickly, and who lie about their experience level and the sort of work they can do. People do this a lot, unfortunately. So... we actually ask them to demonstrate to us that they can learn new stacks quickly. That's the point of the question. If somebody doesn't know Golang or the stack directly, that's awesome. They can learn it quickly and show us.

cryptonector 3y ago
> That's great, we're trying to filter out engineers who can't learn new things quickly, and who lie about their experience level and the sort of work they can do. People do this a lot, unfortunately. I feel for you. It does happen a lot. A portfolio matters. References matter. But it's really nice that you give unknowns a chance too, and to do that you really do need a filter. And it's a fairly trivial filter, since you're asking the applicant to build a proxy. I don't think you'll get too many applicants who don't already know the stack though because... think it of from their perspective: if someone is applying who knows that stack already, then they can beat the others to the punch, so taking 2x as long to learn the stack is likely to be a waste of time. I'm not sure how to make this "fairer" so that you really do measure learning time rather than comfort level. Your filter is likely better at finding experienced Golang devs than experienced devs who can learn Golang quickly. In the short term this is probably very good for you, but the latter are probably better in the long run because people who learn quickly and well are more valuable than people who know a tool well.