Interview questions for senior frontend engineer

Interview Questions

I regularly cover good interview questions on this blog. In this post I cover more general non technical questions that the interviewers might use to assess you on seniority. As usual the questions also have a certain template of answers as well but it is upto you to modify them to suite your situation.

Table of contents

1. Have you ever managed a team ?
2. Can you explain to me how you set priorities of the work ?
3. What is tech debt and what are your views on it ?
4. How do you measure page performance.
5. Tell me about your approaches to testing
6. Tell me how you do PR reviews
7. Conclusion

Have you ever managed a team ?

As a senior software engineer, I have often mentored junior engineers from time to time. This included things like talking to cross functional teams to understand requirements and then converting them into a technical plan and then conveying it to the junior engineers. Breaking down larger projects into smaller tasks and setting up sprint plans. Figuring out who might be most suited to which work.

I have also activety played a role in figuring out priorities, assigning priorities, regularly accessing progress of individuals and then helping them do better.

I am not a people manager and I see myself as more of a senior engineer who helps set the direction of the project.

Can you explain to me how you set priorities of the work ?

Generally all software we write is eventually meant to run a business and generate profit. I always look at business priorities by working with other people such as product managers, senior management etc. Then I try to align my technical work with the business priorities. In most of the work environments where I have worked P0 is generally considered the highest priority which indicates something is broken in a way that is harming is immensely and we must drop all work to focus on fixing it. P1 is something we need to work on today. P2 is something we will work on over next few weeks. P3 is generally cold storage which we might revisit when we think of tech debt.

What is tech debt and what are your views on it ?

In software engineering we always want to build fast. There are trade offs when we want to move fast. Sometimes we have to sacrifice engineering quality to meet a certain deadline. Overtime such bad engineering solutions start becoming a problem and this is often refered to as tech debt. For example, in one of the places where we worked, we had to often run some special promotions on the home page such as Valentines Day Sale, Mothers Day Sale etc. Such sales had hard deadlines and hence we had to focus on writing code quickly. As time went by, this resulted into a lot of ugly code that increased the page size and made our page load times bad.

We had to fix it eventually. Most places I worked at use to have half yearly tech debt weeks where we focused on solving tech debt problems.

How do you measure page performance.

Pagespeed tool and Chrome Lighthouse are to important tools we use everyday to make sure our pages are performant. Other than that we have setup automated tools like Browserstack which measures performance across various devices and emails us reports. We also had subscriptions to third party services that audited our website on regular basis for issues and reported them.

Since most of my work was for ecommerce companies, page performance was especially an important factor.

Tell me about your approaches to testing

Generally, I focus a lot on unit testing. A unit test focues on testing the smallest unit of work. For example, a unit test checks if a function really does what it is suppsoed to do. An integration test is something that tests whether two or more components work together correctly or not. A functional test is more like an end to end test that is designed to test the function of the product.

I have a lot of experience writing unit tests using jest. However, we had very different approaches to integration and functional tests at different companies. At some places we had only integration tests where as at some places we only had functional tests.

Tell me how you do PR reviews

Different companies have different culture around PR reviews. Most places have a set of unit tests and other automated tests that run on every pull request and ensures that the tests and build passes. At some companies we had automated code hygiene tools like SonarCube that ensured that the code is of best possible quality by detecting sytax errors and other issues.

When it comes me reviewing PR requests, I generally have three rules.

1. Make sure that the PR is of smallest possible size and does just one thing.
2. Ensure that PR request correcly does what its description suggests.
3. Go through code and offer constructive feedback.
4. All feedback should be aimed at helping the other person make progress and not just finding faults.

I feel code reviewer is equally responsible for the PR as the code author and we must focus on getting things done with a high quality bar.

Conclusion

There are the few questions but I will add more.