Link interface, processing and storage in a full feature.
These sheets describe activities and teaching exercises. They do not constitute job offers, certifying courses or recruitment promises.
All job descriptions
Connect interface, server logic and data within a defined scope. Full-stack work supports end-to-end understanding without implying mastery of every speciality.
Keep scope explicit. Advanced security, accessibility, infrastructure or analysis may require additional expertise and independent review.
Deliver a complete feature with failure tests, startup instructions and documented limits.
This is an editorial description of common activities. Job titles and scope vary across teams; it is not a certification framework.
W3C: organising accessibility responsibilities across a team
Deliver a registration course with validation, confirmation and searchable status.
Work on a copy or demo environment. Define the data used and the expected result before you begin. Keep your decisions and the difficulties encountered in order to be able to explain the process.
End-to-end functionality, testing and deployment instructions.
The visible state, processing result and recorded data remain consistent.
For each check, note the context, the action, the expected result and what has been observed. Distinguish a successful verification from a remaining hypothesis. Another person must be able to understand the deliverable without attending all its manufacture.
Use the Functional Validation BookWorking on several layers does not dispense with distinguishing their responsibilities. A success displayed should not precede an operation that has failed.
Collaboration to explore: Back-end development.
Specify the sharing of responsibilities: who provides the information, who decides, who checks and maintains the result. A good handover retains the constraints and decisions, not just the final file.
Employment, trades and trainingAssess full-stack work through continuity between interface, request, storage and response. A feature does not succeed merely because the browser displays a positive message.
| Skill | Evidence to examine | Failure to spot |
|---|---|---|
| Contract | Fields, identifiers and states match between client and server. | The client accepts a value that the server interprets differently. |
| Transaction | An action produces an identifiable result and consistent confirmation. | An unintended repeat creates multiple records without control. |
| Diagnosis | A failure can be located without exposing sensitive data. | The report confuses a sent request with a saved record. |
Download the editable CSV checklist
The file contains this table and blank columns for the observed result, owner and follow-up. It opens in a spreadsheet; downloading it does not send your observations to the site.
Follow a submission end to end, then interrupt the return after saving in a test environment. Determine how visitors recover the state and how the team distinguishes a new request from a repeat.
In-depth exercise: Build a small library of files with research and proposal form. Follow an entry from its input to its display, using demonstration data. Set identifier, validation, storage, publishing status, and rendering. Test a rejected entry and a modified entry. An interface displaying "Received" should not suggest that the information is already published or verified. Also check the route during a network error.
These criteria are a working basis to adapt to the context. For each, note the action taken, the expected result, the observed result and the information remaining to be confirmed.
Explain where the data is validated, stored and transformed. Keep a reproducible scenario that runs through the interface and the server. Document the responsibilities of each layer as well as the limits of the demonstration environment. The handover must make it possible to follow a problem from a visible message to its technical cause without exposing private content or access parameters.
A complete exercise connects interface, data and processing. Choose a scope small enough to verify the entire workflow rather than multiplying unfinished features.
A screen and database do not prove that a workflow works. Handle permission changes, interruptions and incomplete data too.
Present a short diagram and a reproducible demonstration. Follow a request from browser to result, then explain failure behaviour.
It allows you to show an approach and its limits. It is neither a diploma, nor a certification, nor proof of a production experience.
Specify that this is an exercise, your role, constraints, decisions and checks. Use test data and media whose rights are established.
The visible state, processing result and recorded data remain consistent. Add the difficulties encountered and what remains to be verified rather than presenting absolute validation.
Choose a verifiable main task and representative states. Complete validation, error handling and permissions before adding features. A limited, explainable workflow makes decisions easier to assess than partially implemented functionality.
