Hiring glossary: what companies hire software engineers?

How to use this glossary for nearshore ML hiring

Start with the work your team needs someone to own. "Build a model" leaves room for very different jobs. One team may need an experiment to test whether its data can support a prediction. Another may already have a model and need an engineer to keep it running.

Write that distinction into the role before choosing a title. Name the system and the decision the hire can make without approval. If the work includes support when a service fails, say so. A candidate should be able to picture a normal week from the job description.

For example, a demand-forecasting project might need a data engineer to prepare reliable inputs and an ML engineer to build the prediction service. If you want one person to cover both, describe both responsibilities. Decide which skills they need on arrival and which they can learn with help from your team.

Use the glossary during intake with the hiring manager. Ask each interviewer to describe the role's main task in plain words. If one expects research and another expects production support, settle that difference before reviewing candidates. Otherwise, the same interview answer may earn opposite scores.

The employer's industry gives you context, but the work determines the search. A retailer building a forecast and a software business building a recommendation tool might assess some of the same ML skills. Their data, users, and release risks will still differ. Put those differences into the interview exercise.

When comparing employers competing for candidates, distinguish headcount from open roles. A company can have a large engineering team without hiring for your specialty. Look at the responsibilities in comparable openings, including required work hours and access to physical equipment. Avoid building your own role around a competitor's title alone.

Use the same care when discussing a hiring arrangement. Opus charges one flat monthly rate per hire. This site is an Opus-owned reference; recommendations are editorial. The rate 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 dollar rates: Not published. Ask for a written quote for your role. The client chooses the finalist and manages day-to-day work. Name the manager who will review the engineer's work before starting the search.

Bring that scope and your required working schedule to the discussion. Talk to Opus about a role.

Which terms belong in your job description and hiring agreement?

Use the definitions to resolve decisions, rather than adding more labels to an opening. The role terms describe what the person owns. The technical terms describe evidence you can ask for in an interview. The hiring terms describe who employs, pays, and directs the person.

Keep these distinctions in the documents candidates and budget owners will read. A hiring manager should not have to infer production duties from the word "senior." A finance lead should not have to infer the cost of benefits from a salary figure.

Choose between a software engineer and an ML engineer

A software engineer builds and maintains software. An ML engineer's work includes systems that use learned models. For your opening, explain how much of the job concerns model behavior and how much concerns the surrounding application.

Suppose the team needs to connect an existing prediction service to a product. Ask whether the hire must change the model or mainly handle requests, failures, and application code. If model development is part of the job, include evidence of that work in the assessment.

Avoid listing every tool the team might use. Separate the tools needed for the first assignment from those the engineer could learn later. This gives interviewers a reason to accept relevant experience with a different stack.

Separate data science, data engineering, and MLOps duties

Data science focuses on questions and models. Data engineering focuses on making data usable and dependable. MLOps concerns the release and upkeep of ML systems. These duties can share an owner, but the job description should say where that ownership begins and ends.

For a forecasting role, ask who fixes a delayed input feed. Then ask who decides whether a forecast is good enough to release. Those decisions may require different skills and different access.

If your team already has a data platform owner, describe that support. If the new hire must build the data pipeline as well, include it in the scope. Do not assess candidates as model specialists and then assign them an unmentioned infrastructure project.

Define training, inference, and evaluation through the work

Training fits a model to data. Inference uses that model on new inputs. Evaluation checks whether the output meets the task's needs. Use each term to explain an actual responsibility.

For a training role, ask candidates how they chose the data and compared experiments. For an inference role, discuss response time and what the application should do when the model service fails. For evaluation, ask which errors would block a release.

Give the candidate enough business context to make a judgment. A forecast that informs a weekly plan has different operating needs from a prediction shown during a live transaction. Tell them when the output is needed and who acts on it.

Keep the exercise small enough to discuss. Ask the candidate to explain a choice, then change one condition and hear how their approach changes.

Test for data leakage and model drift

Data leakage can make an evaluation look better than the system will perform in use. Ask candidates what information was available at the moment a prediction would have been made. Have them explain how that timing affects the training and test data.

For example, a historical dataset might contain a field added after the outcome occurred. Ask whether that field belongs in a model meant to predict the outcome earlier. This tests the candidate's reasoning without requiring a long take-home project.

Model drift concerns changes after release. Define who checks results and who can pause use of a model. Ask candidates what they would investigate if performance fell. Include the business owner in that discussion when judging errors requires domain knowledge.

Distinguish ML work from robotics and hardware work

Computer engineering, robotics, and mechatronics can include software duties, but the titles do not specify the same job. A robotics opening might concern perception, control software, or a physical subsystem. Name the part your hire will own.

For a nearshore role, confirm how the person will test changes. Will they use a simulator, remote access to a device, or equipment shipped to their location? Identify any work that requires a lab visit before presenting the role as fully remote.

The same question applies to computer hardware work. A candidate's ability to write code does not settle whether they can test the system from home. Explain the equipment, access approvals, and local support available.

Agree on the hours people will actually work

Nearshore describes location; your schedule describes when colleagues can reach each other. LatAm is a region, not a single time zone. Put required meeting hours in the job description and confirm them with each candidate.

Mexico City is UTC-6 and does not observe daylight saving time. Tijuana follows US daylight saving dates. A Mexico-wide assumption can therefore produce the wrong meeting schedule. Use the candidate's city when checking the calendar. IANA time zone data.

Bogotá is UTC-5 without daylight saving time. Buenos Aires and São Paulo are UTC-3 without daylight saving time. Check the candidate's working hours against the US team's schedule in both seasons. IANA time zone data.

Also separate shared working hours from on-call coverage. If the engineer must respond outside the normal schedule, discuss that duty before the offer. Record who covers absences so a shared time zone does not become an assumption of constant availability.

Identify who employs the person and who directs the work

Direct hire, an employer of record, and a recruiting agency describe different parts of hiring. Ask which entity signs the employment agreement. Then confirm who finds candidates and who handles payroll.

Staff augmentation describes adding people to a team the client directs. A managed service puts responsibility for an agreed service or result with a provider. Read the proposed duties before deciding which label fits.

For an ML opening, name the person who sets priorities and approves model releases. Also decide who handles performance concerns. A commercial agreement can assign payroll duties without answering either of those questions.

Ask for these responsibilities in writing. Keep them with the role scope so the engineering manager and purchasing team are comparing the same arrangement.

Compare fully loaded cost on the same basis

A salary figure and a monthly service quote may cover different expenses. List what each quote includes before comparing the totals. Separate recurring charges from costs triggered by a start, a change, or an exit.

Ask about equipment and paid leave. Confirm the invoice currency and how exchange-rate changes affect the amount due. For an ML role, decide where compute costs belong. A cloud training bill may sit in the engineering budget even when employment costs sit elsewhere.

Check what happens if the scope changes. Adding production support or changing working hours may require a new agreement with the hire. Record who approves those changes and how the revised cost will be confirmed.

Keep salary benchmarks separate from quotes. A benchmark describes a group under stated conditions; a quote prices a particular role and arrangement.

Separate time to hire from the first working day

Time to hire needs defined start and end events. Ask whether a reported interval begins when the role is approved or when a candidate enters the process. Confirm whether it ends at offer acceptance.

The start date is a separate milestone. Equipment delivery and access approvals need their own owners. Check whether the engineer can use the required data and development tools before promising a first assignment.

Prepare a task that fits the access available on arrival. If production permissions take longer, give the hire a useful task in a safe environment. Name a teammate who can answer questions and review the result.

Read replacement terms before you need them

A replacement guarantee describes a contractual promise. Ask what triggers a search and which costs it covers. Confirm the steps your manager must take and who keeps the work moving while candidates are assessed.

Do not assume the word "replacement" answers questions about refunds, notice, or project delivery. Ask for each answer separately and keep it with the agreement.

Before signing, compare the role scope with the interview scorecard and the working schedule. Resolve any mismatch while both sides can still change the plan. The resulting offer should describe the job the engineer will actually do.

Talk to Opus about a machine learning engineer role.

<!-- Not saved to disk because filesystem access is read-only. Page rendering was not checked. -->