How to hire alexa skill developers with a role scorecard

# How to hire alexa skill developers with a role scorecard

What should a busy buyer put in the scorecard?

Start with the work the person will own after joining. "Build Alexa skills" leaves too much room for different interpretations. A candidate might expect a prototype while your team expects someone to maintain a live service.

Write a short role statement before opening the search:

Own the agreed voice experience from design through release and ongoing support. Work with our product owner and backend team. Document failure behavior, test the release, and leave a handoff another engineer can use.

Edit that statement to match your actual team. If the hire will only handle backend work, say so. If someone else owns dialogue design or release approval, name that person.

The scorecard should answer two questions: what must this person deliver, and what evidence would make you trust them with that work?

Copy this role definition

Fill in these fields with the engineering manager who will supervise the hire.

Avoid listing every tool your company uses as a requirement. For each item, ask what would fail if the candidate needed help with it. If the answer is minor onboarding work, move it to the training plan.

For an existing product, attach a sanitized architecture sketch and a sample issue. For a new product, describe the intended user and the first task they should complete. Give candidates enough context to make choices you can assess.

Turn the first deliverable into acceptance criteria

Suppose the role will own a voice flow that checks an order's status. Write down what a completed task means before choosing interview questions. The example below is a proposed exercise, not a platform requirement.

The user asks for an order update. The mock service returns a status, asks for more information, or fails. Ask the candidate to describe what the user hears in each case. Have them identify any assumptions about who can access the order.

Define the boundary too. The exercise might cover the dialogue and service call while excluding account setup and deployment. A candidate should know which work to complete and which work to explain.

Use those same boundaries when judging submissions. Do not reward extra scope while penalizing someone who followed the instructions. If a candidate spots a risk outside the task, record their reasoning without demanding an unpaid extension.

Use one scoring scale

The following scale is a proposed hiring tool, not a market benchmark:

• 1: Cannot complete the task or explain a workable approach.
• 2: Completes part of the task with substantial guidance.
• 3: Completes the agreed task independently and explains the choices.
• 4: Completes it independently and identifies relevant failure cases or tradeoffs.

Leave an untested criterion blank. A blank tells the panel to gather evidence; a low score says the evidence showed a gap.

Choose required criteria before reviewing resumes. Record the score, evidence, interviewer, and open question in each row. "Strong engineer" is too vague to guide a hiring decision. "Explained how to recover from a failed service call and added a test" gives the panel something to examine.

For each required skill, set the minimum acceptable score. Keep schedule and budget as separate pass conditions. Avoid a weighted total unless the panel can explain why one criterion should count more than another.

What does the data say about budget and nearshore overlap?

The US median annual wage for software developers was $135,980 in May 2025, according to the BLS Occupational Outlook Handbook. That is an occupation-wide US wage figure. It is not an Alexa specialty rate or a Latin American quote.

Use it as a domestic comparison point when finance asks what you are comparing. For the actual hiring decision, request quotes against the same completed scorecard.

A quote for a developer who needs daily technical direction does not price the same role as someone expected to own releases. Likewise, salary and a monthly service invoice cover different things. Ask each provider to explain the total amount your company would pay and the items included.

Keep a budget worksheet beside the scorecard:

Do not assign a savings percentage before comparing matching scopes. A lower quote may reflect a different schedule, seniority level, or set of responsibilities. Resolve those differences before making the shortlist.

Keep internal review time visible in the hiring plan. Name the person who will answer product questions and review code. If the proposed hire needs more guidance than that person can give, revise the role or the budget before interviewing.

Define overlap by city and working hours

Mexico City is UTC-6 and does not observe daylight saving time. Bogotá is UTC-5 year-round. US Eastern time changes seasonally, so a fixed local schedule can shift relative to your team's calendar. See the IANA North America and South America time-zone rules.

Write the actual requirement, such as "available for the agreed review window in America/New_York." Then ask the candidate to confirm the corresponding local hours across the year.

For a LatAm developer, assess whether those hours support your work. A team doing frequent voice-flow reviews may need a shared discussion window. A team with detailed tickets may need less live time. Choose the schedule from those needs.

Separate routine meetings from support coverage. If the role includes responding to failures outside normal hours, state that expectation and discuss its terms. Do not let "US overlap" become an open-ended promise of availability.

Treat availability as a pass condition outside the technical total. Coding ability cannot resolve a schedule that neither side can sustain.

How do the hiring models change who owns the work?

Keep the candidate scorecard consistent across hiring models. Add a separate checklist for the company arranging the hire.

Use the distinctions below to structure the discussion, then confirm the actual scope in writing.

Ask who will review pull requests and decide whether the work is ready to release. A contract label alone does not answer either question.

If you are buying a project, define acceptance at the deliverable level. Ask who fixes defects after handoff and who owns the repository and deployment accounts. If you are hiring a person, define the work they can own and the support your team will provide.

Use two decision records. The candidate record covers engineering evidence, communication, and availability. The provider record covers commercial scope and the support you are buying.

This prevents a fast shortlist from becoming a substitute for technical review. It also prevents a strong candidate from distracting the buyer from unclear contract terms.

When you hire LatAm developers, name the internal manager before signing. Give that manager time for onboarding and review. If the team cannot provide technical supervision, make independent ownership an explicit requirement and test it.

Opus reports: "The client chooses the finalist and manages day-to-day work." This site is an Opus-owned reference; recommendations are editorial.

Talk to Opus about a role.

What should you ask a provider before reviewing candidates?

Send the completed scorecard with the search request. Ask the provider to return evidence against each required criterion. A resume keyword is a starting point for a question, not a completed assessment.

Ask for evidence of personal ownership

Request a relevant project walkthrough. Ask what the candidate built, what another teammate handled, and what happened after release.

Useful questions include:

• Which part of the voice flow did you design or change?
• What did you do when a request could not be completed?
• Which backend changes were yours?
• What failed during testing, and how did you change the implementation?
• Who approved the release, and what did you monitor afterward?
• What would the next engineer need to maintain your work?

Accept a sanitized example when client work is confidential. You can assess reasoning without asking someone to disclose another company's code or customer data.

Follow up on vague answers. "We built the integration" should lead to a question about the candidate's own decisions and code. Record the answer beside the relevant score.

Ask about an unfinished or unsuccessful piece of work too. What did the candidate know at the time? Which choice would they change now? Judge the explanation against the role's needs, without expecting every past project to have gone well.

Agree on a bounded work sample

Use a small exercise drawn from the role. For example, ask the candidate to design a voice flow that retrieves a status from a mock service. Include an unclear request and a service failure.

Ask for a short implementation, tests, and a written note explaining the remaining work. Keep the exercise separate from production access and live customer data.

Set the time allowance and compensation terms in advance. Tell candidates which tools they may use, including AI assistance. Apply the same rules to everyone.

During the review, change one requirement and ask the candidate to explain the effect. This gives the interviewer evidence of understanding beyond the submitted code.

For example, change the mock response so it contains no usable status. Ask what the user should hear and which test should change. Then ask the candidate to show where that behavior belongs in the submitted work.

If AI tools are allowed, ask how the candidate checked their output. Review whether the candidate can explain the code and correct an error. Keep the judgment tied to observable work.

Do not turn the assessment into unpaid delivery work. A narrow exercise should answer the hiring question without asking for a complete product.

Ask how technical vetting maps to your role

Have the provider explain what its assessment actually tests. Ask whether voice interaction work is reviewed and who judges the backend portion.

Request a sample assessment summary with personal details removed. Look for concrete observations that your engineering manager can use. A pass label without evidence leaves your team to repeat the assessment.

If a candidate needs training, document the gap and the plan. Name the person who will teach it and the work the hire can own meanwhile. Do not accept "quick learner" as the full plan.

Separate platform experience from the ability to learn your codebase. For a role that must take over a live skill immediately, ask for evidence of relevant ownership. For a role with training time, define which tasks require supervision until the manager approves independent work.

Set decision rules before the debrief

Ask interviewers to score independently before discussing candidates. Each reviewer should cite observed behavior and identify any question that remains open.

Use the debrief to resolve those questions. If testing was never assessed, arrange a focused follow-up. Do not infer testing skill from a polished architecture discussion.

Avoid averaging away a failed requirement. A candidate who writes clear code but cannot meet the agreed hours still misses a condition of the role.

When reviewers disagree, compare their evidence before debating the score. One may have assessed a different task or given more help. Record that difference and decide whether a follow-up is needed.

If the panel changes a requirement, update the scorecard and reassess all finalists. Preserve the earlier version so the decision record shows what changed.

Before making an offer, confirm:

• The candidate understands the first deliverable and scope.
• The manager accepts any training commitments.
• The working schedule is agreed in writing.
• The commercial terms match the approved budget.
• The first-day setup has an owner.

Where does Opus fit in this hiring decision?

Consider Opus against the same candidate scorecard and provider checklist. Ask for an Alexa-specific assessment plan before treating general vetting as evidence for this role.

Opus reports: "Every candidate passes an 8-layer vetting process." It also reports: "Every Opus placement completes a 6-module internal AI certification before day one."

Ask which assessment steps address the work in your scorecard. Have your technical reviewer examine the candidate's voice-flow decisions and backend work before approving the hire.

Confirm the price and responsibilities

Opus states: "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."

Opus reports: "Every Opus placement works with US timezone overlap." Put your required hours in the search request and confirm the calendar before accepting a candidate.

Ask for a proposed search schedule that leaves room for your technical review. Assign someone to return interview feedback and resolve open questions. Agree on the expected start date separately from the hiring decision.

Review replacement terms alongside onboarding

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

Ask how a replacement request would work for your role and how the handoff would be handled. Keep the role scorecard available for any later search. It records the work you need covered and the evidence required for a replacement candidate.

Your team still needs an onboarding plan. Assign access setup, code review, and release approval to named people. Give the hire a first task with a clear acceptance test and arrange a review with the manager.

At that review, compare the work with the scorecard. Record what the hire completed, where help was needed, and what should change in the next assignment. Use those observations to manage the person after the hiring decision.

If progress stalls, check whether the promised access and support were delivered before judging the hire against the original plan. Record changes to scope so both sides know which outcome is now expected.

Send Opus the role definition, required evidence, and working schedule when you request a search. Include the approved budget and the name of the person who will make the final call.

Talk to Opus about a role.

<!-- Not saved to disk because this session has read-only filesystem access. Build and automated readability checks were not run; publishing validation remains pending. -->