Nearshore role scorecard template

What should a busy buyer put in the scorecard?

Start with the work you need someone to own. Name the first useful result, who will accept it, and what evidence will show that it works.

For a software engineer, that might be a small production change with tests and a documented rollback path. For a support role, it might be a resolved case with a clear customer reply. Pick work that belongs to the role.

Then agree on the hiring bar before anyone reviews a resume. The hiring manager should approve the outcomes. Interviewers should agree on what counts as a passing answer.

Copy this role definition

Replace the bracketed text before you send the scorecard to a recruiter or candidate.

Write outcomes that a reviewer can accept or reject. "Help improve the platform" gives interviewers little to test. "Ship an agreed API change with tests and a rollback note" gives them a concrete task.

Do not assign a new hire a result they cannot control. If success depends on access, an upstream team, or a product decision, record that dependency. Name the person responsible for clearing it.

Use an evidence table during interviews

The following is a suggested engineering scorecard. Its weights are an example, not a hiring benchmark. Change them before the search if the role has different demands.

Keep mandatory requirements outside the weighted total. Required working hours, an essential skill, or an agreed access policy should have a separate pass or fail check. A high total should not hide a failed requirement.

Use these rating definitions as a starting point:

• 1: The work misses the stated requirement.
• 2: The work meets part of the requirement but needs substantial help.
• 3: The work meets the requirement with the support planned for this role.
• 4: The work meets the requirement and shows sound judgment on a relevant complication.

Leave untested items blank. A blank means the interviewer still needs evidence; it should not become a low score by default.

For each rating, save a short note that points to something observable. "Found a duplicate-event bug and added a test" supports a decision. "Seems sharp" does not explain what the candidate can do.

Make the work sample resemble the job

For a backend role, you could ask candidates to review a small API change and explain how they would test it. Supply enough context to make the task fair. State the expected time, permitted tools, and submission format.

Use synthetic data and a bounded exercise. Avoid asking candidates to solve a live customer problem or handle production credentials.

Decide how AI tools fit the exercise before it begins. If they are allowed, ask candidates to explain their changes and verify the result. If a part must be completed without them, say so in advance.

Give every candidate the same core instructions. Allow reasonable accommodations without changing the skill you assess. Interviewers should score their own evidence before the group discusses a finalist.

Fill out a sample row before using the template

Consider an illustrative role that owns a customer-facing API. The first-month outcome could be an approved change to how the API handles duplicate requests. The manager supplies a test environment and names the reviewer.

The assessment can use a small, fictional version of that problem. Ask the candidate to explain what happens when a request arrives twice. Let them inspect the code, propose a change, and describe how they would check it.

A completed evidence row might read:

The follow-up should test a job requirement you already agreed on. Do not add an advanced systems question merely because the candidate finished early.

Run the sample past the hiring manager before interviews begin. If two reviewers assign different ratings to the same work, resolve that difference now. Clarify how much help is acceptable and which errors would prevent a passing score.

What does the data say about budget and Latin American overlap?

Use market data to check the role's budget and schedule. Keep those checks separate from the evidence that a person can do the job.

Use US wage data as a defined comparison

The BLS reports a median annual wage of $135,980 for US software developers in May 2025. Its figure for software quality assurance analysts and testers is $104,300. These are different occupations, so choose the comparison that matches the work. BLS Occupational Outlook Handbook

The BLS Occupational Employment and Wage Statistics program provides occupation-based wage data. A national median does not establish the right offer for a specific seniority, specialty, or location.

Put the following fields beside your scorecard:

Do not treat a US wage figure and a provider's monthly invoice as equivalent cost measures. Establish what each amount covers before calculating a difference.

A salary benchmark also cannot decide whether your role needs a senior hire. Define the decisions the person must make alone. Then test those decisions in the assessment.

If the quotes exceed your budget, return to the scope. Decide whether some work can stay with an existing team member. You can then assess a narrower role without quietly expecting senior ownership from someone hired for a different job.

Keep that change visible in the role definition. Update the work sample and rating rules before asking the provider for another shortlist.

Record overlap by city and season

Mexico City uses UTC-6 without daylight saving time. Tijuana follows US daylight saving changes, so a country-level schedule can miss a relevant difference. IANA North America time-zone data

Bogotá uses UTC-5 year-round. Buenos Aires and São Paulo use UTC-3 without daylight saving time. Their difference from a US team's clock can change when that US location changes clocks. IANA South America time-zone data

Write the schedule as an agreement. For example:

Required shared hours: [start] to [end], America/New_York. Confirm the candidate's local hours during US standard time and US daylight time. Record any agreed schedule changes.

Separate routine meetings from incident coverage. A person who agrees to a daily planning meeting has not necessarily agreed to evening alerts or weekend work.

For a nearshore IT role, identify which tasks need a live response. Code review may tolerate a delay. A production incident may need a defined response window. Put each expectation in the role definition before evaluating availability.

Test the proposed schedule against your actual calendar. Include recurring meetings and the manager's review time. If the only shared hour is already full of meetings, decide when the hire can ask questions about work.

Ask the candidate to confirm the schedule in their local time. Save both versions with the scorecard so the manager can check them when clocks change.

How do hiring models change the scorecard?

Keep the job's performance bar consistent. Change the questions about who finds the candidate, who handles employment duties, and who manages delivery.

Use the model descriptions below to frame your evaluation. Confirm the actual scope in each proposal and contract.

Match the assessment to what you are buying

If you will manage an individual day to day, assess that person's work. Meet the proposed hire and review their evidence.

If you are buying delivery from a team, define the output you will accept. Ask who owns technical decisions, how changes are priced, and who fixes rejected work. An individual interview score cannot answer those contract questions.

Keep a separate provider worksheet. It should record commercial terms and duties without changing a candidate's technical score.

For example, a clear billing proposal may help you choose a provider. It should not add points to a developer's work sample. Likewise, a strong developer does not settle unclear contract terms.

Keep ownership visible after the offer

Assign a named owner to equipment, accounts, onboarding, and the first work review. Make clear which duties sit with your team and which sit with the provider.

Carry the agreed outcomes into onboarding. At the first review, compare the actual work with the same expectations used during hiring.

If priorities change, update the scorecard and tell the hire. Do not assess someone against a new goal that was never discussed.

Before the search starts, also decide how much support the manager can provide. A role with daily coaching can accept different evidence from one that requires independent ownership. Make that distinction explicit in the rating definitions.

Use the first review to separate a skill problem from a blocked assignment. Check whether the hire received the promised access and whether the reviewer was available. Record missed dependencies alongside the result.

If the work meets the agreed standard, save the accepted deliverable as an example for future reviews. If it falls short, name the specific gap and the support planned to address it. Avoid replacing the original scorecard with a general impression of how the month felt.

What should you ask a provider before reviewing candidates?

Send the approved scorecard with your request. Ask the provider to return evidence against each required item, including any checks your team must still complete.

A candidate summary should make the next interview easier to plan. It should show which requirements have been assessed and where a focused follow-up is needed.

Ask for evidence behind each recommendation

Use questions tied to the role:

• Which work sample supports the candidate's core technical rating?
• What did the candidate complete independently?
• What help or tools were permitted?
• Which requirement did the candidate struggle with?
• Who assessed the work, and what rating definitions did they use?
• Can the candidate explain the result in a live discussion?
• Which checks remain for our team?

Request a sample assessment record before agreeing on the process. Remove personal data if it belongs to someone outside your search.

Compare the evidence with your own scorecard. If the provider tests a different stack or a broader role, decide which checks transfer and which must be repeated.

For written English, ask for a job-relevant task. A release note, customer reply, or incident update gives you something to assess. Score whether the intended reader can understand the issue and take the next step.

Avoid a vague "culture fit" rating. Replace it with behaviors the role needs, such as raising a blocker early or documenting a decision for colleagues.

Confirm practical constraints with the candidate

Ask the provider to confirm the proposed hours with the person. Record the named time zone, seasonal changes, and any regular exceptions.

Ask about the expected start date separately from acceptance of an offer. Build the onboarding plan around the agreed first working day.

For roles with sensitive access, specify the checks your team requires before granting it. Decide who approves access and how accounts will be closed when work ends.

Share the actual constraints early. A late change to working hours or required office attendance can invalidate an otherwise strong match.

Review the commercial terms beside the scorecard

Ask for a written proposal that states:

• The recurring charge and billing currency.
• Included services and separately billed items.
• The process for pay changes and rate reviews.
• Notice, cancellation, and replacement terms.
• Who handles payroll questions and employment administration.
• What happens while a replacement search is underway.

Keep a record of the answer and the contract section that governs it. A verbal explanation should not be the only record of a term your budget depends on.

If interviewers disagree, return to the disputed requirement. Ask whether they saw different evidence or applied different standards. Use a narrow follow-up task when the evidence is incomplete.

Do not change weights to favor a candidate after interviews. If the role has changed, revise the scorecard and reassess the shortlist against the new version.

Close the decision with a written record

Give the decision owner a short record for each finalist. Include passed mandatory checks, the scored evidence, and unresolved questions. Name who will resolve each question before an offer.

A decision note can say: "Proceed once the candidate confirms shared hours and explains the failed retry test." That gives the next interviewer a specific task. "One more conversation to be sure" does not.

If you reject a candidate, record the job requirement that drove the decision. Keep comments tied to evidence from the assessment. Follow your team's rules for storing candidate records and limiting access.

To discuss the role with Opus, use the completed outcomes and evidence table. This site is an Opus-owned reference; recommendations are editorial.

Talk to Opus about a role

Where does Opus fit in your hiring decision?

Opus states: "The client chooses the finalist and manages day-to-day work."

That division makes the hiring manager's scorecard part of the decision. Your team should define the work, assess the finalist, and agree on the first review.

Opus describes its pricing as follows:

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.

Published dollar rates: Not published.

Ask for a written quote tied to the role, level, and location you are considering. Compare it with your approved budget and record any costs your team will pay separately.

Opus also states: "Every placement carries a lifetime replacement guarantee with no cap and no time limit."

Ask how that term applies to your agreement, what starts a replacement search, and how billing works during a transition. Continue to assess the finalist against the role's requirements.

Before the conversation, complete the role purpose, first deliverable, mandatory checks, and shared working hours. Name the person who will review candidate evidence and the person who can approve the quote.

Leave room to discuss which skills can be taught. If your manager can coach someone on an internal tool, say so. If the hire must own a production system from the start, make that requirement explicit.

Send the same approved scorecard to everyone involved in the decision. Ask for candidate evidence against its rows, then use those rows in the finalist interview and first work review.

Talk to Opus about a role

<!-- File not saved because the workspace is read-only. Score weights and assessment examples are illustrative. -->