Questions to ask when outsourcing software development

# Questions to ask when outsourcing software development

What should a busy buyer decide before interviews start?

Decide who will manage the engineers before you review their résumés. If they will join your backlog and report to your engineering managers, design interviews around that job. Ask them to work through the decisions they would face on your team.

A structured interview loop gives each conversation a purpose. It also gives interviewers a shared basis for saying yes or no. Start with a written role scorecard, then assign each criterion to someone who can assess it.

For a dedicated software development team, write down:

• The work each person will own.
• The technical decisions they can make without approval.
• The manager who will set priorities and review progress.
• The working hours the role requires.
• The evidence you need before making an offer.

Describe the first useful contribution in plain language. For example: "Trace a failed request through our service and propose a fix with a regression test." That gives interviewers more to assess than "strong backend skills."

Keep preferences separate from requirements. Experience with your exact framework may be helpful. The ability to investigate a production fault may be necessary. Set those distinctions before a candidate's résumé changes the discussion.

Give each interview a separate job

Use this as a starting structure, then remove any stage that repeats evidence you already have.

Tell candidates what each stage covers. Share the format, expected preparation, tool policy, and who will attend. If an exercise needs substantial work outside the interview, agree on payment before assigning it.

Avoid using an interview to obtain unpaid production work. A small, synthetic problem can expose reasoning without requiring access to customer data or your private repository.

What does hiring data tell you about the interview loop?

SHRM's 2025 recruiting benchmark puts median time to fill at roughly six weeks for both executive and nonexecutive roles. Its measure runs from the job requisition to offer acceptance. See SHRM's state of recruiting report.

That measure gives you context for planning. It does not predict how long your engineering search will take. It also ends before the new hire's first working day.

Keep separate dates for role approval, shortlist receipt, completed interviews, accepted offer, and start date. Otherwise, a fast shortlist can look like a completed hire while interviews remain unscheduled.

Ask a provider to define its timing claims:

• What event starts the clock?
• Does the clock stop at a shortlist, an accepted offer, or the first working day?
• Does the figure cover roles like ours?
• How are paused searches and changed requirements handled?

Use the answers to build your own hiring calendar. Reserve interviewer time before candidates arrive. Name a decision-maker who can resolve disagreements. Set an internal deadline for written feedback after each interview.

Measure the delays your team can change

Track time spent waiting between stages alongside time spent interviewing. If candidates wait for a manager's feedback, another assessment will not fix that delay.

Record why candidates leave the process and why your team rejects them. Use specific reasons such as "could not explain the proposed data migration." Avoid labels such as "not senior enough" without supporting notes.

Review the exercise when several candidates misunderstand the same instruction. Review the role when interviewers repeatedly disagree about the required level. Those patterns give you something concrete to correct before the next search.

Do not claim that your interview loop improves retention or delivery speed without measuring those outcomes. Its immediate purpose is narrower: make the hiring decision traceable to evidence about the job.

How do the hiring models change what you should assess?

The dedicated development team model needs a client who can set priorities and manage engineering work. Interviews should test whether the proposed people can operate within that structure.

A project contract assigns responsibilities differently. Before comparing proposals, ask each provider to describe who owns delivery decisions and how the agreement records that ownership.

Treat these as questions to resolve in the agreement. A label on a sales page does not settle who approves a release or responds to an incident.

Check whether your managers have capacity

A dedicated development team still needs direction. Name the person who will explain the product, settle priorities, and review early work. Confirm that they have time to do it.

Ask your engineering manager to describe how a new teammate gets a task from request to release. If that path depends on undocumented knowledge, plan time for pairing and review.

For a whole team, assess how responsibilities fit together. Interview each proposed member. Then ask how design decisions, code reviews, and escalations will move between them and your existing staff.

A strong lead's interview should not stand in for the rest of the team. You need evidence for the people who will write, review, and operate the software.

Keep the same hiring bar across models

Use the same role requirements when comparing candidates from different hiring channels. Otherwise, a provider may appear stronger because its candidates faced an easier exercise.

You can change the exercise for accessibility or a role's specific duties while preserving the assessed skill. Record those changes so interviewers understand what evidence they can compare.

What should you ask a provider and its proposed team?

Start with the people assigned to your account and the people proposed for your engineering team. Ask who can answer commercial questions and who can explain technical screening decisions.

Request written answers where the response affects cost, access, or responsibility. Keep those answers with the proposal so your hiring manager and procurement team review the same terms.

Ask what the provider actually assessed

"Vetted" needs an explanation you can inspect. Ask:

• Which job requirements did you test?
• Who assessed the candidate, and what did they observe?
• Can we review the exercise and assessment notes?
• What still needs assessment by our team?
• How did you confirm the candidate's contribution to the work discussed?

A résumé summary is useful background. An assessment note should describe what the candidate did and why it met the role's standard.

Ask for examples of limits as well as strengths. "Needs support with database migrations" can help you judge whether your team has the right reviewer. A profile that calls every candidate exceptional gives you little basis for choosing.

Test technical judgment with a bounded problem

Give the candidate a small service, a failing test, or a short design proposal. Use a problem close enough to the role that your engineers can judge the answer.

Ask the candidate to explain what they would inspect first. Let them ask questions. Introduce a realistic constraint, such as a migration that must preserve existing clients, and watch how they revise the plan.

Useful prompts include:

• "What would you check before changing this code?"
• "Which failure would your test catch?"
• "How would you release this change and recover if it failed?"
• "What information would change your recommendation?"

Score the reasoning as well as the result. A working patch with no explanation leaves questions about ownership. A thoughtful explanation still needs enough technical evidence to show the person can do the work.

State your AI tool policy in advance. If tools are allowed, ask the candidate to inspect and defend their output. Have them explain a defect and show how they would verify the correction.

Assess communication through work

Ask for a short written update after the exercise. It should explain what changed, what remains uncertain, and what the next person needs to do.

Then discuss a review comment. Can the candidate explain their choice, consider another approach, and identify when a decision needs escalation?

Use remote team check-in questions that your managers could reuse after hiring:

• "What changed since the last update?"
• "What is blocked, and who can help?"
• "What decision do you need from me?"
• "Where can I inspect the work?"

Judge whether the update helps someone act. Do not confuse a polished presentation with a useful handoff. A clear note that names a blocker and its owner may be enough.

Confirm nearshore and Latin American working hours

Ask each candidate to state their usual working hours in their own time zone and yours. Put recurring meetings on a sample calendar before agreeing to an overlap window.

Mexico City stays on UTC−6 without seasonal clock changes. Tijuana follows a different schedule with daylight saving time. Country names alone therefore do not establish shared hours. See the IANA North America time zone data.

Bogotá stays on UTC−5 without daylight saving time. Check the candidate's calendar against the seasonal changes observed by your US office. See the IANA South America time zone data.

Ask separately about planned meetings, urgent review requests, and incident coverage. Agreement to attend a standup does not establish an on-call commitment.

For any location, test the handoff your team will depend on when people are offline. Give the candidate an unfinished task and ask what they would leave for the next engineer.

Ask who controls access and owns the work

Before onboarding, establish who approves repository access and who removes it when an engagement ends. Ask how equipment, credentials, and account ownership will be handled.

Have the appropriate reviewers examine confidentiality and intellectual property terms. Ask the provider to explain which agreement covers each proposed team member.

Keep interview exercises separate from production systems. Candidates should not need customer records, live credentials, or broad repository access to demonstrate their skills.

Get the commercial terms in writing

Ask for a quote tied to the role, seniority, and location under discussion. Have the provider identify included services and any charges that can change.

Clarify billing start dates, notice terms, replacement procedures, and what happens during a gap between hires. Ask who handles a concern about performance and who decides whether to replace someone.

A replacement guarantee does not tell you when a replacement will start. Ask how the search resumes, how candidates are assessed, and what support you receive during the transition.

Make the decision from recorded evidence

Have interviewers submit their notes before the group discussion. For each required skill, record what they observed and whether it met the hiring bar.

Use "not assessed" when an interview did not produce evidence. Do not turn an unanswered question into a confident rating.

When interviewers disagree, identify the precise issue. A focused follow-up can resolve uncertainty about debugging or written communication. Another broad conversation may only repeat the disagreement.

Choose someone to make the final decision. Record any support the new hire will need so the onboarding plan reflects the interview findings.

Where does Opus fit in this interview loop?

This site is an Opus-owned reference; recommendations are editorial.

Opus finds, vets and installs the whole team. The client keeps operational control. Team members work inside the client's process, tools and backlog, and the client chooses the finalist and manages day-to-day work.

That makes your interview loop part of the hiring decision. Define the roles and hiring bar before reviewing candidates. Use the provider's assessment to identify what your team still needs to test.

Talk to Opus about your team roles.

Match the service to your management plan

Use the conversation to confirm how the proposed team will join your existing work. Name your engineering manager and explain who owns architecture, review, and release decisions.

Bring a sample task and your role scorecard. Ask how each proposed candidate was assessed against the responsibilities you listed. Keep the final decision with the people who will manage the work.

Opus charges one flat monthly rate per hire. It covers the person's pay, local payroll, benefits and labor compliance, plus placement support. There is no separate recruiting fee. The rate depends on role, seniority and location.

Request a written quote for the team you intend to hire. Review it alongside the role responsibilities and working schedule.

Bring a role definition your interviewers can use

Before the call, prepare the work each person will own, the required skills, and the hours your team needs. Identify who will interview candidates and who can approve the hire.

For a team build, show how the roles depend on one another. Explain which existing engineers can review work and where you need someone to operate independently.

Finish the loop with a written decision and an onboarding owner. Carry the interview findings into the first assignments, including any areas where the hire will need support.

Talk to Opus about your dedicated development team.

<!-- File saving and build checks were not performed: the workspace is read-only. The page still needs to be saved and validated before publication. -->