Full Stack Interview Guide: Demonstrate API Validation and Failure Handling
Prepare a small API walkthrough with input checks, status handling and a realistic test plan.
What should your full-stack interview demo prove?
Demonstrate an end-to-end flow that you can explain and test. Pick one small feature, such as adding a practice task, and describe the request, validation, response and interface state. A convincing walkthrough includes a failure case as well as a successful screen. Do not describe a mock as a deployed backend.
Define the contract before the interface
For an original practice task service, require a non-empty title and limit it to 80 characters. Explain whether surrounding spaces are removed and what the user sees when input is rejected. Specify the request shape and response shape in your README. State who may create a task and where authorization belongs; a client-side disabled button is not a server-side access check.
Show a small testable validation function
This JavaScript example was checked locally with Node. It demonstrates validation only; it does not start an HTTP server or authenticate a user.
function validateTask(input) {
const title = typeof input?.title === 'string' ? input.title.trim() : '';
if (!title || title.length > 80) return {ok:false,error:'Invalid title'};
return {ok:true,value:{title}};
}
console.log(validateTask({title:' Practise API errors '}));
console.log(validateTask({title:' '}));Expected results are a successful value with title Practise API errors and an invalid-title error. Reuse the same contract in server tests, while treating browser validation as assistance for the user. Explain how you would handle missing JSON fields, oversized requests and unexpected data types.
Walk through an HTTP failure
Describe a POST request and how the client distinguishes validation failure, lack of permission, server failure and network failure. Do not assume every response contains valid JSON. Explain the loading state, error message and preservation of user input. POST is not inherently idempotent; a lost response does not prove that a creation failed. Discuss the contract needed before enabling an automatic retry of a create request.
Make your demonstration credible
Bring a short test table: valid title, blank title, too-long title, malformed body and unauthorized request. Mark which tests were actually executed and which are planned integration tests. If your interface uses a mocked endpoint, say so and show how you would replace it. Keep environment secrets on the server and use synthetic examples for public portfolio data.
Practice and common mistakes
Test an 80-character title and an 81-character title. The first should pass this example and the second should fail. Explain that JavaScript string length counts UTF-16 code units, so a product requiring user-perceived character limits needs a more precise rule. Avoid claiming complete security from one validation helper. Finish your rehearsal by explaining the missing persistence, authentication and integration checks rather than pretending they already exist.
Prepared by AI Leaf Global Learn for classroom learners in Mudichur/Tambaram, Chennai, and online learners across India. Confirm current batch details with the training team. Tamil Nadu, Chennai and Tambaram are audience tags, not additional branch claims.