What I Look For When Hiring a Full Stack Software Engineer After 1,500 Website Optimizations
By Matt Suffoletto
After running roughly 1,500 website performance optimizations across WordPress, WooCommerce, Shopify, and Shopify Plus sites since 2020, I have a much sharper idea of what makes a strong full stack software engineer than I did a decade ago. The role gets described in job posts as someone who can move between front-end and back-end work, but in practice the engineers who push a business forward share a different set of habits.
The pattern I keep noticing is that great full stack engineers care about what the user experiences, not just whether the code runs. Below is what I look for when I am hiring for our team, and what I would encourage any founder or hiring manager to look for too.
They treat performance as a feature, not a cleanup task
Most engineers can build a working feature. Fewer build one that loads fast on a real network. According to the HTTP Archive’s Web Almanac, only a minority of mobile pages still pass all three Core Web Vitals thresholds, and the ones that fail tend to lose users at the first interaction (see the Web Almanac). A strong full stack engineer keeps that math in their head from the first commit. They consider how a new feature affects Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. They ask whether a new dependency will add 100 kilobytes of JavaScript before they install it.
When I am interviewing, I ask candidates how they would approach a page that loads in six seconds on a slow connection. Strong answers walk through measurement before optimization: open DevTools, run a Lighthouse audit, study the network waterfall, find what is blocking render. Weak answers jump straight to “I would minify everything” without ever asking what the actual bottleneck is.
They understand the full request lifecycle
The label “full stack” gets thrown around loosely. To me, it means an engineer who can trace a request from a user’s tap to a database query and back, and explain where time is being spent at each step. They know that a slow API endpoint can be addressed with an index, a cache, or a smaller payload, and they know how to decide which one fits. They know that a slow front-end can be a render-blocking script, an oversized hero image, or a layout shift waiting for a font to load.
This shows up in practical work. Strong full stack engineers will not blame “the back end” or “the front end” in isolation. They look at the entire pipeline and find the single change that produces the biggest gain. Often it is not where you expected.
They ship small, reversible changes
In my experience, the single biggest predictor of long-term site health is whether engineers ship small changes. Smaller pull requests are easier to review, easier to roll back when something breaks, and easier to attribute when a regression appears in monitoring.
Engineers who batch up huge changes tend to leave a trail of hidden regressions. Engineers who ship a tight, well-scoped change every day or two tend to keep their site fast, even as features pile up. This habit is hard to spot in an interview, but you can probe for it. Ask candidates to walk you through their last few pull requests. If they describe ten lines of code and a clear reason, that is a good sign. If they describe a 2,000-line refactor that “touched a lot of things,” I get nervous.
They take ownership beyond their ticket
The best full stack hire I ever made noticed that we had no automated way to flag when a deploy made a page slower. Nobody asked him to fix that. He wrote a small script that compared key metrics before and after each deploy and posted the result in a shared channel. Within a quarter, the team’s instinct to ship clean changes got stronger because everyone could see the impact.
Full stack engineers who take ownership of the system, not just their assigned ticket, compound over time. They notice problems early, raise them clearly, and often propose the simplest fix.
They communicate trade-offs in plain language
Web performance work involves real trade-offs. Caching aggressively lowers load times but stale content can confuse customers. Server-side rendering helps speed but adds infrastructure complexity. A strong full stack engineer can lay out the choice in a few clear sentences and recommend an approach with reasoning.
If a candidate cannot explain a trade-off to me, the founder of a small company, I doubt they can explain it to a sales lead, a marketing manager, or a customer success specialist who has to live with the consequences.
Closing
Hiring a full stack software engineer is not really about a checklist of frameworks. It is about finding someone who treats the application as a product the user has to enjoy, takes ownership of how it behaves in the real world, and communicates clearly with the rest of the business. Frameworks come and go. These habits hold up.
Author Bio: Matt Suffoletto, Founder & CEO, PageSpeed Matters
