Hiring Software Engineers: What Technical Due Diligence Looks Like

The Problem with Hiring Developers

Most business owners hire software engineers the same way they'd hire other professionals: review credentials, check references, evaluate proposals. This approach fails because software development is fundamentally different from most professional services.

A lawyer who wins cases has proven competence. An architect with built buildings has demonstrated ability. But a developer with a portfolio might have copied code, worked on small parts of larger projects, or built things that failed six months later.

This guide explains what technical due diligence actually looks like—even if you're not technical yourself.

What You're Actually Evaluating

When you hire a software engineer or team, you're evaluating four things:

1. Can they build what you need? Technical capability to execute your specific project—not generic programming ability.

2. Will the result be maintainable? Code that works on day one but can't be modified is worthless. You need work that can evolve.

3. Can they communicate effectively? Technical work requires constant clarification. Poor communication causes project failure more than poor coding.

4. Will they be available when things break? Software always has problems after launch. A developer who disappears is a liability, not an asset.

Red Flags That Predict Failure

Before discussing what to look for, here's what to avoid:

"We can build anything" Good engineers are specific about their expertise. Someone who claims to be expert in everything is expert in nothing. Specialization is a positive signal.

No questions about your business If a developer doesn't ask detailed questions about your operations, workflows, and users, they're planning to build generic software that won't fit your needs.

Technology-first proposals "We'll use React, Node.js, AWS..." before understanding your requirements means they're selling their skills, not solving your problem.

No discussion of maintenance If the proposal doesn't address ongoing support, updates, and evolution, you're buying a product with a two-year expiration date.

Unwillingness to share code Developers who won't show previous work—even in redacted form—may have nothing to show. Request code samples and architecture documentation.

Price is dramatically lower If a proposal is 50% cheaper than others, something is wrong. They may be offshore with communication challenges, junior developers without disclosure, or planning to cut corners.

Questions That Reveal Competence

These questions help evaluate technical capability even if you're not technical:

"Describe a project that failed. What happened?" Good engineers have failed and learned from it. Anyone who claims 100% success is either lying or hasn't done complex work. Listen for honest reflection and lessons learned.

"Walk me through how you'd approach our project" You want to hear: requirements clarification, research phase, architecture decisions, iterative development, testing, deployment, maintenance planning. If they jump straight to building, they're not planning.

"What would you NOT use for this project?" Technical judgment is as much about knowing what to avoid as what to use. Good engineers can explain why certain popular technologies are wrong for your specific needs.

"How would you handle a major change in requirements halfway through?" This happens on every project. The answer should involve: impact assessment, options presentation, timeline adjustment, communication about trade-offs. Not just "we'll handle it."

"What happens if you get hit by a bus?" Crude but important. The answer should involve documentation, code ownership transfer, and planning for continuity. If the answer is awkward silence, the project will be vulnerable.

Evaluating a Portfolio

When reviewing previous work:

Look for complexity, not beauty A visually stunning website might be a WordPress template. A ugly internal tool might represent sophisticated engineering. Ask about the technical challenges, not the visual design.

Ask about their specific contribution "I worked on the payment system" is different from "I built the payment system." Clarify exactly what they did versus what the team did.

Contact references, but ask the right questions Don't ask "were they good?" Ask:

• Did the project stay within budget? By how much?
• How long after launch did they provide support?
• Were there major issues discovered after launch?
• Would you hire them again for a similar project?

Verify claims independently If they claim to have built a system, find out if it's still running. Check if the company still uses it. Software that was replaced or abandoned tells a story.

The Technical Interview (Even for Non-Technical People)

You can evaluate technical competence without being technical yourself:

Ask them to explain something complex simply Request an explanation of a technical concept from their proposal. If they can't explain it clearly to a non-technical person, they may not understand it deeply themselves—or they can't communicate effectively.

Bring a technical advisor for one conversation Hire a consultant for a single hour to review the proposal and sit in on one meeting. This is cheap insurance. They can identify unrealistic promises, inappropriate technology choices, and missing considerations.

Request a small paid trial Before committing to a large project, commission a small piece of work. This reveals communication patterns, code quality, and working style. A few thousand dollars spent here can save tens of thousands later.

Contract Provisions That Protect You

Technical due diligence extends to the contract:

Source code ownership You must own the code from day one. This should be explicit, not assumed. The contract should specify that all code, documentation, and related materials are your property.

Regular code delivery Require code to be delivered to your repository weekly, not just at project end. This prevents "90% complete" situations that never reach 100%.

Documentation requirements Specify that documentation is a deliverable, not an extra. Define what documentation means: deployment procedures, architecture decisions, code comments, user guides.

Maintenance terms Include post-launch support terms. What's the response time for critical issues? What's included versus billable? How long are they committed to availability?

Exit provisions What happens if you need to end the relationship? The contract should specify code handoff procedures, knowledge transfer sessions, and transition support.

Warning Signs During the Project

Even with good due diligence, problems can emerge:

Scope changes without communication If features are added or modified without clear discussion of impact, the project is heading for budget overrun or failure.

Deadline slides without explanation One missed deadline might be acceptable. A pattern of missed deadlines with vague explanations indicates deeper problems.

Resistance to showing work in progress Developers who don't want you to see incomplete work may be hiding problems. Regular demos should be part of any healthy project.

"Technical debt" justifications Some technical debt is normal. Constant invocation of "technical debt" to explain delays or problems suggests poor planning or execution.

Team changes without notice If the people who started the project aren't the ones finishing it—and you weren't informed—quality and knowledge transfer are at risk.

The Relationship That Works

The best development relationships I've seen share these characteristics:

• Clear, frequent communication (at least weekly)
• Documented decisions and rationale
• Regular working demonstrations
• Honest discussion of problems and trade-offs
• Mutual respect and reasonable expectations
• Long-term thinking beyond the initial project

You're not just buying code—you're entering a relationship that will last years if successful. Evaluate accordingly.

Related Reading

• Why Custom Software Projects Fail
• When Custom Software Is the Wrong Choice
• How Doctors Should Evaluate Technical Partners