Hiring glossary: what companies hire software developers

How to use this glossary for a nearshore or Latin American team

Use these terms while writing a role description, reviewing a proposal, or deciding who will manage new developers. Start with the work your company needs done. Then choose the hiring model that gives your team the right people and clear responsibilities.

A customer portal may need steady development and support after launch. An internal reporting tool may need someone who can understand existing data and work with its users. Describe that work before choosing between a backend developer and a full-stack hire.

The same approach helps with a whole team. Name the person who will set priorities. Decide who will review code and approve releases. If those duties sit with your engineering organization, make that clear in the hiring request.

Opus finds, vets and installs the whole team; the client keeps operational control. This site is an Opus-owned reference; recommendations are editorial. The team works inside the client's process, tools and backlog. The client chooses the finalist and manages day-to-day work.

Read the Opus guide to hiring a nearshore development team.

Turn labels into decisions

For each term in a proposal, ask what it means in practice. "Dedicated" should lead to a discussion about assigned capacity. "Senior" should lead to examples of decisions the developer can own. "Vetted" should lead to assessment evidence.

Write the answers into the role description or agreement. A useful sentence names the person responsible and the work they control. For example: "Our engineering lead assigns work and approves releases." That gives a candidate more context than "join a collaborative team."

Avoid making a title carry the whole job description. If a full-stack developer will spend most of the week fixing backend services, say so. If a senior developer must coach other engineers, include that duty in the interview.

Start with the software your company needs

You do not need to sell software to have a development role. Frame the hiring request around the system and its users. For an internal application, explain which staff use it and what happens when it fails. For a customer product, describe the user task the developer will help improve.

Keep business context close to the technical requirements. "Maintain the application our warehouse staff use to record shipments" explains a job more clearly than a list of programming languages. Add the existing stack after that sentence.

If you are hiring for a game, describe the part of the game the person will build. An interview about gameplay behavior should explore different work from an interview about player accounts. Use the same discipline for web development: distinguish browser interfaces from the services behind them.

Give each reviewer a defined decision

Before sending a role to a provider, ask your engineering owner and budget owner to read it. Engineering should confirm the work and expected level of independence. The budget owner should confirm what capacity the company can fund.

Keep unresolved questions in the hiring request. If production support is still being discussed, ask candidates about it without presenting an agreed schedule. Resolve that point before an offer. A glossary helps people use the same words; your agreement must still describe the actual job.

Which terms should you check before you hire dedicated developers?

Use the definitions to connect hiring language to decisions about people, cost, and daily work. Start with the terms that determine who does what. Then check whether the role and schedule support the work you expect.

Separate team assignment from delivery ownership

A dedicated development team needs someone to direct its work. Under team augmentation, that person sits on your side. Assign an engineering owner before interviews begin so candidates can ask about architecture, review practices, and priorities.

Project outsourcing creates a different discussion about delivery responsibility. Read the proposed obligations closely if a supplier promises an outcome while also asking you to direct every task. Your agreement should make clear who decides what gets built and who accepts the result.

For a team working inside your process, provide access to the same backlog and review tools your existing engineers use. Set a clear route for questions. A new developer should know who can resolve a blocked task without scheduling a meeting with the whole team.

Write down how decisions move when your engineering owner is away. Name a backup reviewer and say which changes require approval. If only one person can approve a release, adding developers will still leave that approval with one person.

Check what dedicated capacity includes

Treat "dedicated" as a point to define in the agreement. Ask whether named developers are assigned to your company and whether they have other client work. Confirm the expected workweek and how planned leave affects availability.

Discuss meetings and support duties as part of that capacity. If you expect developers to attend customer calls, review others' code, or investigate incidents, include those duties in the role. Leave room for them when planning feature work.

Ask how changes to the team will be handled. Your hiring request might begin with a backend role and later need more frontend work. Agree on how to raise that change, who approves it, and whether it changes the rate. Avoid assuming that an existing assignment can cover any new technical need.

Describe the work behind each role

Use frontend, backend, and full-stack as starting points. Add the application and the kind of work the person will do.

A frontend hiring request might focus on a customer checkout flow and its accessibility requirements. A backend request might focus on maintaining an existing service and investigating failed requests. These are assignments you can discuss during an interview.

For a .NET role, identify the framework version and whether the job involves maintenance or migration. Explain which parts of the application the developer can change. If a migration must preserve existing behavior, use an interview discussion that tests how the candidate would check that behavior.

Define seniority through the independence you need. A developer expected to choose an approach and review others' work needs a different assessment from someone completing well-defined tasks. Describe a decision the person will face, then ask how they would approach it.

Ask what technical vetting actually tested

Request evidence that relates to the role. An assessment of general coding skills may answer a different question from a discussion about maintaining your application. Ask which tasks candidates completed and how the assessor judged the work.

Use your interview to examine a realistic problem without requiring access to private systems. You might discuss a simplified failed request or ask the candidate to explain a past design choice. Follow up on what they checked and what they would change.

Give candidates enough context to ask useful questions. Watch whether they clarify uncertain requirements before proposing a solution. When comparing candidates, record the evidence against the same role requirements so a confident presentation does not become the whole assessment.

Agree on working hours by location

Nearshore and remote describe different aspects of the arrangement. Neither term tells you when a developer will be available.

Mexico City stays on UTC-6 without daylight saving time. Bogotá stays on UTC-5 without daylight saving time. US clock changes can therefore alter the difference between those cities and your office. IANA North America time zone data, IANA South America time zone data.

Put the agreed work schedule in writing. Check whether it covers your code review window and regular meetings throughout the year. Discuss urgent support separately so neither side assumes that daytime overlap includes overnight availability.

Choose which activities need people online together. A design discussion may need a shared meeting, while a documented review can happen at different times. State when someone should expect a response to a blocked task. That gives remote developers a usable schedule instead of a vague instruction to be available.

Distinguish the employer from the daily manager

Use separate fields in your proposal review for the employing entity and your internal manager. The employer of record label describes an employment role. It does not, by itself, explain who finds candidates or who directs engineering work.

Ask who signs the employment agreement and who handles questions about pay or leave. Then name the person who sets development priorities. Make sure the developer knows where to take each kind of question.

A recruiting agency agreement also needs clear boundaries. Confirm whether its work ends after the search or includes ongoing services. For a direct hire, identify the team on your side that takes over once the candidate accepts.

Compare the same costs and dates

A monthly rate and a salary describe different amounts. Before comparing proposals, ask what the quoted amount covers. Confirm the currency, billing period, and treatment of leave. Ask how a change in role or hours affects the price.

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 Opus dollar rates: Not published. Ask for a written quote for the roles you need.

Keep the assumptions beside each quote. A proposal for a developer with production support duties should be reviewed against the same duties elsewhere. If equipment or paid tools are needed, ask who supplies them and whether they affect the invoice.

Treat hiring dates with the same care. A candidate accepting an offer does not mean the person starts work that day. Agree on a first working day, then assign someone to prepare access and the first task.

When discussing time to hire, ask what starts and stops the clock. Candidate selection, offer acceptance, and the first day worked are separate events. Use the event your staffing plan depends on when setting internal expectations.

Plan the first assignment and any handover

Before the team starts, choose a small piece of real work with clear acceptance criteria. Name its reviewer and explain how changes reach production. Check access early enough to resolve login or permission problems before they block that assignment.

Write acceptance criteria as behavior someone can check. For a password reset change, that might include what a user sees after an expired link. Include relevant failure cases so the developer does not have to guess how the product should respond.

Give access according to the work assigned. Identify who approves permissions and where the developer should report an access problem. Use your existing security process for accounts and credentials.

Read replacement terms before signing. Ask how to request a replacement and what happens to billing during a transition. Keep project notes and review decisions in shared tools so another developer can understand the work.

Plan the handover around current tasks. Record what is finished, what remains blocked, and who can answer questions. Confirm who removes access when an assignment ends.

End the hiring request with the work to be done, the skills it requires, agreed hours, and your internal manager. Those details let a provider assess the role and let candidates understand the job they are considering.

Read the Opus guide to hiring a nearshore development team.

<!-- File not saved: the workspace is read-only. Page rendering was not checked. -->