Ask HN: How do you interview senior front end engineers/architects?

[deepakkarki]

[mchannon]

Try the Ashley Madison approach to hiring:

First, accept that the vast majority of people you want to hire are already employed and normally couldn't be bothered with your startup. The leftovers are either really unlucky or not worth hiring.

Second, go after the top 98% and leave the others for the rest of the industry. Don't waste time trying to interview them beyond a quick phone screen on personality, because any time of theirs you ask for is extremely expensive to them and you need to acknowledge it from the start (or they'll not respond). Offer them _more_ than they're earning now. After you find one you like, and you're willing to pay them more than they're currently getting, and they're willing to jump ship for that, close the deal as quickly as possible.

This works because their current employer vouches for them (by employing them), and their current employer is presumably a better judge of technical skill than your team is. So leverage that skill instead of cobbling together some facsimile yourselves.

The downside for this approach is that if they're currently earning $200k and you have a budget of $120k for the position (or even $220k), you're not going to hire anybody. It's a shared delusion in the industry that everybody can lowball the senior talent and they won't wise up.

It's been said before, but it bears repeating. For senior talent, you're not buying the job, you're selling it. It's a buyer's market and you need to play motivated salesman and not choosy PITA customer.

[chatmasta → mchannon]

> Second, go after the top 98%

Hopefully you mean the top 2%, or the 98th percentile. /snark

Generally though, I agree with this advice for small companies (i.e. your first ~5 hires). I would recommend making a list of experts on your stack who you would love to work with. Trawl GitHub, StackOverflow, HN, LinkedIn until you identify a list of candidates that are verifiably good at what they do. Then just start recruiting them, a.k.a. selling your company and vision.

For small companies, this aggressive approach seems like it would be both more reliable and efficient than the "pull based" approach of vacuuming up resumes.

[muzani → mchannon]

"First, accept that the vast majority of people you want to hire are already employed and normally couldn't be bothered with your startup. The leftovers are either really unlucky or not worth hiring."

Hey, I'm not employed! Haven't had a full time job in almost a year. But it's mostly because working 10 hours a week on projects pays as well as a full time job.

If someone wants to hire me, I'll listen, but you probably have to offer double what I make working from home.

[mchannon → muzani]

if ( self_employed == employed )

  working 10 hours a week = employed;

[muzani → mchannon]

I mean I've been on the job market for a long time now. I'd actually prefer some kind of full time commitment over doing boring CRUD apps. But it's just not a good deal. Interview process is either too painful, compensation is too low, or the job is too meaningless.

[aprdm → mchannon]

Funny that's exactly how we hired our last senior person. Felt a bit guilty of not interviewing too much but was worth it.

[eb0la]

I ask for basics.

Why? There is a lot of stuff happening in the top layer of everything (UI, full-stack, os/cloud/vm/container)... and it is impossible to evaluate properly knowledge in that area.

BUT... If I ask for basics (OS, Database, organization, how to isolate processes from each other, how to scale), I can see if the answer is solid technically, if the candidate can articulate an answer, how she/he communicates.

Also, I always ask for a projects candidate is proud of.

I want to hear what (s)he did, and why. Architects have to decide stuff, so I want to hear the whys and the why nots.

Then I ask what the would do differently now in the same project.

Reject the candidate if (s)he would do everything the same way: there is always room for improvement, and shit usually happens.

This is a sign other people did the work, or the candidate has a complicated personality that might backfire after hiring.

(edit: sorry if the answer looks a bit harsh)

[croo]

The great thing about anyone who's working in their trade more than five years that you can actually ask them "what were the most interesting projects you worked on" and get a meaningful response. I would ask him about the experiences of what you just listed here and go with the flow. Also you may want to read about CAR (context action result) interview method to have a better understanding how should you structure your questions about these topics.

What was the worst problem erformance wise he had to overcome? What was the largest team he ever supervised, why did he get in that position? If you talk about these kind of questions for a good hour or two you already will feel something about this person. You then have to transorm this feeling to a yes or no as a team. As he will be your future mentor and technical leader I would interpret the "yes,but..." And "no, but..." Answers as "no".

[gashaw]

Prepare a few questions for each trait you care about and then ask all candidates the same (or sample of) questions.

Grade the candidate on each trait based on how well they answered the related questions and pick the best one.

Because you know the questions you can prepare and not be intimidated to ask someone more senior.

For instance:

How to design an app that feeds from two radically different apis? (no need for detailed code)

What perfomance practices they used in library/framework/their own code and why?

What test cases they would write for (a simple) given spec?

Ask them about instances were they mentored/helped/coached teammates.

Good luck.

[qnsi]

Hey, just posting an interesting blog post that was linked previously on HN and got 973 upvotes[1]: https://hiringengineersbook.com/post/trouble-hiring/

(I am not affiliated with them in any way)

[1]https://news.ycombinator.com/item?id=18955731

[muzani]

With senior engineers, you tell them what you do and ask them their opinion on it. Pay attention to their questions. Ask them what they think would improve the system. Pay attention to how they diagnose your system.