Hiring Developers at Smart Pension
Hiring is always a difficult thing to get right. One of the most important things is to see if it’s a fit on both sides, the candidate needs to see if this is a place they want to work in and you want to see if they will fit in with the team.
To help the discussion, let’s chat about how we do Engineering interviews at Smart Pension.
The overview:
- Initial phone call (30 minutes)
- Take home programming test (up to 2.5 hours)
- Test reviewed by Engineering team (we aim to get back to you within 24 hours)
- In person code pairing exercise (1 hour)
- In person cultural fit chat (1 hour)
Initial Phone Call
Once a CV is reviewed, an initial chat with our Recruitment team is scheduled to discuss expectations. It’s a quick chat to see if we’re what you’re looking for and vice versa. If that’s still a match, this is where it gets fun! Also a chance to ask any burning questions.
Take home programming test
We send the candidate a take home test. The test is below:
Ruby Developer Test
Before you start coding (and let’s be honest, we know that’s what you want to do), please read the following.
Firstly, the test should take you no more than 2.5 hours to complete.
Secondly, the test is for us to see how you code and the methodologies you use, what we will be looking for in this test are the following:
● Functionality
● Efficiency — We like clean, simple code.
● Readability
● Tests (we have 96% test coverage in our code and we aim to keep it that way).
● Also, we would like to understand your ability to use TDD and OO, so please ensure these are part of your complete test.
● Feel free to submit your solution as a link to your version control repository
The test is as follows:
1. ruby_app
Write a ruby script that:
a. Receives a log as argument (webserver.log is provided)
e.g.: ./parser.rb webserver.log
b. Returns the following:
> list of webpages with most page views ordered from most pages views to less page views
e.g.: /home 90 visits /index 80 visits etc… > list of webpages with most unique page views also ordered e.g.: /about/2 8 unique views
/index 5 unique views etc…
Finally, have some fun — Feel free to make changes or design something if you think it meets the criteria above, but would produce better outcomes and of course, the sooner you return the test, the quicker we can move the process.
If you want to code it up yourself, the test file is over here: https://textuploader.com/159t1
Why make the test public? You really can’t cheat at it as the next step is we bring you in to pair with our Engineers to work on extending your solution. Those that have copied it are found out rather quickly. We’ve had people copy solutions they have found online — most of those online solutions are from people who currently work at Smart!
Test reviewed by Engineering team
Once the test is completed, our recruitment team sends it across to the Engineering team to review. The names of the candidate are stripped from any solution, so that Engineers review tests blind. This means no biases are brought in, we review code purely on the code itself. After reviewing, the Engineers (and at least 2 Engineers review every test, often more) also recommend what level the candidate is.
We do separate tests on one criteria, junior vs anyone else — We’re a little bit more understanding of people learning at that level (We use 5 criteria for reviewing Junior tests, one of which is “ Not copied from someone else”. Okay this also applies for everyone, but we recently had a massive spike of people applying for junior roles just copying code found on github and changing a few variable names).
We use a trello board to track the tests, a new card is created when the recruitment team needs the Engineering team to review, an alert is automatically made in #sp-dev-recruitment slack channel.
Feedback is then given independently on the card (the recruitment team normally puts their name on the card so it’s easier for them to track progress).
Feedback is then sent to the candidate, whether good news or bad news. It’s always constructive feedback, as Engineers we should always be looking for ways that we can improve! Why code reviews are fun! Our code base is of an extremely high quality, we develop using TDD, so we’re looking for people who understand that philosophy of building high quality code and who want to work with a TDD philosophy.
In person code pairing exercise
The best way to get a feel for the team you could be working with is to pair with them. At Smart, we do a lot of pairing, not all the time, but most of our Engineers pair at certain times.
Bring in your own laptop! We’ll connect you up to the Internet when you get in.
We don’t believe in whiteboard coding exercises, we’d rather you program in the way you do day to day. Use whatever tools that you are comfortable with
During the pairing, there are normally two Engineers present. We chat about your solution, explore ways we can extend it and code away.
Next we give you a short programming exercise. What we’re looking for here is understanding how you work and if you’d enjoy working with us.
Finally a few general Ruby questions.
It’s a highly interactive process! We encourage you to ask questions back.
In person cultural fit chat
Next up, with 2 different members of the team, they could be Engineers, Scrum Masters, Product Owners or Engineering Managers. We have a chat about culture at Smart, how we work and how you like to work.
We have a highly collaborative culture at Smart, everyone helps everyone to deliver awesome high quality software, so we want to make sure that’s a place you’ll enjoy.
Some people really like to be given a problem and then being left alone for weeks to complete it, we don’t work that way. We focus on the team building the best possible solution that they can.
Our teams are empowered to decide on what processes to put in place (they do get advice from Engineering Managers and Agile Coaches), but they do make the final decision. For example one team recently switched from Kanban to Scrum. After a few weeks they have switched back to Kanban. We encourage that experimentation!
We’re also building software for the long term, so want to make sure we’re building it properly. Pensions are long term, our software (or at least the data) will be being used 80 years from now. So we want to make sure we get it right.
We leave plenty of time for questions from you, normally at least 20 minutes. Again, we want to make sure this is a workplace you’d enjoy working in!
Conclusion
We believe that diverse teams makes the best teams. We want you to bring your true self to work. We don’t care who you are or what you wear and we don’t discriminate in any way.
All of us have innate biases, so we make sure where ever possible we have a diverse group of people on the interview panel, including at least one woman. After the interview loop, we get together with the hiring manager where we discuss the candidate and make a decision. Part of the job of the hiring manager is to ask the questions of the interviewers to make sure they aren’t bringing their own biases into the interview process. As humans we often tend to hire people who similar to us — the goal in building an awesome team is to hire people who don’t think like us, while at the same time having the same core values (passionate about development, collaborative, care about building high quality software).
After our conversation, we then chat to the recruitment team, give our feedback and aim to have feedback to you within 24 hours. Feedback is always sent back to the candidate, whether good or bad news. We aim to make it constructive as well, areas for you to improve or grow in.
Our hiring process is a work in progress. We also firmly believe in Kaizen — continuous improvement. We’re always tweaking the process to make it better. So if you have any suggestions, we’ll love to hear them!
And if you’re looking for a role, we are hiring, check out our jobs page: https://www.autoenrolment.co.uk/careers
