At Hatchways, we noticed companies ask a lot of knowledge-based questions in phone screens and onsite interviews. This is especially the case for web developer roles, where you are expected to know so many different topics from interacting with the DOM to caching a SQL database.
Despite the overwhelming number of possible trivia questions, we have noticed a few popular topics. The questions in this guide below is a great starting point to practice for knowledge-based interviews. With enough practice, these interviews will become a breeze.
Q1: What happens when you go to a website on a browser and hit enter?
Answer: This is by far the most popular question we have seen. It’s a great question because it gives you the opportunity to showcase both specific and general knowledge in web development. Try to be detailed in your answer, especially in your area of expertise (front-end, back-end, networking, etc.).
The following list below are the important steps to remember when answering this question. We recommend that you go into more detail in your area of expertise.
- DNS Lookup: You should mention that the browser will look for the IP address of the URL (either in the cache, or doing a DNS query).
- TCP connection: You should talk about how the browser initiates a TCP connection (HTTP is a protocol that utilizes a TCP connection). There is a handshake that happens between the client (browser) and the server. If you have knowledge of HTTPS vs. HTTP, this is a good time to mention how they differ. If you have knowledge of sockets, you can elaborate more on the details of the connection and the ports that are commonly used (HTTP uses port 80 and HTTPS uses port 443). You can read more about HTTP here.
- HTTP request: This is where you mention that going to a website on a browser is a GET request. It’s also a good time to talk about what information is sent with a request (headers (cookies, cache headers), URL (query parameters), etc.)
- HTTP response: Depending on your knowledge of web servers, you can go into a lot of depth here talking about how a web server works and responds to a request (load balancers, API gateways, request handlers, etc.). You should then mention the type of responses the request can have (status codes, formats (HTML, JSON, XML, etc.)).
Here is a good answer to this question on medium.
Q2: How does user authentication work?
Answer The best way to study for this question is to try building a basic app with user authentication! Here is a good tutorial on building a login/auth app using the MERN stack.
There are many different user authentication systems, but most interviewers are looking for familiarity with password login systems. Here are some topics you should mention in your answer:
- Signup and Login: A new user will sign up to a system with a password. The back-end will store a hashed version of the password (not the password itself). When a user logs in, the password will be hashed and will be compared to the stored version.
- Token Session Management: A token is usually generated for the user so that users don’t need to keep logging into your app to use it. The user will use this token to make authenticated API calls to your application. Tokens have an expiry time, which dictates when the user is required to log in again.
- JWT: JSON Web Tokens are very common ways for tokens to be generated to verify users. They work by encoding a payload using a secret key (only known by the server). Everytime a user makes a request to your app, they send the JWT token to the back-end. The server then verifies that the user is correct (by encoding the JWT token with the payload and checking if they are the same) and that the token is not expired. JWT is a great compact way to provide secrecy between parties.
- Cookies vs. Web Storage: Before the token can be sent along with requests, it needs to be saved on the browser. It can be saved as a cookie or in session or local storage. It's a good idea to read up about the differences between the storage methods.
- Log out: To log the user out, you simply need to remove the token from the browser storage.
Outside of the high level topics above, it’s also good to know about other topics related to user authentication such as OAuth 2.0, two factor authentication, passwordless systems, and security problems related to authentication (CORS, CSRF, CAPTCHA, etc.).
Q3: What is a RESTful API?
Answer: Similar to the previous question, the best way to learn about RESTful API's is to build or use them! Here is another tutorial on building a simple RESTful API using NodeJS and Express.
API stands for Application Programming Interface - it is a set of rules to allow programs to communicate with each other. REST stands for “Representational State Transfer” - it is a type of API design. RESTful APIs have 6 guiding principles - client-server, stateless, cacheable, uniform interface, layered system, and code on demain (optional). You can read more about it here.
In our opinion, it's important that you mention in your answer that RESTful APIs have a client-server relationship often used to build back-end applications that talk with front-end single page applications (SPAs). It is also important to mention that RESTful APIs are stateless - each request from the client to server contains all the information needed to understand the request.
Here are other topics you should know related to RESTful APIs:
- RESTful naming conventions: RESTful APIs have standards on what are common naming conventions. You can read more about that here.
- HTTP Status Codes: There are also standards on which status code you should return from HTTP. You can read more about that here.
- RESTful vs. SOAP: SOAP is a standardized protocol used by HTTP - we won’t go into much detail here since it is an older technology that is not as commonly used. However, we have seen companies ask for comparisons before, so you might as well research it!
- SPAs: SPA stands for single page application. Back-end RESTful APIs have become more popular since it’s much easier and more favourable to build SPAs.
Q4: What is the difference between GET and POST?
Answer: As a full-stack developer, you probably have worked with many different HTTP request methods. Companies like to test your knowledge of the different types. It’ll be helpful to familiarize with the following 7 HTTP methods:
- GET: The GET request is the most common method for retrieving data from a server. You should not modify any resources in the server code for a GET request. In addition, you cannot send a request body when making a GET request.
- POST: A POST request is the second most common method - it is used to send data to an API to create or modify a resource. You send a response body in a POST request. A POST request is non-idempotent.
- PUT: A PUT request is similar to a POST request - it is also used to create or update resources. Different than a POST request, it is idempotent (calling a PUT request multiple times will produce the same result). In addition, PUT requests are commonly used for editing a resource based on a known id (or creating one if it does not exist).
- PATCH: This method is similar to a PUT request, except it is used for a partial modification to a resource (it is also non-idempotent).
- DELETE: This method is used to delete a resource - similar to a GET request, it cannot have a request body.
- HEAD: This request is identical to a GET request, except it has no response body. You can read more about it here.
- OPTIONS: This request returns data describing what methods and operations the server supports for that URL - it is commonly used with CORS (you can read more about preflight OPTIONS requests here).
This blog post is a good resource to read more about different HTTP request methods. You can also understand the different HTTP methods with respect to RESTful APIs here.
Q5: How do you optimize the performance of a website?
Answer: Given that the question is so open-ended, you can focus on the areas of development that you have strength in. Generally the interviewer is also looking for specific answers and the answers they are looking for depends on the role. We have broken down a list of optimizations based on different parts of the stack below. The lists are in no way exhaustive, but they give you an idea of what interviewers may be looking for in an answer.
- Content delivery network (CDN): You can use a CDN to serve static files. It reduces latency for featuring static files on the internet, since a CDN stores a cached version of its contents in multiple geographical locations. When a user requests the static file, the server that is closest to the user will serve the file causing the fastest response time.
- Caching: Browser are able to cache your static files. You can specify in the HTTP response using a cache header - it can tell the web browser if the item should be cached and for how long.
- Image optimization: This is an often forgotten technique - websites often serve very large images causing increased latency. Instead, you can compress and cache served images. In addition, apps can now send variable image sizes. In addition, you can also replace rasterized images with vector images.
- Lazy loading: This is a design pattern to delay the initialization of an object until it is needed - this technique is commonly used when fetching images only as the user scrolls and sees them.
- SPA optimizations: One of the issues with SPAs is they can have an overall slow initial page load time. This is because a SPA may have a long app launch time - when the page initially needs an application (React, Angular, Vue, etc.) to be downloaded and booted before doing the work to render the page. There are a few optimizations related to SPAs -pre-rendering,code splitting, and lazy rendering/fetching.
- Load Balancing: Traditionally websites were hosted on a single machine. The difficulty with this approach is that as your site gets more traffic, you can’t easily scale your application to handle the traffic. A load balancer can solve this problem. You can instead host your application on several machines, and then use a load balancer to distribute traffic to the different servers depending on which ones are more available.
- Vertical and horizontal scaling: You could improve your back-end application’s performance through vertical or horizontal scaling. Vertical scaling is where you improve the speed of your individual servers (more CPU, RAM, etc.). Horizontal scaling is where you add more servers to handle back-end requests.
- Database Optimizations: You can improve your back-end by improving the way you structure your data and how you access it. Often times, applications are slow because they are making many database calls in one API call. You can work on batching your read and writes to the database, or remove any unnecessary database calls. In addition, you could restructure your data in your database (normalization, denormalization, caching certain calculations) to optimize the existing queries that your application does often. You can also use database indexes to improve specific queries in your database.
- Asynchronous tasks: You can use multi-threading or background workers to do tasks that take a long time in your application. Imagine that your application needs to send thousands of emails. An unoptimized approach would involve creating an API call that sends all of those emails (one after another). This doesn’t allow you to run any of those tasks concurrently and it may also slow down your front-end application that needs to wait for the response to be completed. A more optimized approach would be to send emails using background tasks. Each background task could send one email, which will allow your application to send emails asynchronously. Generally applications handle multiple background tasks using a task queue. The task queue can be customized to run at a certain concurrency rate and a certain number of jobs per second.
- Caching: There are many levels of caching that you can implement on the back-end to improve its performance. For example, you can cache entire back-end API calls, specific calls to your database or third party APIs, specific calculations, and specific data. Redis and memcache are commonly used caching databases.
- Code performance: For both the front-end and back-end, you can optimize your website by writing more efficient code. This means writing algorithms that has good time and space complexity (read about Big O Notation to learn to measure computational complexity). This generally means reducing nested for loops, and using data structures to reformat your data. In addition, you can write more efficient code by reducing unneeded code (calls to a third party API/database, reducing rendering on the front-end), memoization and other code performance techniques.
There are many more possible optimizations - most of the time, optimization depends specifically on your application and its bottlenecks. If you want to learn more, here are a few topics to check out:
- Gtmetrix: This is a cool website where you can put your URL into this website, and it’ll tell you what you can improve on to optimize the front-end of your application.
- You can read some more resources here: front-end optimizations, more front-end optimizations, back-end optimizations.