3 ms·

What I mean to say is that we're hiring Golang engineers. I mean, is that OK? To have a technology stack that you are hiring for (Google Cloud, Golang, Terrafo

What I mean to say is that we're hiring Golang engineers. I mean, is that OK? To have a technology stack that you are hiring for (Google Cloud, Golang, Terraform etc), and to look for candidates with experience with that stack, or who would consider learning that stack? ps. This interview question was designed to also be a great question to learn that stack with, but I would not expect a senior programmer would be able to do so in one weekend -- hence I gave programmers as much time as they wanted, in many cases, several months to play around with the stack and see if they enjoyed it in their spare time. Some engineers even asked for some budget to play around with it in Google Cloud and I provided it. Or should we just code each service in Rust or Elixir or Node or F# or whatever language stack a candidate prefers that day?

eikenberry 3y ago
It's not the tech they are using but the size of the project. This project requires simple tasks but spread over multiple technologies such that most developers won't have experiences with all (or even many) of them. The key thing here is the time. Having just done a ton of interviewing I can tell you that almost every code challenge has some form of this issue and so you learn to just multiply the time they say by 3-4 (as a rough average). Thus taking ones that say 'a few hours', which means a day or two at most, are feasible but the ones that say 'a day or two' or 'a weekend' are not. Also remember candidate are usually not only applying to your job. They will easily have 3-4 of these going in parallel and with each taking up that much time is untenable.
- gafferongames 3y ago
  That's a completely fair point
waynesonfire 3y ago
> 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.

eikenberry 3y ago

It's not the tech they are using but the size of the project. This project requires simple tasks but spread over multiple technologies such that most developers won't have experiences with all (or even many) of them. The key thing here is the time. Having just done a ton of interviewing I can tell you that almost every code challenge has some form of this issue and so you learn to just multiply the time they say by 3-4 (as a rough average). Thus taking ones that say 'a few hours', which means a day or two at most, are feasible but the ones that say 'a day or two' or 'a weekend' are not. Also remember candidate are usually not only applying to your job. They will easily have 3-4 of these going in parallel and with each taking up that much time is untenable.

gafferongames 3y ago
That's a completely fair point

waynesonfire 3y ago

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