ReactJS Agency Technical Assessment: Beyond the Portfolio

Assess the Engineers Behind the Portfolio

A portfolio can show what an agency helped build. A technical working session helps you understand how the proposed engineers would approach your product. Use this guide after shortlisting suppliers and before committing to a substantial delivery phase.

For commercial terms, team continuity and the overall selection scorecard, start with our ReactJS agency selection guide . This assessment focuses on engineering evidence rather than repeating the entire buying process.

Prepare One Representative User Journey

Choose a feature that resembles your actual work: a role-based dashboard, a multi-step form, a subscription change or an operation that updates an external system. Provide a short description, relevant constraints and the expected user outcome. Keep confidential data and credentials out of the exercise.

Invite the engineers expected to deliver the project. Ask the agency to bring a code sample it is permitted to share, or agree a small paid discovery task using your own repository. A sales presentation from a different team provides limited evidence about who will build your product.

• State the purpose: evaluate reasoning, collaboration and delivery approach.

• Share the scenario in advance so the session tests judgment rather than recall under pressure.

• Name the constraints: existing APIs, supported devices, permissions and the first release boundary.

• Ask for explanations and evidence; avoid requiring unpaid implementation work.

An Example 60-Minute Assessment

• First 10 minutes: clarify the user journey, constraints and unanswered questions.

• Next 20 minutes: walk through a comparable feature and its main technical decisions.

• Next 15 minutes: introduce a failure or change to the scenario.

• Next 10 minutes: discuss testing, release and recovery.

• Final 5 minutes: agree what remains uncertain and what evidence would resolve it.

Adjust the agenda to the size of the engagement. An existing product with unfamiliar architecture may justify a separate React code audit before anyone commits to a delivery plan.

Follow the Data Through the Feature

Ask an engineer to trace a user action from input through validation, the API, stored data and the UI update. Have them explain where state lives and what happens while a request is pending. They should be able to connect each choice to the product's behavior.

• Which data comes from the server, and which state exists only in the interface?

• What happens if the user submits twice or navigates away while a request is pending?

• How does the interface recover from a failed save without falsely reporting success?

• Where are permissions enforced, and how would a forbidden request be tested?

Listen for limits and tradeoffs. There may be more than one reasonable architecture. A strong answer explains why one fits your constraints and what would make the team reconsider it.

Introduce a Failure or Scope Change

Change one condition: the API is slow, a response is out of date, a user's role changes, or a dependency becomes unavailable. Ask the team to reason through the effect on the user, the data and the release plan.

This makes generic answers harder. The useful evidence is how engineers ask questions, identify assumptions and narrow the problem. Do not score confidence or presentation polish as a substitute for explaining the behavior.

Ask for a Performance Investigation

Describe a slow interaction in the selected journey. Ask what the engineers would measure before changing code, how they would reproduce the issue and how they would compare the result.

Look for a distinction between network delays, unnecessary work, large assets and rendering costs. Naming a framework or proposing memoization everywhere is not an investigation. Ask which user-visible improvement would make the work successful.

Review Testing and Accessibility with a Concrete Example

Ask the agency to show a test of an important behavior, explain what it catches and identify what it does not cover. Discuss how the team tests integrations, error states and the critical journey after deployment.

For accessibility, ask for a keyboard walkthrough and examples of manual checks alongside automated tooling. Agree the acceptance target and the people responsible for reviewing it. A list of testing libraries alone does not show how the application will be assessed.

Walk Through a Release and a Failed Release

Choose a small change and ask how it reaches production: review, automated checks, environment configuration, deployment and observation. Then ask what happens if the release causes errors.

• Who decides whether a release is ready?

• How does the team notice a broken customer journey?

• What can be rolled back, and what needs a separate recovery step?

• Who responds after launch, and where are those responsibilities recorded?

Include data or API changes when they are part of your scope. Reverting frontend code may not undo a database migration or an external action.

Record Evidence and Open Questions

After the session, record each conclusion as a claim, the evidence you saw and what remains uncertain. Separate a missing capability from something that was simply not covered in the meeting.

• Demonstrated: the proposed engineer explained and showed the behavior.

• Plausible but unverified: the approach makes sense, but you still need an example or reference.

• Unresolved: a material question has no owner, assumption or next step.

Use the results in the main agency selection scorecard . If the remaining uncertainty could materially change price or delivery, agree a bounded investigation before signing off the wider plan.

Discuss Your React Codebase

Our ReactJS development service covers building and improving React products. For an existing system that needs incremental change, see software modernization . Talk to a Maker about the work you need assessed .