[adsjhdashkj]

What's a good method of (technical) hiring in your view?

For some context on my question:

I'm part of a startup-ish group of people who, frankly, don't have a tech hiring group. We have ~25 engineers (i'm losing track these days lol), but no real manager-engineer bridge. Which translates to, we have a bunch of people who code but none who know how to hire. Unfortunately, i am one of those responsible for hiring, and i've got no clue what to do.

We've gone through various attempts over the years. I've been part of ~15 hires for the company - most of our current tech side, to one degree or another. We heavily value hiring the "person" - so we try to suss out people values and cultural fit, but i think we really suffer from being able to evaluate the technical ability of the candidate.

We're not worried about hiring the top talent of SF - we probably couldn't afford that anyway. But we do want bright people who can grow in the problems we're solving. This is where i'm struggling to improve on, as a person hiring.

Thoughts?

[shauns]

Growth Mindset might be a bit of a wooly term but that tends to be what I look for. I want people who continually get better. There are lots of resources on specific things you can discuss for this. For me, I think simply asking "what was a recent new thing you had to learn" opens up a good conversation.

For ascertaining whether someone meets a technical bar -- the gold standard has to be facilitating some way where they can do some actual work with you. That might be v difficult depending on nature of stack, tech debt, etc. But the closer you can make that sort of process to what would really be happening, the better. Coding exercises really only prove someone is good at coding exercises -- that may or may not have any relevancy to what you do I think.

[adsjhdashkj]

> I think simply asking "what was a recent new thing you had to learn" opens up a good conversation.

Really appreciate the reply, that's a great question.

> the gold standard has to be facilitating some way where they can do some actual work with you.

We've actually done this, recently. It worked okay. We identified a few problems with that iteration for us though:

1. We chose real projects, but we felt limited by finding a project where the scope could be small enough for the developer to create it to a meaningful extent and not be bogged down in planning. Projects without meaningful planning however felt so simple that i didn't feel it would challenge anyone. 2. I really hated giving interviews "real" work. Which is to say, it was work we as a company needed - but that felt too easy to be seen as exploiting the applicant - for good reason. 3. I felt disconnected from the applicants mindset. I want to understand how they think on a problem - what things they're skipping for time, what pain points in the application need testing, what things they think need to be abstracted, etc.

I did like how it gave them time to solve the problem themselves. As someone who struggles with.. stage fright (for lack of a better term), interviews are hell for me. I want to hire people even if they're terrified and draw a blank.

My next set of interviews coming up i'm thinking i'll try a combination of a take-home project, but also something pair programmed. Perhaps a take-home, and then we review in a pair program after? I want them to be able to not be under pressure, but i also need some insight on their mind.

Unfortunately i have no idea offhand how to design a take-home that is both simple but not brain dead. I don't want it to take long, i don't want to riddle it with complex algorithm based requirements either. My initial gut is to mock up some requirements - after implementing them myself - that have real world value. How do they choose to abstract database access for unit testing? What do they choose to cache with? Did they consider cache invalidation? Something like this.. i guess.

My final concern is that we'll be hiring for specific languages, but i'd like to be able to hire someone wanting to learn and use those languages. Partially because it promotes growth, but also because it opens the job market. Namely, we're a Rust shop and i don't want to hire only people who know Rust - but i also don't want to hire evaluate someone based on a take-home in another language.

I'm debating offering a pair programming option for the take-home if they're not comfortable with Rust. I would expect their take-home to be far worse, as so many concepts would be new.. so i'm unsure if this would be valuable.

Thanks for the reply, and if you have any more thoughts i'd love to hear them :)

Best of luck on the market!