Coding interview – 5 simple rules that increase your chances
“Talk is cheap. Show me the code.” – most of us heard that quote by Linus Torvalds. We applied it to recruitment process making coding interview the most important part. Since early days we knew it will pay back and it did.
We also knew that refinement process requires constant measurement. So we track everything – cycle time, lead time, lead generation, time spent per stage, email communication and what’s most important for you – code review outcomes. Furthermore, our adds, jobs offers, and email conversations were discussed dozen times to make sure we give more to the candidates than any other company on the market.
Today, I’m happy to share with you 5 tips that will highly increase the chances of passing a coding interview. All of them are based on observations from more than 1000 interviews. It’s not guesswork.
No 1: Write a high-quality code.
Quite often candidates try to show their best nailing down business logic behind the coding task totally forgetting about proper code quality. To us, Clean Code is a must have, not something optional. Regardless of the position, language and your experience we expect a solution to be clean and readable. Things like inconsistent formatting, meaningless comments, class names that don’t express their purpose are warning signs for every reviewer.
We deeply believe that first book that a developer should read once he knows how to write code is a Clean Code by Robert C. Martin. Just think about it, you do it once, it’s an easy read and it affects your entire career.
No 2: Make sure you have good tests.
Not only good but great. If you use Junit that’s fine, even better when you write in Spock. Regardless of the framework or technology tests are crucial. This is how we ensure that our code works. This is how we eliminate uncertainty and increase confidence.
There are a few aspects every developer needs to know to write good tests. Frankly speaking, all of them are quite basic like Test-Driven Development, testing levels, mocking vs stubbing, tests pyramid, FIRST rule and few naming patterns. Nothing more, simple right?
The best thing is that you can read about them in a famous book Growing Object-Oriented Software, Guided by Tests by Steve Freeman.
No 3: Know technology you use.
In a majority of the cases, Java developers pick the most popular framework ever created – Spring, precisely Spring Boot. Although it’s not a strict requirement, I’ll use it as an example.
If you haven’t worked with it in the past there are great tutorials on official Spring website. They will walk you through important aspects of aforementioned technology to a sensible level. None of them takes more than 15 minutes.
Practically, to pass coding interview it’s enough to understand Spring Core and it’s dependency injections mechanics, Spring MVC and Spring Data. There is no magic here! Just make sure you did your homework. Or else you will scope every class as public, inject a mutable object into singletons through setters or write your own DAO using criteria API.
Again, Spring, as well as JPA and other widely adopted frameworks are here to stay. So don’t hesitate to invest little time into them. It will payback in the future and make your solution look professional.
No 4: Take your time to properly design solution.
Ideally, Domain-Driven Design and a rich domain model. However, we saw a great number of solutions without some of the artefacts from DDD that absolutely satisfied our expectations.
All of them met three points listed above. All of them were SOLID and kept simple. Most of the time what stands out is a package structure focused on business context, proper encapsulation, consistent design and the rich domain model.
What we don’t want to see on the other hand is the most common solution – a controller, service and datastore.
There is a great book Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans that we happily recommend to everyone interested in software design. Clearly, it takes more than one book to become software architect but this is where you start.
No 5: Build RESTful API.
Let’s be honest, REST API – any API in fact – is a product itself. It’s as important as a user interface or user experience that we all care that much. After all, we live in a world of open APIs where SaaS solutions are more than welcome. There is no guarantee that one day API that was “supposed to be private” will not become publicly available.
It’s even more important when you think about experiences that nearly every programmer have – working with badly designed API. It never behaves as you expect, it logically does not make sense. Sometimes, it even does not work. Part of the problem is that APIs are hard to design or change. Another part is that we don’t pay much attention.
Be a good citizen, don’t harm other developers and design according to APIs best practices.
This is it guys, 5 simple rules to increase the chances of passing a coding interview.