4 reasons to work as a front-end engineer at Nutmeg

Jason Cheung

5 min read

When searching for a new job, it’s often difficult to get true insight into the role you’re applying for. The interview process is usually your best chance to get this insight, but you may not have time to ask enough questions to truly get a feel for what the role entails. In this article, I’ve outlined what it’s like to work as a frontend engineer at Nutmeg and some of the reasons to work here. 

Reason #1: we have an interesting frontend stack  

We are in the process of migrating from a legacy Ruby on Rails app to React, talking to Java microservices. This means that the majority of the frontend work we do is greenfield.

We identified early in the React migration that we wanted to create components that could be reused across the whole Nutmeg application. A joint initiative between the frontend guild and the design team was started to create a design system, and as a result ‘Nutkit‘ was bornNutkit hosts our base UI components like button, toggle, radio and input. It follows the Atomic Design methodology.

At a higher level, we create business logic components that provide functionality for a business domain. An example would be a payment form component that we can drop onto multiple pages across the Nutmeg website, without the need to duplicate the code for handling payments. These business logic components live in monorepos that are published as npm packages and consumed by any application in need of that business logic.

To visualise our design system, we use Storybook – a showcasing tool for components. The Storybook is hosted and accessible internally to be used as a reference point during design system discussions.

There are many more technologies we use at Nutmeg – too many to list in this article. If you’re interested in seeing them, you can view our living tech radar at https://tech-radar.nutmeg.com.

Reason #2: We care about code quality 

We put a strong emphasis on the quality of the code we produce and have a number of processes in place to ensure the code reaches production with a high level of quality. I’ll outline and describe those processes in this section.

Discussions and early feedback 

Before beginning a piece of work, we encourage our front-end engineers to openly discuss what they’re about to build – and how they’re planning to build it – with other frontend engineers. The benefit of this approach is that everyone has visibility of the work that’s about to be done, and everyone can give their own opinion on what would be the best solution. We cover various angles of component design with this kind of transparency, as each engineer’s opinion comes from their own software development experience. The additional purpose of early component discovery is to avoid an engineer having their work rejected after they have already spent time building the component.

Code reviews 

The next stage of quality assurance is the code review stage. We open pull requests (PRs) to merge into master. Any front-end engineer can review a PR, even if it’s outside of the team they work in. What we like about PRs is that the code author gets a sanity check on their code, they may receive feedback for a better implementation of the functionality, and the reviewer may learn from the code they’re reviewing. Code reviews help us to keep our code aligned with industry and internal best practices and conventions.

Automated testing

To increase our confidence in our code behaving exactly as we intend, we have various forms of automated testing. The first is unit testing. We use Jest and Enzyme to write our unit tests and capture DOM structure with snapshot testing. 100% code coverage is enforced using git hooks. Git hooks also allow us to automate code linting with ESLint for JavaScript, and Stylelint for Sass.

The next form of automated testing is our integration tests – where Cypress is our tool of choice. Testing with Cypress is highly beneficial, as it allows us to test the business logic and interactions between components – i.e. exactly how the user interacts with the application.

The next layer of testing is our (legacy) Cucumber tests for end-to-end testing. These tests run through specific journeys across the application to ensure that the Nutmeg application is still fully functional and that the newly-introduced code hasn’t unintentionally affected another part of the application. Our aim is to replace these tests using Cypress.

Lastly, for our design system, we use Loki to test for visual regressions in components. We check in a snapshot image of the component as a reference image. Once a new change is committed, Loki takes a new snapshot of the components and compares them against the reference image. If the images are not the same (i.e. one pixel is different), the Loki tests will fail, and the pipeline will halt.

All of the automated testing is integrated into our Jenkins pipelines and determine whether a build passes or fails. 

Reason #3: Our frontend guild

Our frontend guild is made up of 12 engineers who are split across different domain teams. We host a bi-monthly meeting where we update one another on the work we’re doing and what work is coming up. We also use the meeting to showcase new technologies, patterns, and best practices. We can bring problems to the table and have an open discussion on the best approach to solve them. It’s also a forum for ensuring we’re all aligned with one other. Put simply, the meeting is to talk about all things frontend.

Frequent communication between the front-end engineers and the design team is crucial to the upkeep and alignment of our design system. We meet on a weekly basis to review the latest designs and conventions for our design system and product as a whole. It helps us to remain consistent and to have early discussions about the creation of new components in the design system.

Reason #4: Nutmeg fosters a great learning environment

Having the opportunity to learn and grow as an engineer and as an individual is important. Year-on-year, you want to be able to look back and know that your knowledge has expanded and deepened. At Nutmeg, there are a multitude of ways to learn, and managers will encourage and facilitate professional growth.

As mentioned above, pull requests provide us with the opportunity to learn from other front-end engineers. Not only can we review any engineer’s code to learn new techniques and language features, but we also receive feedback on our code and how we can improve it.

If you would prefer a more formal learning platform, you can request a subscription to PluralSight and Safari Books, where you can take online courses or read e-books.

If you’re a conference-goer, Nutmeg can pay for you to attend conferences and managers actively encourage you to seek out conferences that are of interest to you.

Inside the company, employees host lunchandlearn sessions, where they present on a topic during lunch, and others can eat their lunch while listening to the talk. The topics range from the basics of ETFs to an introduction to our design system. 

Similar to lunchandlearns, engineers host skill share sessions, where they present more engineering-focused topics to spread awareness and knowledge. Previous speakers have talked about Kafka, Kubernetes, and Docker.


Nutmeg is a brilliant and interesting place to work as an engineer. The front-end architecture is sophisticated and evolving. Learning is at the core of the company. Our design system allows for pages to be built quickly and with consistency. We value code quality as much as speed of delivery. And with all the new products and features we’re building, it’s truly an exciting time to work here.

Was this post helpful?
Let us know if you liked this post
Powered by Devhats
Jason Cheung

At Nutmeg, Jason works as a senior front-end engineer, looking at the parts of the website related to customer details and compliance.

Outside of work, Jason has a passion for Web accessibility, softball, video games, travelling, and the Oxford comma.

Other posts by