Back-end developer

A back-end developer designs and maintains the server side of a web application. They turn product needs into working processes, organise data exchanges and provide the responses that interfaces or other services need. Their work is less visible than the screen a customer uses, but it underpins business rules and the reliability of data.

Their remit begins with understanding requirements and specifications. They then develop server components, adapt database access and check that incoming requests produce the expected responses. An API can provide an agreed way for an interface or another service to exchange information. Depending on the product, the developer may also validate inputs, manage permissions, write tests, fix bugs and produce documentation needed for maintenance. These tasks do not mean that one person is responsible for all aspects of the application's security or operations.

The size of the organisation and the complexity of the project affect how work is divided. In a small team, a developer may work on several parts of the product. In a larger organisation, they may focus on one server module. The role should therefore specify the processes to build, the data involved and the technical decisions entrusted to the developer, instead of assuming that a job title has the same scope everywhere.

Back-end, front-end and full-stack developers: who does what?

• A back-end developer handles server processes, data access and responses sent to interfaces or services.
• A front-end developer works on the visible, interactive part of the application. They coordinate with the back-end developer on the data and behaviour required.
• A full-stack developer works on both sides. The title does not remove the need to specify how much interface and server work the role actually involves.

The role described here centres on server-side code. General interface development, analytics pipelines and infrastructure administration become part of the role only if the organisation explicitly adds them.

The first recruitment question is one of responsibility: who can develop the application's processes and data without making changes difficult to test or maintain? A requirement stated simply as “develop the back end” is too broad. The business rules to implement, the responses interfaces need and the data to create or modify give candidates and assessors a more useful scope.

One mistake when defining the role is to ask for deep server-side specialisation and general responsibility for interfaces at the same time, without stating the priority. A full-stack developer may be suitable if both sets of tasks really belong to the role. If the team already has interface developers and mainly needs to develop server components, the requirement is different. The division of work should also make clear who decides on the data model and who supports changes that affect operations.

Security is part of everyday server-side coding decisions. Incoming data needs validation, and access to data must follow the permissions set by the application. Performance also needs attention proportionate to the processes and the product's workload. These topics can be assessed through concrete work without expecting the candidate to guarantee every aspect of security or availability alone.

Fictional example: a team adds a new customer area. The interface is already covered, but data must be stored and returned according to each user's access rights. The hire could then focus on designing server processes, validating requests, testing and documenting those changes. This scenario helps define the role; it does not describe an observed assignment.

The role also extends beyond the first release. Bugs, changing requirements and evolving data call for documented fixes. Describing this maintenance work helps identify a candidate who can explain their choices and work on an existing component, as well as write new code.

• Analyse requirements and specifications concerning server-side processes.
• Implement the application’s business rules in server components.
• Design or adapt the data model needed for the assigned features.
• Create and maintain data access while accounting for permissions and confidentiality.
• Provide the responses or APIs required by interfaces and consuming services.
• Validate incoming data before processing it.
• Test server components and fix identified faults.
• Document changes to make the application easier to maintain.

Several routes can prepare someone for back-end development. Apec mentions computing studies at different levels, while a French professional qualification can be obtained through training or by accumulating recognised skills. These routes indicate possible learning; none is, on its own, a universal requirement for the role. Hiring decisions are better grounded in the work to be assigned.

To assess that learning, ask the candidate to show a server-side project whose workings they can explain. A business process, data access method or API response can provide a basis for discussion. The candidate should be able to describe the original need, design choices, inputs checked and tests performed. A project portfolio or documentation may help distinguish what they actually did from the team's collective work.

Useful training also covers the code lifecycle. Writing a component is one capability; changing it after a bug, explaining the fix and checking its effect is another. Database and security knowledge should be assessed in the context of the data being handled. An exercise related to the application to be maintained will be more revealing than a list of technologies with no defined use.

The experience required depends on the project's complexity and the support available in the team. Describe the responsibilities you want the person to have exercised: completing a supervised task, taking over an existing module or choosing a solution for a more complex process. Years of experience alone specify neither autonomy nor work done. This profile sets no common threshold.

To assess this profile, adapt the following steps to the server processes to be assigned, the data involved and the autonomy expected.

1. Set the criteria for the role

Draw up a short assessment grid before interviews. Separate programming business rules, designing data access, exchanging information through APIs, testing and input security. For each criterion, define what the person will need to do in your application. A team with an established technical framework may expect careful implementation. A design role also calls for justification of trade-offs.

Link each criterion to something observable: an explained component, a data diagram, tests or a documented fix. This avoids mistaking familiarity with a framework's name for the ability to solve the role's actual problem.

2. Examine previous work

Ask the candidate to present a server-side process they developed or changed. Have them explain the need, their own contribution, the path of a request through to the data and the response produced. Ask about a bug they fixed and the tests used to verify the result.

A positive sign is an explanation that connects technical choices to product constraints. A concern arises if the candidate cannot distinguish their contribution from the team's. A project and its documentation can support this discussion; their existence alone does not prove proficiency.

3. Use a case close to the planned work

Present a case limited to one process, API or data access task. Ask the candidate to identify missing information before writing code or sketching a solution. Observe how they define inputs, responses, access rights and useful tests.

Fictional example: a request must return data to an interface, but some users should see only part of the results. Ask the candidate to explain input validation, access control and how they would check the behaviour. Several solutions may be acceptable if the candidate understands their limits.

4. Assess collaboration and autonomy

Ask how they would clarify an ambiguous business rule with a product colleague, then agree a response format with a front-end developer. Check that they can flag an assumption and document a fix. For an autonomous role, also examine how they would decide when to seek a review or further expertise.

Different terminology from the team's is not itself a warning sign. The concern is when the candidate cannot explain who should decide a rule or what their code changes for other components.

5. Cross-check the evidence

With the candidate's prior agreement, ask for specific examples of maintenance, cooperation and responsibilities actually held during professional reference conversations. Compare the answers with the project discussed and the practical case, without treating any one answer as conclusive proof.

If nobody in the company can assess server-side design, involve a competent professional in the technical interview. Give them the role's criteria and ask for a reasoned view of the work presented and the decisions made, then compare that view with the team's needs.