Front-end developer

A front-end developer builds the part of a website or web application that people use in a browser. They turn designs and functional requirements into interactive pages and components. Their work lets people view content, navigate and complete tasks on different screens. Some job adverts use the title “frontend developer” for the same field.

They structure content with HTML, style it with CSS and programme interactions with JavaScript. Depending on the project, they connect the interface to data provided by application services: a request might, for example, update part of a page without reloading it. This connection to the server does not make them responsible for server-side processing, data flows or infrastructure overall.

Their remit also covers how the interface behaves on the target screens and browsers, its accessibility, testing and fixing faults. They work with the people who define the product, design the experience and build server-side services. The exact division of work depends on the organisation: some teams give the role more visual implementation work, while others assign more interface logic. The reporting line and remit should therefore be specified in the job advert rather than inferred from the title.

Front-end developer, web integrator and full-stack developer: who does what?

• Front-end developer: builds the interface's behaviour and appearance in the browser, then connects it to the services it needs.
• Web integrator: focuses mainly on building pages from designs and adapting them to different devices. The two titles can overlap between companies.
• Full-stack developer: works on both the interface and server-side development. This broader remit must reflect the work actually assigned.

Depending on the team, visual design may be the responsibility of a UX/UI designer. The front-end developer discusses feasibility and interactive states with them, without automatically taking responsibility for the design.

Hiring a front-end developer means asking someone to turn a requirement into an experience people can use in a browser. An interface can look faithful to a design while being hard to navigate with a keyboard, unreliable on some screens or unable to display received data correctly. The hiring decision should therefore consider expected use and how quality will be checked, beyond visual appearance alone.

The first challenge is defining what the role covers. A team with a designer and server-side developers may need an interface specialist who can implement components and discuss their states. If those responsibilities are not covered elsewhere, the role may need a broader remit. The title alone cannot settle this: the job brief should name the deliverables, the people the candidate will work with and the decisions they will be entrusted with.

Hypothetical example: a company wants to make a form usable on a phone. It could ask the front-end developer to adapt the layout, programme the interactions and check keyboard navigation. It must specify who defines the user journey, who produces the data returned by the server and who approves the expected behaviour. This illustrates one possible division of work, not a required structure.

Quality has several dimensions. Functional tests cover interactions, forms, navigation and links, among other things. Testing on the target devices and browsers reveals other faults. Automated accessibility checks help, but do not replace examining how people use the interface, particularly with a keyboard. How responsive the interface feels also matters, without attributing every factor in a service's performance to the front end alone.

One common mistake is to require a particular framework without establishing the fundamentals the role needs. Another is to call a role “front-end” when it combines server-side development, visual design and team management. The right level of autonomy depends on the project's complexity, the other skills available and the decisions the person will need to make independently.

• Turn designs and functional requirements into pages and components that people can use in a browser.
• Structure content in HTML and define its presentation in CSS.
• Programme interface interactions with JavaScript.
• Connect components to data supplied by application services where the project calls for it.
• Adapt the layout and interactions to the target screens and browsers.
• Account for accessibility, particularly keyboard use, in the components they build.
• Test user journeys, forms, links and interactive states within their remit.
• Diagnose interface faults and document the fixes made.
• Work with product, design, testing and server-side teams on expected behaviour.

Routes into front-end development vary. Self-study, courses and intensive training can be combined. Computing qualifications, such as a French BTS, BUT or licence, can also provide useful foundations. A certification course may distinguish learning to build interfaces from learning server-side development. None of these routes is a universal requirement for the role.

When assessing an applicant, start with the skills your project needs. The person should be able to explain how they structure a page in HTML, style it with CSS and programme interactions in JavaScript. A piece of work can show how they adapt an interface to target screens, use data from a service and address an accessibility problem. If the project was collaborative, also ask what they personally designed, built, tested or fixed.

Relevant experience is best described through responsibilities. Did they work from a detailed design or have to clarify missing states with the designer? Did they integrate an API supplied by another team? Did they diagnose faults seen in a browser or when using a keyboard? These details say more about their autonomy than a number of years alone. In its general developer profile, Apec also notes that the experience required varies with the project's complexity.

A strong formal education does not guarantee practical command of interface work. Equally, a less conventional route can be compelling if the candidate explains their choices, tests and the limits of their work. Link the skills you observe to the tasks you will actually assign, then decide what technical support will be available when the person starts.

GetPro's general assessment method starts with a prioritised set of criteria, then seeks concrete examples in interviews and, if references are taken, from the people consulted. The criteria and exercises below are suggestions to adapt to the front-end developer role, the interfaces involved and the expertise available in your team. They do not describe a GetPro method specific to this profession.

1. Set the criteria before interviewing

Describe a real interface within the remit: its users, target screens and browsers, data received from the server and interactions to build. Separate essential capabilities from tools the person can learn. The scorecard used in GetPro's general method distinguishes criteria that can be checked against a candidate's background from those requiring an interview or test; each criterion has a way of being assessed. For this role, you could use a shared scorecard covering semantic HTML, CSS, JavaScript, adaptation to different screens, accessibility, testing and collaboration. For each criterion, say what an answer or piece of work should demonstrate. Specify who designs the mock-ups and who develops the APIs, so you assess the person against their future responsibilities.

A positive sign is the ability to connect a technical choice to a specific use. A warning sign is an answer that assumes every interface problem can be solved by choosing a framework, without examining the expected behaviour.

2. Examine a past piece of work

In interviews, GetPro's general method uses open questions and asks for concrete examples for key criteria. To assess front-end work, ask the candidate to present an interface they know well. Clarify their personal contribution: components built, interactions coded, adaptation to devices, bugs fixed and discussions with other contributors. Ask which decision changed following a test or feedback from users. A project file and its presentation are also used in a web developer training framework; this offers an example of what can be observed, not a compulsory recruitment procedure.

A collaborative project is still useful if the person clearly distinguishes their work from the designer's or server-side team's. If they struggle to explain those boundaries, ask follow-up questions rather than drawing an immediate conclusion.

3. Set an exercise close to the role

Choose a task short enough to discuss: describe or build a form that adapts to the target screens and connects to an API response. Ask how the person would structure the page, handle interactive states and check errors. Assess their approach and trade-offs, as well as the finished appearance. Ask them to explain how they would test navigation, links and the form in the planned environments.

Hypothetical example: for a form with an error message, ask the candidate to show how they would make the message understandable and how they would check the journey using a keyboard. Automated checks can help detect some accessibility problems, but are not enough on their own.

4. Observe collaboration and communication

Present a design with a missing state or an ambiguous API response. Ask whom the person would consult and what they would propose while awaiting a decision. Look for a clear explanation of their assumptions and the limitations of their solution. An answer that assigns every decision to the front-end developer without discussion may indicate that the role has been poorly defined.

5. Cross-check relevant evidence

GetPro's general method includes contextual questions and concrete examples when taking references. If you take professional references for this role, keep questions to the stated responsibilities: autonomy over an interface, quality of fixes and collaboration with other professions. Compare the answers with the examples and practical exercise. If nobody in the company can assess the code or accessibility, involve a competent technical assessor in the exercise and its review. Give them the same scorecard so their opinion addresses the role you have defined.