10 Essential Full-stack Interview Questions *

The purpose of this question is to test the candidate’s knowledge of RESTful API standards. A common mistake when building endpoints is to use descriptive verbs in the path. For example:

• GET /users/search
• GET /posts/create

Instead, a truly RESTful path should only contain nouns—the method used on the endpoint should determine the action. For example:

• POST /users (create a user model)
• PUT /users/{id|slug} (replace a user model)
• PATCH /users/{id|slug} (update part of a user model)
• DELETE /users/{id|slug} (delete a user model)
• GET /users/{id|slug} (retrieve a user model)

Determining whether a resource exists is an action that is frequently required in APIs, but is rarely done correctly according to the RESTful and industry standards. The commonly accepted way to determine if a resource exists, using the above “user” resource as an example, is like so:

• HEAD /users/{id|slug}

This request will use the least amount of bandwidth as it will return no data, simply just a 200 (resource exists) or 404 (resource does not exist) HTTP status.

The key issue with the proposed table design are the object_id_X and object_type_X fields. It is considered poor design to increment named fields when the data could be stored in a related table like so:

Notifications Table

CREATE TABLE `notifications` (
	`id` INT NOT NULL AUTO_INCREMENT,
	`type` INT(8) NOT NULL,
	`notifiable_id` INT unsigned NOT NULL,
	`notifiable_type` VARCHAR(10) NOT NULL,
	`updated_at` TIMESTAMP NOT NULL,
	`created_at` TIMESTAMP NOT NULL,
	PRIMARY KEY (`id`)
);

Notification Relations Table

CREATE TABLE `notification_relations` (
	`notification_id` INT unsigned NOT NULL,
	`relation_id` INT unsigned NOT NULL,
	`relation_type` VARCHAR(10) NOT NULL,
	PRIMARY KEY (`notification_id`)
);

The most effective way to solve this problem is to use queues.

When a request is made to our API, a separate job is then created and added to a queue. This job will then be executed independently to the requested endpoint, thus allowing the server to respond without delay.

There are many queue providers but the most notable are:

• Amazon SQS
• Redis
• Beanstalkd

Although the answer to this is debatable, the widely accepted practice would be to use a 409 Conflict HTTP status code.

It would also be acceptable to return a 422 Unprocessable Entity.

Some may argue that a 400 Bad Request is acceptable, but we discourage this, since conventionally it implies the server did not understand the request, which in this case is not true.

If the data within the API is publicly accessible then, technically, it is not possible to completely prevent data scraping. However, there is an effective solution that will deter most people/bots: rate limiting (also known as throttling).

Throttling will prevent a certain device from making a defined number of requests within a defined time. Upon exceeding the defined number of requests, a 429 Too Many Attempts HTTP error should be thrown.

Note: It is important to track the device with more than just an IP address as this is not unique to the device and can result in an entire network losing access to an API.

Other less-than-ideal answers include:

• Blocking requests based on the user agent string (easy to circumvent)
• Generating temporary “session” access tokens for visitors at the front end. This isn’t secure: Storing a secret on the front end can be reverse-engineered, thus allowing anyone to generate access tokens.

Firstly, and most importantly, the answer should include one, and only one, query. There are numerous ways to achieve the expected result, but the correct way is the following:

SELECT
   posts.*,
   COUNT(post_likes.user_id) AS likes 
FROM
   posts 
   LEFT JOIN
      post_likes 
      ON posts.id = post_likes.post_id
WHERE posts.user_id = 'XXX'
GROUP BY posts.id

The key attributes here are srcset and sizes. These attributes allow the developer to specify multiple image sizes for one <img>, for example:

<img src="https://example.com/images/image.png" srcset="https://example.com/images/image-1024.png 1024w, https://example.com/images/image-512.png 512w" sizes="100vw">

By using srcset and sizes, the browser will then intelligently select the correct image source to be used based on the size of the visitor’s viewport.

Any suggestions of changing the image source using JavaScript based on the size of the viewport should be seen as a red flag. This indicates the developer has not been keeping current with CSS feature support and/or best practices.

There are technically various ways to achieve this. However, nowadays, there is one “correct” way to do this: using display: flex and margin: auto.

Other methods include position: absolute;, top: 50%, and margin-top: -Xpx, but these are no longer considered good practices since the introduction of display: flex.

In order to build a site optimized for organic search engine rankings, it is important to implement certain standards throughout the code. These include:

• Specifying an alt tag on images
• Using the correct HTML tags for content hierarchy i.e., <h1>/<h2>/<h3> and p
• Connect the site to the company’s social pages
• Add an XML sitemap
• Avoid broken links
• Use vanity/friendly URLs (human readable)
• Add a robots.txt file
• Integrate Google analytics (or alternative)
• Specify a favicon, bonus for specifying browser specific icons
• Ensure lightning fast page load time
• Avoid JavaScript errors
• Optimize assets (including minification)
• Enable and force SSL
• Specify unique titles for each page without exceeding 70 characters
• Include a meta description on each page
• Ensure there is enough content with enough relevant keywords (search engines will penalize your site if all pages are one-sentence pages)
• Leverage browser caching
• Avoid W3C markup validation errors
• Specify relevant meta tags