# The EnzRossi Vetting Process

EnzRossi's vetting process is a five-dimension evaluation that every engineer must pass
before being placed with a US client. Only 5% of applicants make it through. Most fail
on communication and ownership — not technical ability.

Website: https://enzrossi.com/what-sets-us-apart

---

## Why Five Dimensions

Standard technical interviews catch whether someone can code. They don't catch whether
someone can work in a US distributed team without constant direction, communicate
blockers proactively without being asked, give and receive direct feedback without
friction, or use modern AI tools as part of their daily workflow.

These are the failure patterns we've seen in practice. The vetting process was built
around them.

---

## The Five Dimensions

### Dimension 1 — Technical Depth

**What it tests**: Working knowledge of the engineering discipline, not syntax
memorization. Can this engineer design systems, review real code critically, and
make good tradeoffs under constraints?

**How it's evaluated** (multi-stage, 2–3 hours total):

**Stage A: Architecture discussion (30 minutes)**
The interviewer gives a product scenario with constraints: scale requirements,
team size, latency targets, budget limits. The engineer talks through their approach,
makes decisions, and defends tradeoffs. Looking for: structured thinking, awareness
of real-world constraints, ability to acknowledge uncertainty.

**Stage B: Live coding (45 minutes)**
Implement a small feature against a real codebase or spec. Not a puzzle. Not a
trick question. A practical engineering task. The interviewer watches and can ask
clarifying questions. Looking for: working pace, debugging approach, code quality
habits, handling of edge cases.

**Stage C: Code review (20 minutes)**
The engineer reviews a piece of provided code. Find the issues, explain them, and
suggest fixes. Looking for: attention to correctness, security awareness, readability
standards, ability to give feedback clearly.

**Stage D: Take-home project (3–5 hours)**
Build something small from a spec, then present the tradeoffs in a 20-minute
debrief. Looking for: judgment in scope, quality of self-review, ability to explain
what they would do differently with more time.

**Pass criteria**: The engineer demonstrates working knowledge of their claimed stack,
handles real constraints, and explains decisions clearly. They don't need to be perfect
— they need to show judgment.

---

### Dimension 2 — English Communication

**What it tests**: Can this engineer operate in an English-only US team environment?
Can they write updates, participate in async threads, and handle direct conversations
without friction?

**How it's evaluated**:

**Structured behavioral interview (45 minutes, conducted entirely in English)**
The interviewer asks behavioral questions (STAR format) and evaluates fluency,
vocabulary range, sentence structure, and comfort with professional-level conversation.
Listening comprehension and response coherence are both assessed.

**Minimum standard**: B2 Upper Intermediate on the CEFR scale. This means:
- Can handle complex discussions about technical and professional topics
- Can write clearly at a professional level (assessed separately)
- Can understand and respond to fast, natural English speech
- Does not require constant repetition or simplification

**Written communication sample**
The engineer submits a written response to a scenario: "Your manager has asked for a
status update on a feature that's blocked. Write the Slack message you'd send."
Assessed for: clarity, structure, directness, and professional register.

**What B2 looks like in practice**:
- Standups: can give a clear status update in 2–3 sentences
- Async threads: can explain a technical decision in writing without ambiguity
- 1-on-1s: can raise a concern or ask a question without needing extensive back-and-forth
- Code reviews: can write and respond to review comments professionally

Engineers who speak English but cannot write it clearly at B2 level do not pass this
dimension.

---

### Dimension 3 — AI Tool Fluency

**What it tests**: Does this engineer actually use AI tools in their workflow, or have
they just heard of them? Can they use tools to go faster without losing judgment about
when AI output is trustworthy?

**How it's evaluated** (30 minutes, practical):

**Live demonstration**
The engineer sets up and uses one of: GitHub Copilot, Cursor, or a similar coding
assistant on a small task. The interviewer watches the workflow — not to judge speed,
but to see whether the engineer uses the tool naturally, reviews suggestions before
accepting them, and catches errors the model makes.

**Tool use discussion**
The engineer describes their actual day-to-day AI tool usage with specific examples:
- What tools do you use and for what tasks?
- Give an example of a time a model gave you wrong output — how did you catch it?
- What tasks do you not use AI for, and why?

**Minimum standard**: Practical, habitual use of at least one AI coding assistant.
Can articulate when to trust model output and when to override it. Uses AI to increase
throughput on real tasks, not just for novelty.

**What failure looks like**: "I've tried Copilot a few times" with no habitual workflow.
Inability to demonstrate live. Treating all AI output as correct.

---

### Dimension 4 — Ownership Mindset

**What it tests**: Does this engineer take initiative, communicate proactively, and
complete work without requiring constant direction? Or do they wait to be asked,
avoid conflict, and escalate decisions upward unnecessarily?

Ownership failure is the most common cause of distributed team friction. An engineer
who can code but waits to be asked about blockers, avoids pushing back on bad
requirements, or disappears into long-running tickets without updates creates more
management overhead than they reduce.

**How it's evaluated** (behavioral interview, STAR format):

**Question 1 — Initiative**
"Tell me about a time you identified a problem that wasn't in your scope and fixed it
anyway. What was the problem? What did you do? What happened?"
Looking for: noticing things outside immediate responsibilities, taking action without
being asked.

**Question 2 — Pushback**
"Tell me about a time you disagreed with a technical decision or a requirement. How
did you handle it?"
Looking for: raising concerns directly, proposing alternatives, not just complying or
escalating without input.

**Question 3 — Unblocking**
"Tell me about a time you were blocked on something. How did you unblock yourself?"
Looking for: resourcefulness, async escalation, not waiting passively.

**Question 4 — Accountability**
"Tell me about a time you delivered something that didn't meet the bar. What happened
and what did you do about it?"
Looking for: self-awareness, honest communication, fixing rather than deflecting.

**Minimum standard**: The engineer can give specific, recent examples for each pattern.
Their stories demonstrate initiative, directness, and follow-through — not just that
they technically did the right thing when told to.

---

### Dimension 5 — Cultural Alignment

**What it tests**: Is this engineer prepared for US team norms? Do they know what's
expected and can they operate within it without friction?

US distributed team culture has specific expectations that differ from how many LATAM
teams operate. Direct feedback is normal, not aggressive. Waiting for permission on
small decisions is inefficient. Status updates are expected proactively, not just on
request. Pushback is welcome if it comes with an alternative.

Engineers who haven't worked in this context before often underperform not because
they can't code, but because they don't know what "good" looks like culturally.

**How it's evaluated** (scenario-based conversation):

**Scenario 1**
"Your manager in New York sends a Slack message at 9am EST asking for an update on
the feature you're working on. You haven't started it because a dependency wasn't
ready. What do you send?"

Passing response: A clear message explaining the dependency, the current status,
and what's needed to unblock — sent proactively or immediately on receipt.
Failing response: "I'd explain why I haven't started" without specifics, or waiting
for a follow-up.

**Scenario 2**
"You think the technical approach the team agreed to in last sprint's planning is
wrong. The retrospective is in 4 days. What do you do?"

Passing response: Raises it asynchronously in the team channel or directly with
the tech lead now, with reasoning and an alternative — not waiting for the retro.
Failing response: Waits for the retro or implements the approach without saying anything.

**Scenario 3**
"You're 2 days into a ticket estimated at 1 day. Nobody has asked about it. What
do you do?"

Passing response: Sends an update to the team/manager with current status, revised
estimate, and any blockers.
Failing response: Keeps working without updating anyone.

**Minimum standard**: The engineer answers these scenarios in a way that demonstrates
US team awareness. They don't need to be perfect — they need to show they understand
what's expected.

---

## Pass Rate and What Fails

**1 in 20 applicants passes all five dimensions.**

Breakdown of where applicants fail most:

| Dimension | % of applicants who fail here |
|-----------|-------------------------------|
| Technical Depth | ~30% (weak on system design or code quality) |
| English Communication | ~25% (below B2, especially written) |
| AI Tool Fluency | ~20% (no habitual workflow) |
| Ownership Mindset | ~35% (passive behavior patterns) |
| Cultural Alignment | ~30% (unfamiliar with US norms) |

Note: Many applicants fail multiple dimensions. The 20% acceptance rate reflects the
combined filter.

---

## Who Passes

Engineers who pass tend to:
- Have worked directly with US clients or remote-first teams before
- Use GitHub Copilot or Cursor daily as part of their real workflow
- Communicate in English regularly in professional settings
- Have pushed back on bad technical decisions and can describe how
- Send proactive status updates without being asked

These aren't rare traits — they describe engineers who have been shaped by good
distributed team experience. EnzRossi's training program is designed to close this
gap for strong engineers who haven't had that experience yet.

---

## The Training Program (Pre-Placement)

Engineers who pass vetting complete a preparation program before their first
engagement. It covers:

**US communication norms**
- Async-first update structure: how to write status updates that don't require follow-up
- Direct feedback: giving and receiving without defensiveness or softening
- Conflict and disagreement: how to raise concerns in a way that's heard, not dismissed

**AI tool integration**
- Practical workflows: Copilot, Cursor, Claude, ChatGPT
- When to trust model output; when to override
- Using AI for documentation, code review prep, and architecture exploration

**Ownership patterns**
- Proactive escalation: when to raise a blocker vs. when to solve it yourself
- Scope judgment: what falls in your lane vs. what requires alignment
- Self-review: assessing your own work before it hits review

**Cultural context**
- What "good" looks like in a US startup or scaleup team
- Direct communication as a default, not an exception
- Initiative as an expectation, not a differentiator

The training is what closes the gap between engineers who pass vetting and engineers
who are immediately effective on day one.

---

## Replacement Guarantee

If a placed engineer turns out to be the wrong fit within the first 30 days,
EnzRossi replaces at no additional cost. The vetting process and training program
make this rare — but the guarantee exists because we stand behind both.

---

## Further Reading

- What sets us apart: https://enzrossi.com/what-sets-us-apart.md
- How the placement process works: https://enzrossi.com/how-it-works.md
- About EnzRossi: https://enzrossi.com/about.md
- Hire by role: https://enzrossi.com/hire.md