Our approach
Vetted by Engineers.
What that means in practice.
Most recruitment matches CVs to job descriptions. We assess the person against the role first, write down what we found, and introduce only those who meet the bar.
Assess the role, not the CV
A CV tells you what someone has been near. Our assessment finds out what they did, how they reasoned, and whether that matches the work you need done. We take the brief from the hiring manager wherever possible, because they know what good looks like.
Different roles, different tests
There is no single engineering exam that suits every technology role. A platform engineer, a backend engineer, a security analyst and a product manager each need a different kind of assessment. The structure of our process stays consistent; the content changes with the discipline and with your brief.
1Assessment by role
Four roles, four assessments.
Examples of how the assessment changes. Your brief shapes the detail.
| Platform Engineer | Backend Engineer | Security Analyst | Product Manager | |
|---|---|---|---|---|
| Typical format | Technical interview and infrastructure walkthrough | Paired design exercise and code review | Scenario-based triage exercise | Case study and structured interview |
| Core focus | Infrastructure as code, Kubernetes, release, incidents | API and data design, testing, concurrency | Triage, log analysis, incident handling, threat knowledge | Problem framing, prioritisation, working with engineering |
| What we listen for | Reasoning behind past infrastructure decisions | How they justify design trade-offs | Order of investigation and use of evidence | What they chose not to build, and why |
2The Technical Audit Record
What you receive with every candidate.
The record is written by the assessor and runs to a page or two. It has seven sections, always in the same order, so candidates can be compared on the same terms.
Where we did not assess something, the record says so. Where there is a risk, such as a long notice period or a gap against the brief, it is stated plainly.
- 1Summary
- 2Relevant experience
- 3Capability assessment
- 4Working style
- 5Alignment to the role
- 6Logistics
- 7Risks and limitations
Technical Audit RecordBoolean Group
TAR-SAMPLE-PE
Illustrative sample
1Summary
Hands-on platform engineer who could explain the structure and trade-offs of infrastructure they had built, not just the tools involved. Recommended for interview.
2Relevant experience
Two platform roles, most recently in a team of six supporting around forty product engineers. Led a move from hand-built environments to Terraform modules. Shared an on-call rota.
3Capability assessment
| Area | Finding | Evidence noted |
|---|---|---|
| Infrastructure as code | Demonstrated | Walked through their module structure and state management. Described a drift problem and how it was resolved. |
| Kubernetes operations | Demonstrated | Comfortable with cluster upgrades, resource limits and debugging failed deployments. |
| CI/CD and release | Partly demonstrated | Solid pipeline design. Less exposure to progressive delivery such as canary releases and feature flags. |
| Incidents and observability | Demonstrated | Gave a clear account of a production incident, their part in it, and what changed afterwards. |
| Cloud cost management | Not assessed | Not covered. Worth exploring at interview. |
4Working style
Methodical and clear. Prefers a short written design note before large changes. Asked useful questions about where the team’s ownership starts and stops.
5Alignment to the role
Close match on stack and scale. On-call expectations were discussed and accepted.
6Logistics
Notice: One month
Location: Hybrid, London
Salary: Shared with client separately
7Risks and limitations
Limited multi-region experience, which the brief lists as desirable. Has not managed people.
Assessor sign-offVetted by Engineers.
Illustrative sample. The candidate, brief and findings are fictional and show the format only.
Technical Audit RecordBoolean Group
TAR-SAMPLE-BE
Illustrative sample
1Summary
Capable backend engineer with good habits and clear reasoning, strongest on API and data design. Recommended for interview at mid to senior level.
2Relevant experience
Four years across two product companies, mainly Python services on PostgreSQL. Built and owned a billing service end to end.
3Capability assessment
| Area | Finding | Evidence noted |
|---|---|---|
| API design | Demonstrated | Designed a versioned API during the exercise and justified their choices on pagination and error handling. |
| Data modelling | Demonstrated | Produced a sensible schema and explained where they would denormalise for read performance. |
| Testing practice | Demonstrated | Writes tests by default. Clear on where unit and integration tests each earn their keep. |
| Messaging and concurrency | Partly demonstrated | Has used queues in production. Reasoning about ordering and idempotency was partly complete. |
| System design at scale | Not assessed | Not assessed at senior depth. Flagged for the client’s own design interview. |
4Working style
Collaborative, thinks aloud, and is comfortable saying when they do not know something. Prefers small, frequent releases.
5Alignment to the role
Strong on language, database and remote working. Event-driven experience is lighter than the brief describes.
6Logistics
Notice: Three months, negotiable
Location: Remote, UK
Salary: Shared with client separately
7Risks and limitations
Notice period runs past the client’s preferred start date. Event-driven work would be a step up.
Assessor sign-offVetted by Engineers.
Illustrative sample. The candidate, brief and findings are fictional and show the format only.
Technical Audit RecordBoolean Group
TAR-SAMPLE-SA
Illustrative sample
1Summary
Analyst with a careful, evidence-led approach to investigation. Ready for a level-two role with support on leading incidents.
2Relevant experience
Two years in a managed security provider’s SOC on a shift rota, triaging alerts across several client environments. Some threat-hunting work.
3Capability assessment
| Area | Finding | Evidence noted |
|---|---|---|
| Alert triage | Demonstrated | Worked through sample alerts in a sensible order and separated noise from likely incidents. |
| Log analysis | Demonstrated | Wrote reasonable queries to answer an investigation question and explained what each one was for. |
| Incident handling | Partly demonstrated | Understands the incident lifecycle. Has supported containment but not led it. |
| Threat knowledge | Demonstrated | Mapped observed activity to common attacker techniques without prompting. |
| Cloud security | Not assessed | Outside the core requirements of this role, so not assessed. |
4Working style
Calm under pressure, careful with evidence, writes clear notes. Would do well in a team with structured mentoring.
5Alignment to the role
Matches the SIEM, the rota and the level. Has worked shifts before and understands the commitment.
6Logistics
Notice: One month
Location: On-site, Manchester
Salary: Shared with client separately
7Risks and limitations
Has not yet led an incident from detection to closure. Would need support to step into that role.
Assessor sign-offVetted by Engineers.
Illustrative sample. The candidate, brief and findings are fictional and show the format only.
Technical Audit RecordBoolean Group
TAR-SAMPLE-PM
Illustrative sample
1Summary
Product manager with a strong working relationship with engineers and a disciplined approach to prioritisation. Recommended for interview.
2Relevant experience
Three years as product manager for internal developer tools, previously a business analyst. At ease with technical stakeholders.
3Capability assessment
| Area | Finding | Evidence noted |
|---|---|---|
| Problem framing | Demonstrated | Narrowed an ambiguous case study to a testable problem before proposing any solution. |
| Prioritisation | Demonstrated | Made trade-offs explicit and said what they would deliberately not build, and why. |
| Working with engineering | Demonstrated | Gave specific examples of negotiating scope. Treats technical debt as a product decision. |
| Metrics and outcomes | Partly demonstrated | Clear on outcome measures. Less experience setting up measurement from scratch. |
| Pricing and commercials | Not assessed | Not part of this brief, so not assessed. |
4Working style
Structured and direct. Writes concise product briefs and listens before proposing.
5Alignment to the role
A good fit for a platform team whose users are engineers. Less exposure to external customer research.
6Logistics
Notice: Two months
Location: Hybrid, Bristol
Salary: Shared with client separately
7Risks and limitations
Limited external customer discovery. The client should test this if it is central to the role.
Assessor sign-offVetted by Engineers.
Illustrative sample. The candidate, brief and findings are fictional and show the format only.
Illustrative sample. Real records are prepared for a specific brief and shared only with the client and with the candidate’s consent.
What the record is not
The Technical Audit Record is a structured professional opinion, intended to make your hiring decision better informed. It is not a certification, a guarantee of performance, or a background check.
- It does not replace your own interviews or your hiring decision.
- We do not carry out criminal record, credit, right-to-work or reference checks. Those remain with the employer.
- What a candidate tells us about their history is recorded as such, not independently verified.
Full detail is in our terms of use.
The process, step by step
- 01
Brief and calibration
We agree what the role needs and what the assessment should cover, ideally with the hiring manager.
- 02
Search and initial screen
We identify relevant people and check motivation, logistics and expectations first.
- 03
Technical assessment
Structured, role-specific, and designed around your brief.
- 04
Technical Audit Record
Written for each candidate who meets the bar, and shared with the candidate’s consent.
- 05
Introduction
A short shortlist, interviews arranged, feedback gathered and passed on to both sides.
Tell us what you’re hiring for.
A short brief is enough to start. We reply to every enquiry within two working days, and we will tell you plainly if we are not the right fit for the role.
Or email us directly:
team@booleangroup.co.uk