Reader,

At the bottom of today's email is the rubric I used with the hiring manager during discovery and interview debriefs.

It was developed with a senior engineer in the organization who conducted a one-time discovery session with me and the client manager to understand the department’s initiatives and requirements.

This approach immediately created a level of trust and shared accountability with the decision-maker and provided a clear framework for me to surface gaps and misalignment early.

That rubric proved critical in filling that last opening.

Combined with insight from others in the department, it became clear the team believed they needed an architect for the final role when the actual scope of work did not support that level.
A strong junior engineer was sufficient for the position.

What I did not share in part one of this newsletter was an additional hurdle:

At this point the play was easy.

• I knew exactly what they needed compared to what they thought they’d need
• I knew exactly the type of profile I needed to source

So rather than allocating my team to source a handful of new resumes and hoping something stuck, I pressure-tested the assumption.
I created a narrow search and within a few hours found exactly what I needed.

I brought in a QA architect with deep Cypress expertise from Slalom Build who was open to interviewing and helping validate the true needs of the role.

After interviewing both candidates, management was finally happy with both profiles and ready to make decisions.

I led a debrief with the client team focused on the actual work, the tradeoffs, and the cost implications of each candidate. The conclusion finally became clear to management:

This outcome would not have been possible without the initial rubric and the relationships I built along the way.

​

Below is an example of the job description and intake template I use to align expectations early and identify the right candidate profile from the start:

​Job Description​

​Rubric (Intake Template)

Steven's Notes on the "why"

Jaclyn mentioned that a "strong junior" would have sufficed for what the client initially saw as a job for an "architect".

The gap between "junior" and "architect" is often 7+ years of experience, so that's a big disconnect.

Obviously, not all "years of experience" are equal. Some are more dense with relevant experience.

But the role here asks for someone who can:

• add & maintain automated tests to a Cypress suite
• add accessibility testing to the CI/CD pipeline that runs the Cypress tests

Even before the age of AI, this is something a junior can handle if they've got the curiosity to learn new skills.

Everything you need to know to expand test coverage can be found in the Cypress docs.

Any doubts about how to add accessibility testing to the CI/CD can be found in the docs for the CI/CD tool (e.g., GitHub Actions, Jenkins, etc.).

There aren't many "gotchas" for simple tasks like these that would require a Senior+ level of expertise.

So the important things to look for are basic experience with the tech stack the client is using, and a familiarity with writing automated tests. It's rare to find candidates who have automation experience without testing experience these days, so the testing side of the req should be satisfied by the right automation candidate, but screening for testing ability is already something most companies don't know how to do well.

That's another conversation for another time.

The bottom line is, "more" isn't necessarily "better" when it comes to seniority. The humdrum of expanding test coverage would probably bore someone who thrives in an architect role. It would cost a hell of a lot more to have an architect writing tests instead of a junior.

Looking out for your client means not just helping them find the best candidate, but also helping them get the most bang for their buck.

​

-Jaclyn
​