After applying for a vacancy, and going through the screening stage — a process of sorting the candidates’ CVs, seeking and selecting those who have the greatest adherence to the vacancy — we have the moment of the technical challenge, where a small project is usually sent to be developed.
The purpose of this stage, as the name implies, is to make a technical assessment of the candidate’s practical knowledge, and for that, some important points are analyzed, which I will address so that you can be as assertive as possible at this stage and be able to move forward. to the next.
Fully understand the proposed challenge
- When you receive the project description, set aside a good amount of time to read, understand and write down any doubts.
- Make a checklist of each item, this will make it easier when you are at the time of development.
- If you have any doubts, be sure to ask the recruiter, this is not seen as a negative, on the contrary, it only demonstrates that you have read the challenge thoroughly.
Focus first on developing everything that was asked, then think about refactoring or adding something you think is important.
The README file
Give maximum importance to the README file, it is the white paper of your application and will probably “speak” for you when the code review is carried out.
A good README file should answer the questions below:
- What is the purpose of the application? What does she propose to solve
- What technology was used?
- Which architecture did you choose? It’s because?
- Was any external library or framework used? Justify the reason for use.
- What are the existing dependencies?
- How to run the application?
- How to perform automated tests?
- Is there any technical documentation detailing what was developed?
A tip is to deploy the project in a cloud provider (there are some free ones such as: Heroku, AWS free tier, GCP free trial) and inform the url in the README file, this helps, if for some reason, problems occur when executing the application locally.
Focus on quality, not quantity
When starting the development stage, keep in mind that the objective of the challenge is to be as close as possible to a real application that will undergo code review, code quality tool and execution of automated tests.
When choosing technology and architecture, give preference to the one you have the most domain. This is not the time to put into practice things you are studying and do not yet have complete knowledge of. Rather develop a solid, well-structured and organized application using MVC than try to implement a hexagonal or any other architecture and violate most principles.
Write clean code, with clear nomenclature of functions and variables, keep classes small and with few responsibilities, functions should only have one responsibility, if you have more than that, isolate in other functions, observe the Coding Guidelines of the chosen technology, remember from the 5 S.O.L.I.D principles and also DRY, KISS, YAGNI.
Quality prevails over quantity, so anyone who thinks that delivering several extra features will guarantee a better evaluation is wrong. So focus on quality!
Tests are essential, or rather, mandatory!
Never submit a technical challenge without automated tests! As much as it is not explicit in the project description, assume that tests are mandatory.
Tests ensure that the features created will work exactly as expected, and that future modifications or implementations will not covertly break any part of the application. And if it breaks, you will have knowledge and you can make the correction before sending it to production.
I suggest taking the time to study TDD, this will help you create the tests even before having all implementations of an application finalized.
And remember: Never submit a technical challenge without automated tests!
Last but not least
As I mentioned earlier, the idea is to deliver an application prepared for a productive environment, having said that, we have to take into account the following points:
- Monitoring: Does your application have a log service that allows you to monitor it? Is it possible to identify errors easily?
- Scalability: Will the developed code scale when a new feature needs to be added?
- Performance: Is the developed application performing? What does that mean? Is it able to receive a high volume of requests without generating some kind of bottleneck? Small changes make a big difference in this item.
- Security: Is the input data securely handled? Outputs not exposing sensitive data?
A tip to read is the 12factor (Twelve-Factor App), which has 12 guidelines on developing software as a service.
—
It’s not a cake recipe, but using these tips you have everything to do well in the next challenges.
Follow there, and then tell me how it went ?
