Companies Hire for Hard Skills and Fire for Soft Skills. Here Is How to Stop.

Here is a stat that nobody tracks but everyone feels: the majority of developer terminations in the first year have nothing to do with technical ability.

The developer knew the stack. They passed the coding test. They could talk about system design in an interview. But three months in, things started breaking down. They missed deadlines without flagging them early. Their pull request descriptions were one-liners. They got defensive in code reviews. They worked in isolation when the feature needed collaboration.

We see this pattern constantly. After placing over 200 engineers with US companies, it shows up in roughly the same way every time: a company hires someone who looks technically perfect on paper and then parts ways within 6-12 months because of everything that paper doesn't measure.

The pattern we keep seeing

It looks like this. A company posts a job for a senior React developer. Fifty people apply. The hiring team filters by years of experience, framework knowledge, and coding challenge scores. They interview the top three. One candidate nails the technical round: clean code, correct answers, solid system design.

They get the offer.

Week one is fine. Week four, the engineering manager notices this person never speaks up in standups unless directly asked. Week eight, a production issue sits unescalated for six hours because the developer wasn't sure who to tell. Week twelve, a teammate asks to pair on a complex feature and gets brushed off.

By month six, the manager is spending more time managing this one person than the rest of the team combined. The developer is skilled. They are not effective.

Why this happens

Hiring processes are built to measure what's easy to measure. Coding tests have right and wrong answers. Years of experience fit in a spreadsheet column. Framework knowledge maps to a checklist.

Communication, ownership, judgment under ambiguity: these don't fit in a spreadsheet. So most hiring processes skip them entirely, or reduce them to a "culture fit" chat that amounts to "would I want to grab a beer with this person?"

That's not a process. That's a coin flip dressed up as an interview.

The result is predictable. You hire for the thing you measured (technical skill) and fire for the thing you didn't (everything else).

What "soft skills" actually means in engineering

The phrase "soft skills" does a disservice to what we're actually talking about. These aren't soft. They are the skills that determine whether a technically capable person actually delivers value on a team.

Here's what we mean when we evaluate soft skills at EnzRossi:

Proactive communication. When a developer hits a blocker, do they sit on it for two days or flag it within hours? When a deadline is at risk, do they tell the team before it slips or after? This is the single biggest predictor of whether a remote developer will succeed.

Written clarity. Remote teams run on writing: Slack messages, PR descriptions, Notion docs, async updates. A developer who writes clearly multiplies the team's speed. A developer who writes poorly creates a constant tax on everyone else.

Ownership behavior. This is the difference between "I finished my ticket" and "I finished my ticket, noticed the integration tests were flaky, fixed them, and updated the docs." Ownership means thinking beyond the edges of your assigned task.

Feedback receptiveness. How does a person respond when their code gets pushback? Do they engage with the feedback, or do they get defensive? Code review is where team culture lives or dies.

Judgment under ambiguity. Requirements are never perfect. When a spec has a gap, does the developer freeze, build the wrong thing, or ask the right clarifying question? This is especially critical in remote teams where you can't just tap someone on the shoulder.

How to screen for these before you hire

The good news: you can absolutely evaluate these skills in a hiring process. You just have to be intentional about it.

The interview shift

Replace "tell me about yourself" with scenario questions. Instead of asking a candidate to describe their experience, put them in a situation. "You're two days into a feature and realize the API contract doesn't match the mockup. The designer is on PTO. What do you do?" There's no single right answer, but the way someone thinks through it tells you everything about their communication and judgment patterns.

Do a live collaboration exercise, not a live coding test. Give the candidate a partially built feature with a bug and some unclear requirements. Work through it together over a shared screen. You're not grading whether they find the bug in twelve minutes. You're watching how they ask questions, how they explain their thinking, and how they handle being stuck.

Check async communication directly. Give a take-home exercise and evaluate the submission message as much as the code. Did they explain their approach? Did they note tradeoffs? Did they list what they'd do differently with more time? The code can be great and the communication can be terrible. You need to know both.

Ask for a real conflict story. "Tell me about a time you disagreed with a code review comment." If they can't recall one, they're either too junior or too agreeable. If they describe a situation where they were clearly right and the other person was clearly wrong, that's a red flag. The best answers show someone who engaged with the disagreement productively.

What we do differently

At EnzRossi, every engineer goes through a behavioral interview before we even schedule the technical round. We do this intentionally. If someone can't communicate clearly in a structured conversation, we don't need to see their code.

In that interview, we're evaluating the five things I described above: proactive communication, written clarity, ownership, feedback receptiveness, and judgment. We score each independently. A candidate can be exceptional technically and still not pass our process if they score low on communication or ownership.

This isn't about being picky for the sake of it. It's about respecting our clients' time. Every engineer we place joins a real team with real deadlines. If that engineer creates communication overhead instead of reducing it, we've failed.

The hiring market loves to optimize for speed. "First shortlist in 3 days" is something we promise too. But speed without accuracy is just fast failure. We've built a vetting process that's fast because it's structured, not because it cuts corners.

If you're tired of hiring developers who interview well and deliver poorly, start by flipping your process. Evaluate communication first. Filter for technical skill second. You'll hire fewer people who look good on paper and more people who actually ship.