A test to evaluate a back-end developer requires asking questions that go even further than the code, for instance, testing their knowledge about HTTP (Hypertext Transfer Protocol) or even authentication systems such as JWT (JSON Web Tokens).
In this quick guide we will show you some suggestions to evaluate a back-end developer.
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:
What is JWT and what are its 3 main components?
Can you use GET instead of PUT in order to create a new resource, why or why not?
What are the components of microservices architecture?
What is integration testing?
What is ACID (atomicity, consistency, isolation, durability)?
What is the N +1 problem?
What is an ORM?
How would you find the most expensive searches in an app?
What is the difference between HTTP and HTTPS?
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.
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