Coding Assessment: why and what are we looking for?
As part of our recruitment process, we currently offer candidates the option of a take-home code exercise and/or doing a pairing session. Even though the code exercise requires a longer time commitment, some candidates choose it because of the flexibility to work offline, timezone challenges or simply to show us their coding skills.
So here is an “open letter to candidates" about what we're looking for when we review their code:
Dear candidate,
Although we call this a Coding Assessment, just solving it like a challenge is not as important to us as how you solve it. We’re not simply evaluating your delivery capability, we are actually measuring the internal quality of the code you write.
But everything in life has constraints and yours is the time you should be dedicating to this. We really appreciate and respect that you have chosen to spend some of your personal time writing code so we can better understand how you do it. But we are OK if you make a few assumptions and impose a few constraints so that you don’t spend too much time on it, just please document those in your readme file.
Our day-to-day job at Pragmateam is to go to clients and deliver high quality code, raise the bar, coach others and be the ones pushing the boundaries in terms of techniques, technology and practices. So when we look at a code challenge solution we are trying to understand if you would be a good fit in this context, so we essentially wish we could see the best of your knowledge, practices and techniques. We are pragmatic (it’s in our name after all) and in some situations we need to discuss trade-offs and compromises to deliver on time with good quality, so we understand this challenge might not be 100% realistic but it’s a tool we use to understand more about you and how you code.
So pick a few things where you want to show the best of your skills, it could be testing, architecture, code structure, frontend design or anything that you like and think you’re good at. If there are some things that you consciously decide not to prioritise and you just bootstrap them, that is fine but again, please mention them in your readme file.
We have added a few constraints such as not using frameworks and it is because we want to see your code and how you do things, not how the framework does it. In real life, we will probably be using a framework but we will know exactly why and be aware of how all the 'magic' works and where we could have problems. But in the coding assessment it’s important to understand your own choices of architecture, libraries, project organisation etc.
If there are some parts of the solution that you just want to make a little bit simpler, such as using some pre-baked data structure instead of a real DB, that is totally fine but, again, make sure you document it so we understand you consciously took a shortcut for the sake of the assessment.
Finally, to give you an idea of what we’re looking for, this is a list of keywords that show up in coding assessment reviews. It’s probably impossible to address every single one of them perfectly so don’t get stressed about it but just take it as an example of things that are important to us (hint: at Pragmateam, we never write code without writing tests, so there you go):
breakdown into multiple systems, usage of paradigms (Functional, Event Sourcing etc.), architectural decisions (messaging, DDD, Contexts etc.), unit test, acceptance test, integration test, functional test, TDD, code quality, cyclomatic complexity, use of patterns, up-to-date coding techniques, programming language knowledge, error handling, extensibility, decoupling, developer feedback loop, running & setup, instructions (readme), linters, version control, static analysis
All the best with your coding, we hope you enjoy the assessment and we promise we will always review it respectfully as we really appreciate the time you are spending on it.