The knowledge a back-end developer is required to have goes beyond programming language, since there are technologies and protocols the programmer must deeply understand in order to do a good implementation. Let’s see:

General topics:

1. What is JWT and what are its 3 main components?
2. Can you use GET instead of PUT in order to create a new resource, why or why not? 
3. What are the components of microservices architecture?
4. What is integration testing?

Databases

1. What is ACID (atomicity, consistency, isolation, durability)?
2. What is the N +1 problem?
3. What is an ORM?
4. How would you find the most expensive searches in an app?

HTTP protocol

1. What is the difference between HTTP and HTTPS?
2. What are HTTP status codes? Mention what are codes 200, 301 and 500 for?

Take-home projects as a complement to the interview

Traditional tests used to evaluate a modern back-end developer usually have these specifications:

• Design a RESTful API (full CRUD)
• Deliver a document with endpoints and the database model 
• Deploy everything to a test server 

Despite everything being okay with this type of tests, other aspects need to be taken into account, for example:

• Add some type of API authentication as JWT (JSON Web Tokens).
• Create documentation for the API using a tool such as Postman 
• Do unit testing.

Designing the test with a coherent structure is also something that must be kept in mind in order to avoid misunderstandings when the developer resolves each take-home test. It should have at least 3 essential components:

• Objective: To describe what the app must do. This can be described in just two or three lines.
• Functional requirements: Here, the functionality the API should have is described.
• Technical requirements: Here, specific technologies or the way in which some aspects have to work inside the project are described. 

Evaluating best practices

Within most technologies there are many ways of doing one thing, that is why it is a good idea to evaluate the standards the programmer implements in the code. Let’s see some of these best practices:

• Implement error handling, for instance, by using HTTP status codes correctly.
• Use names instead of verbs  in the endpoints (For example: DELETE/products/123 instead of DELETE/deleteProduct123)
• Versioning of APIs, for instance, in https://developer.github.com/v3/ the last version is indicated at the end or the URL
• Document the APIs

These are just some of the conventions used the most when it comes to creating APIs, however, each technology has its special features and the company must determine what the criteria is for determining whether it is or not a good code. 

Conclusion 

Technical take-home tests usually take a long time, and some developers even do two tests at the same time with a different company, therefore it is conceived as an exhausting task and for that reason many companies choose to do short tests that a programmer can complete within 3 or 4 days.

It’s important to clarify the type of candidate that is wanted and of course, offering them more than a good remuneration in order to attract the best candidate

‍