Developer interview questions and answers

First the browser checks its cache, then resolves the domain to an IP address through DNS. It opens a TCP connection, and for HTTPS it does a TLS handshake to agree on encryption. Then it sends an HTTP GET request with headers and cookies. The server, say Nginx in front of a Node or Laravel app, runs the route and returns HTML with a status code like 200. The browser parses the HTML into the DOM, fetches CSS, JavaScript and images, builds the render tree, lays out the page and paints it. Scripts can then call APIs and update the page.

var is function-scoped and hoisted, so it is available as undefined before the line where it is declared. let and const are block-scoped, and touching them before declaration throws an error because of the temporal dead zone. let can be reassigned, const cannot. But const does not freeze objects, so I can still push into a const array. The practical bug I have seen is a for loop with var and a setTimeout inside: every callback prints the final value. Switching to let gives each iteration its own binding. In my projects I use const by default and let only when a value changes.

I would model tasks as a resource. GET /api/tasks lists the logged-in user’s tasks with pagination, GET /api/tasks/{id} returns one, POST /api/tasks creates one and returns 201 with the new task, PATCH /api/tasks/{id} updates fields like title or done, and DELETE returns 204. Validation errors return 422 with field messages, a missing task returns 404, and a task owned by someone else returns 403. Every route sits behind token auth. I would add filters like ?done=false, version the API under /v1, and keep responses in one consistent JSON shape so the frontend can handle errors in one place.

I start with evidence, not guesses. I check the error tracker and server logs for the exact stack trace and time. Then I list what differs between local and production: environment variables, PHP or Node version, database data, caching, file permissions and third-party keys. Last year an image upload failed only in production because the server had a 2 MB upload limit in php.ini while my local limit was higher. If logs are not enough, I reproduce on staging with a copy of production config. Once fixed, I add a log line or test so the same failure is caught earlier next time.

CORS is the browser’s rule for letting a page on one origin call an API on another origin. Origin means scheme, domain and port together, so localhost:3000 calling localhost:8000 is cross-origin. The browser sends the request, or first a preflight OPTIONS request for things like JSON bodies or custom headers, and only lets the page read the response if the server replies with the right Access-Control-Allow-Origin header. So the fix belongs on the API server: allow the specific frontend origins, methods and headers, and allow credentials only if cookies are needed. I avoid a wildcard origin on authenticated APIs.

I would measure first with Lighthouse and the browser Network tab to see if the delay is server time, large files or blocking scripts. If the first byte is slow, I look at the backend: slow queries, missing indexes, N+1 queries, and whether results can be cached. On the frontend, I compress and resize images, serve WebP, lazy-load images below the fold, split JavaScript bundles so each page loads only what it needs, and defer non-critical scripts. On one e-commerce project, adding an index on the orders table and converting product images to WebP took the listing page from about five seconds to under two.

I pick SQL, like MySQL or PostgreSQL, when data has clear relationships and I need joins, transactions and strong consistency, for example orders, payments and users. Foreign keys and constraints protect the data. I pick a document store like MongoDB when records vary in shape and are read as a whole, such as product catalogues with different attributes per category, or activity logs. A key-value store like Redis fits sessions, caching and counters. In most web apps I start with PostgreSQL because it also handles JSON columns well, and I add Redis for caching only when I can show a need.

For a normal server-rendered or same-domain app I prefer sessions. The server stores the session, the browser gets an HttpOnly, Secure cookie, and logout or revoking access is immediate. I add CSRF tokens for forms. JWTs suit mobile apps or separate APIs where the server should stay stateless, but they are hard to revoke, so I keep access tokens short-lived, around 15 minutes, with a refresh token stored securely and rotated on use. I never put JWTs in localStorage for a sensitive app because any XSS can read them. Passwords are hashed with bcrypt or Argon2, never encrypted.

JavaScript runs on one main thread with a call stack. Slow work like network calls or timers is handed to the browser or Node, and when it finishes, a callback is queued. The event loop moves queued work onto the stack only when the stack is empty. Promise callbacks go in the microtask queue, which runs before timers in the macrotask queue, so a resolved promise logs before setTimeout with zero delay. async/await is cleaner syntax over promises: await pauses that function, not the whole thread. A heavy loop still blocks everything, so for large calculations I would use a Web Worker.

SQL injection happens when user input is joined into a query string. I prevent it by always using parameterised queries or the ORM’s query builder, like Eloquent or Prisma, and never building SQL with string concatenation. For XSS, the risk is user input rendered as HTML or script. I rely on the template engine’s automatic escaping, avoid innerHTML and raw output unless the content is sanitised with a library, and set a Content Security Policy header. I also validate input on the server, not only in the browser, and give the database user only the permissions the app needs.

I pull the latest main branch and create a feature branch named after the ticket, like feature/cart-coupon. I make small commits with clear messages, push the branch and open a pull request with a short description and screenshots if the UI changed. After review comments, I push fixes to the same branch. If there is a merge conflict, I pull main into my branch, open the conflicting files, keep the correct lines from both sides, run the app and tests, then commit. In my final-year project with three teammates, this workflow stopped us overwriting each other’s code.

On a food-ordering app, some users were charged twice about once a week. It never happened in testing. I added logging around the payment callback and found the gateway sometimes sent the same success webhook twice within a second. Both requests passed our check for an unpaid order because neither had saved yet. I fixed it by making the webhook handler idempotent: a unique constraint on the gateway payment ID and a database transaction with a row lock on the order. Double charges stopped. Since then I assume any external callback can arrive twice and design for it.

During my internship at a small agency, the client project was in Vue, and I had only used React. I had eight days before my first task. I did the official Vue tutorial on the first two days, then read our existing components to learn how the team structured things. I rebuilt one small screen in a sandbox and asked my mentor to review it. By the second week I shipped a filter panel for the product list. The lesson I took is to learn from the team’s real code, not only from tutorials.

I once deployed a database migration that renamed a column, and the old app servers were still running during the deploy, so checkout failed for around ten minutes. I noticed the error spike, told the team lead in the channel right away, and rolled back the release. Then I wrote the change in two steps: first add the new column and write to both, deploy, then remove the old one in a later release. I also added a checklist item for backward-compatible migrations to our pull request template. No one on the team has repeated that mistake since.

Our product manager wanted infinite scroll on the order history page. I felt it would hurt users who needed to find an old order and would make the page footer unreachable. Rather than argue, I built a quick prototype of both options and we checked support tickets, which showed people mostly searched for specific orders. We agreed on paginated results with a search box and a date filter. The PM presented it to the business as her decision, which was fine with me. I learned that a working demo settles arguments faster than opinions.

I estimated three days to integrate a new SMS provider, but their API documentation was out of date and callbacks behaved differently from what was written. By day two I knew I would not finish, so I told my lead the same afternoon instead of on the deadline. We moved the SMS feature to the next release and shipped the rest on time. I raised a support ticket with the provider and finished in five days. Now, for any third-party integration, I spend the first half day building a small proof of concept before I give an estimate.

A school owner asked why his website went down whenever results were announced. Instead of talking about servers and CPU, I compared the shared hosting plan to a small shop with one counter: fine on normal days, but on results day three thousand parents arrive at once. I showed him two options with monthly costs: move to a slightly bigger server, or publish results as a static page through a CDN. He chose the CDN option because it was cheaper. On the next results day the site stayed up, and he now calls me before any big announcement.

I have looked at openings for full-stack developers with about three years of React and Node experience in Pune, and similar roles are offering roughly 12 to 15 lakh per annum. My current CTC is 9.5 lakh. Given that this role adds cloud deployment and on-call responsibility, I am looking for something in the range of 13 to 14 lakh fixed. I am open to discussing the split between fixed pay and variable, and I would also like to understand the learning budget and the review cycle before I decide.

My notice period is 60 days as per my contract. I have already discussed a handover plan with my manager: I am finishing a payment module release in the first three weeks, and after that I can document my work and hand over to a teammate. Based on that, I could ask for an early release after about 45 days, but I would not promise it until my manager agrees. If you need someone sooner, I am happy to do a short onboarding call or read your codebase docs before I join.

I have used your billing app for my freelance invoices, so I know the product from the user side. I read your engineering posts about moving the invoice screens to React and adding offline support for small shop owners with weak internet. That is the kind of problem I want to work on: real users, real constraints, not only internal dashboards. My current work is mostly maintaining an old admin panel, and I want to build customer-facing features at scale. Your stack of React, Node and PostgreSQL also matches what I have used for the last two years.