▲ 1 points

Ask HN: How to interview a senior front end engineer?

What are the right questions to ask in an interview for a senior frontend engineer from an employer perspective?

Given that we are trying to raise to average experience level of our own team, how do we interview a person who is more senior than the senior-most frontend engineer we have at the moment?

For context, our engg. team is quite small, and we have 4 frontend engineers, all of whom are junior/associate software engineers. We are hoping to add someone to the team that can improve the quality of the work we do (unit tests, architecture, reviews, scoping projects, scaling the codebase up, etc.). Our tech stack is React/TS and ASP.NET Core.

In general, I am also interested in learning about how to hire for roles where our company does not already have experience in? It seems to me that to hire a senior frontend engineer, you would need another senior frontend engineer sitting on the interviewing side. How do we break that circular dependency?

5 comments

>We are hoping to add someone to the team that can improve the quality of the work we do

I think that's your answer... Show them your existing front-end code, and ask them how they'd make it better. If they're experienced, then they should have some very concrete ideas. Then ask them "why" for their ideas. If they can't fully explain the "why" behind the "what" they're probably just regurgitating things they've read, but don't actually understand the tech.

Thank you for the idea. We do know some parts of code where we have issues which might be good candidate for the interview.

Apart from this, do you have recommendations or ideas for the take home tests for frontend engineer interviews? In a previous hiring run, the test we used turned out to be too easy because all candidates were able to implement it successfully and offloaded work heavily to third-party libraries.

FWIW, we ditched our take home tests a few years ago because candidates considered the ~8 hours required to complete it to be a waste of their time when they didn't have to go through that hassle for other comparable offers. It was a neat little project but about half of the candidates either rejected the notion of doing that test or simply didn't send in the result, so we used to lose about 50%.

Instead, we spend more time discussing real-world-oriented stuff, like what the parent is describing.

Personally, I like to orient the discussion toward failures and recoveries if the candidate doesn't do it on their own. You learn so much about someone that way.

I wouldn't give or do a take-home test, I respect people's time too much. Again, I would sit with them and have a conversation about your code, and their suggestions. Hiring someone is more than what code they produce... Can you work with this person? Are they receptive to feedback? How do they handle conflict/being challenged?

Ask them what they have done before. First of all, years of experience is good to have so you may want to strive for 5-10 years instead of someone with 2 years. You can then ask if they have mentored others before and how they think about best doing that. Also hear if they have been the lead developer in projects before.

Just some ideas.