Selene Hire
Software & Engineering

Hiring a frontend engineer

Ninety applicants, ninety portfolio links, and almost all of them look good. The screening problem here is not spotting bad work — it is working out who was responsible for the good work.

A polished portfolio is evidence of a team, not a person. Frontend is the one engineering discipline where the output is visible to a non-engineer, which sounds like an advantage and mostly is not. A beautiful site tells you a designer was good. It cannot tell you whether this candidate argued for the simpler interaction, built the component library everyone else used, or was handed a Figma file and asked to match it pixel for pixel — and those three people command very different salaries. Meanwhile the CV fills with framework names, which have never been the hard part: someone fluent in React learns Vue in a fortnight, and nobody has ever shipped a good interface because they knew the framework.

Setting up the role

From a framework list to a guide, in one conversation

Selene goes after who owns the interface decisions here — because that answer, not the framework, decides which candidates are even plausible.

The questions she asks

Who decides what the interface does

The question that matters on a frontend role is whether this person receives designs or shapes them. A team with a dedicated designer wants a superb implementer; a team without one needs somebody with taste and the confidence to use it. Those are different hires, and the same job ad attracts both.

The question that reframes it

One sentence changes the guide

Managers hiring frontend almost always describe the job as implementation and then, asked this question, describe judgment. The gap between those two answers is where the bad hires come from — you advertise for a pair of hands and are disappointed when you get one.

Exceptional, not just good —

“Someone who notices a design is wrong and says so before they build it, not after.”

→ Design judgment became a must-have; framework breadth stopped being scored.

The requirements

What the guide ends up measuring

Six criteria, and notice that only one names a technology. That is deliberate: the manager has no designer, so the scarce thing is judgment, and every framework on the list can be learned by someone who already has it.

No hard gates here

Nothing to gate on, and one gate worth resisting

No licence, no certification, no shift pattern — every applicant goes straight to being read. The gate people invent for this role is years-of-framework, and it is worth resisting: it filters on the one thing that transfers fastest and correlates with almost nothing you actually want.

The scoring

Scored on the decisions, not the screenshots

Selene never receives the candidate’s name or the raw CV. She scores a blind, structured profile, with any stated age, sex, nationality and religion stripped out before scoring runs.

What she reads is how someone describes their own work, which on this role is the only place ownership ever shows up — a portfolio cannot tell you who argued for the simpler interaction.

How the blind scoring works
Scope, plainly

What stays with you

Selene's half

  • Establishing whether this role shapes the interface or implements it, and building the criteria to match
  • Reading all 90 against the same guide, blind, with the evidence attached
  • A ranked shortlist, and where the portfolio contradicts the CV, saying so
  • An interview brief aimed at ownership — like that component-library question

Yours

  • Getting engineers to apply — Selene doesn’t post to job boards or source candidates
  • Opening the portfolios; she reads what candidates wrote about their work, not their live sites
  • Any pairing session or take-home, with her brief in hand
  • The offer, and every call that matters

Say whether you have a designer

That one answer splits this role into two different hires — watch the guide pick one.