Junior Web Developer

Sample Answer

GET is used to retrieve data from a server. The request parameters are included in the URL, which means the data is visible and the request can be bookmarked or cached. POST is used to send data to the server to create or update a resource. The data is in the request body, not the URL, which makes it more appropriate for sensitive data like passwords or form submissions. As a rule: GET for reading, POST for writing.

Sample Answer

A JOIN combines rows from two or more tables based on a related column. I would use it when I need data that lives in more than one table. For example, if I have a users table and an orders table, and I want to list every order alongside the customer's name, I would JOIN on the user_id field. An INNER JOIN returns only rows with matching values in both tables. A LEFT JOIN returns all rows from the left table and matching rows from the right, with NULL for non-matches.

Sample Answer

I would start with browser DevTools, specifically the Network and Performance tabs, to see which resources are taking longest to load. Common culprits are unoptimised images, too many HTTP requests, unminified CSS and JavaScript, or slow database queries. For images, I would compress them and consider lazy loading. For scripts, I would minify and defer non-critical JavaScript. For database performance, I would check whether slow queries are missing indexes. I would then retest using Lighthouse to verify the improvement.

Sample Answer

A cookie is stored on the client side (the browser) and has a configurable expiry time. It is sent with every request to the server for the relevant domain. A session is stored on the server, and only a session ID is stored on the client in a cookie. Sessions are more secure because the actual data never leaves the server. I would use sessions for login authentication and cookies for less sensitive persistent data like user preferences.

Sample Answer

I start by clarifying the requirements and sketching a rough wireframe, even for a small project. Then I plan the data structure and set up a Git repository with a clear commit convention before writing any code. I build the back-end logic first, test the data flow, then work on the front-end. I commit regularly with descriptive messages. Before submitting or deploying, I review my own code once as if I am a reviewer seeing it for the first time. I find I catch at least two things every time.