React glossary: what companies hire software developers

How to use this glossary for a nearshore React hire

Start with the work waiting for the hire. A checkout rebuild calls for different evidence from a reporting dashboard or an internal approval tool. Write down the user flow, the current problem, and the result you expect the person to own.

Then use the terms below to make the opening specific. If your React developer must also maintain server code, describe that responsibility before interviews begin. If a back-end engineer will handle those changes, explain how the two people will work together.

Use the same definitions with engineering, finance, and talent teams. Engineering may use "senior" to mean someone who can plan a migration. Finance may hear "monthly rate" and assume every cost is included. Resolve those differences in the hiring request.

For each term you put in the role description, add a sentence about your actual work. For example:

• "Front-end ownership includes our account settings and billing screens."
• "The developer will review pull requests with our engineering lead."
• "The interview includes a discussion of a form and its error states."
• "We will agree on shared working hours before making an offer."

These statements give candidates something concrete to assess. They also help interviewers ask consistent questions and explain their hiring decisions.

Keep a short list of requirements that would change your decision. A skill belongs on that list when the hire will need it for assigned work. Put skills the person can learn with support in a separate section.

Opus is one option to discuss when you have that scope ready. This site is an Opus-owned reference; recommendations are editorial.

Talk to Opus about a React role.

Use these terms to define the role and compare candidates

Choose the title from the work

"Software developer" covers work across software systems. "Web developer" narrows the setting to websites and browser-based applications. "Front-end developer" identifies the part users interact with. Choose the title that describes the work you expect to assign.

For a React hire, explain which screens the person will own and how much work happens outside the browser. An account page might require interface changes alone. A billing change might also require work on the service that supplies account data.

A full-stack title deserves particular care. Name the server-side responsibility, such as changing an endpoint or investigating a failed request. State whether the developer will have a back-end colleague to consult. Avoid using the title to leave ownership open.

Keep React and React Native requirements separate. If the team needs both browser and mobile work, describe each part and assess it during hiring. A candidate should know which codebase they will work in first.

Match the business need to the role

A company does not need to sell software to have a software hiring need. Describe the task the system supports. For a retailer, that might be checkout. For a manufacturer, it might be an internal order screen.

Use those examples to shape the interview. A customer-facing flow can prompt questions about failed requests and browser behavior. An internal approval tool can prompt questions about permissions and what happens when someone edits an old record.

For a game business, separate web work from gameplay work. Account settings and a player portal can belong in a React role. If the opening also includes game engine programming, give that work its own requirements and evaluation.

This also makes the job easier for candidates to assess. Someone should be able to read the opening and explain what they would build, who would use it, and where they would need help.

Turn components and state into interview evidence

A component is a useful starting point for a code discussion. Give the candidate a familiar interface, such as an address form. Ask which parts they would share with other screens and which should stay specific to that form.

Move from code structure to behavior. Ask what happens when a user changes a field, submits the form, or leaves before saving. Those questions let the candidate explain state through actions a user can take.

Add a failed request to the discussion. Should the form keep the entered text? How does the user retry? What should happen if they press submit again while the first request is running? Ask the candidate to explain their choices.

Use the same exercise for each candidate, with the same context and time allowance. Record the reasoning you heard. A score such as "strong React skills" is less useful than a note describing how the candidate handled a failed submission.

Check API integration and TypeScript against your codebase

API integration includes the work around a request as well as the request itself. Ask candidates how they would handle loading, an empty result, and an error. Give them the response shape they would receive from the server.

If your team uses TypeScript, include a small example from that style of work. Ask the candidate to explain the expected data and how they would handle an unexpected response. Keep the task focused on code they might maintain.

Explain the support available. Will a back-end engineer document the endpoint? Can the hire propose changes to the response? Who investigates when the browser and server disagree? Put those responsibilities in the role description.

Avoid adding every tool in the repository as a hiring requirement. Identify which tools the person must use without guidance and which they can learn during onboarding.

Make accessibility and testing part of the task

Define accessibility through behavior that interviewers can observe. Ask the candidate to move through a form with a keyboard. Discuss labels, focus, and how a user learns that an input needs correction.

Keep these expectations in the acceptance criteria for the exercise. Candidates should know whether you expect them to discuss an issue, fix it, or explain how they would check it. Apply the same standard across interviews.

For automated tests, ask which failure the proposed test would catch. A useful discussion might cover a submission that fails or a button that stays disabled after a retry. Have the candidate explain the expected behavior before writing the test.

Also ask what they would check by hand. The goal is to understand how they decide a change is ready for users. Tie the discussion to your review and release process.

Define seniority before reviewing resumes

Seniority describes the judgment and ownership you expect. Write down which decisions the hire must make without waiting for your engineering lead. Perhaps they must plan a change across several screens or investigate a production bug with limited guidance.

Then describe the support they will have. A developer joining an established front-end team faces a different role from the first front-end hire. State who can review architecture decisions and who will help set priorities.

Compare the resume against those responsibilities. Ask for a specific example of similar work. Establish what the candidate decided, what colleagues handled, and how they checked the result.

Use a portfolio for the same purpose. Ask for a walkthrough of a user flow, including a failure case. If the project was shared, identify the candidate's contribution. Accept an anonymized explanation when they cannot share private code.

Set a fair scope for the work sample

A work sample should resemble a bounded piece of the job. Give candidates enough context to make a decision. Explain the user, the expected behavior, and any constraints they should treat as fixed.

State the expected effort before the task begins. Make clear whether you want working code, a review, or a discussion of an approach. Do not score a written proposal as though you had requested a finished application.

Set the policy on documentation and AI tools in advance. Apply it consistently, then ask the candidate to explain the work they submit. Their explanation should connect the code to the behavior you requested.

Leave room for questions. If the prompt has an unclear requirement, observe how the candidate handles it. Give equivalent clarification to other candidates so you can compare their work fairly.

Put nearshore overlap in writing

Nearshore describes relative location. Latin America, or LatAm, describes a region. Neither term tells you when a particular person will attend a code review or respond to a production issue.

Name your team's time zone and the hours when live collaboration is required. Include recurring meetings and any support coverage. Ask candidates to confirm the schedule before the final interview.

Mexico City uses UTC-6 without daylight saving time. Tijuana follows seasonal clock changes, so a country name alone does not settle the schedule. Use the city when checking the IANA North America time zone data.

Bogotá uses UTC-5 without daylight saving time. Buenos Aires and São Paulo use UTC-3 without seasonal clock changes. US clock changes can therefore change the time difference. Check the IANA South America time zone data.

Record the agreed work window in named time zones. Confirm how the team will handle seasonal changes before sending recurring invitations.

Compare hiring arrangements by responsibility

Keep the technical role separate from the hiring arrangement. A React developer still needs someone to assign work, review changes, and decide what ships. Name that person before comparing provider proposals.

For a direct hire, establish who handles employment and onboarding. With an employer of record, ask which party handles each employment task and which duties stay with your team. Do not assume recruiting is included.

For staff augmentation, spell out daily management and code review. For a project contract, define the deliverable and who accepts it. Include a process for changing scope when the team discovers work beyond the original request.

Ask who owns the work product and how access will end when the engagement finishes. Put those terms in the agreement for review. A job title or service label does not answer those questions.

Compare the full cost over the same period

Start with a written breakdown of the quote. Ask what it includes and which costs remain with your company. Keep pay, service fees, and equipment separate until the quote explains how each is handled.

Use the same budget period for each option. Confirm the billing currency, payment schedule, and terms for rate changes. Ask how leave and any additional coverage affect the amount your company pays.

For US context, the median annual wage for software developers was $135,980 in May 2025. This is an occupation-wide wage figure. It does not establish a React-specific rate or your full employer budget.

Keep your own team's time in the plan too. Name who will interview, onboard, and review the hire's work. Confirm that those people have time available before committing to the start date.

Agree on the first working day

Track candidate selection, offer acceptance, contract signing, and the first working day as separate events. Ask what must happen between them. A release plan should use the date the person can begin work.

Prepare repository access and development instructions before that date. Give the hire a named reviewer and an initial task with clear acceptance criteria. Choose work small enough that the reviewer can give useful feedback.

Confirm how the hire will raise a blocker and who can resolve access problems. Set the first review around completed work and questions from the task. Use that discussion to decide what support the next assignment needs.

Bring the role scope, required overlap, and intended start date to the hiring conversation.

Talk to Opus about a React role.

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