Getting Past the Tech Test

A talk for London Ruby User Group, October 2020

I used to have trouble with tech tests. I could write code, but I wasn't really sure what they were after, or how to best present myself. Now that I'm better at it, and reviewing a lot of tech tests, I see others having the same struggles I did. I wrote this presentation to see if I could help.

Transcript

1. GETTING PAST THE TECH TEST Understanding the unspoken expectations – and how to exceed them. Michael Mazour for LRUG October 2020
2. WHAT IS THIS TALK? I know good developers who have had a lot of trouble with tech tests. They don’t lack coding skills. But they lack tech-test skills and savvy. Lack of tech test savvy is bad for everyone. It keeps good people out of good jobs, and it causes good companies to miss out on people they’d love to have. I used to have this problem myself. I improved those skills, and you can too.
3. WHAT IS THE TECH TEST FOR? It’s only partly about whether you can solve the problem. Yes, you do have to solve the problem, but what’s more important is that all you’re given is a problem statement. You are writing a greenfield application. You could do anything. Just a script. A script with a test. An object-oriented solution with unit and integration tests. An OO solution with tests plus whatever else you consider core best practices. What you do with that green field is what tells potential employers who you are.
4. “The tech test is our chance to meet you.” - My current CTO
5. THE COMPANY’S GOALS • Filter people who can’t solve the problem. • See how you solve the problem. ◦ Did you fulfill professional expectations and not just stated requirements? ◦ Roughly assess your level. • “Are you one of us?” ◦ ...or alternatively, “do you seem teachable?”
6. YOUR GOALS • Solve the problem that was given. • Demonstrate professional skills. ◦ Demonstrate your skill level. • “When I work with you, this is what you’ll get. It’s good and we both know it.”
7. DISPLAYING PROFESSIONALISM Use the test to show how you work in real life. Markers of a professional work environment that should also be evident in your code: • Rigorous testing • Coding standards • Concern for efficiency and performance • Concern for clarity • Handling unhappy paths And always remember, • Companies have devs at all levels – so code has to make sense to devs at all levels.
8. REVIEWERS ARE A DIVERSE POPULATION Reviewers might be the most senior devs at the company – or they might be a year out of boot camp. Most engineering departments include devs at a wide variety of levels. So code at the company needs to be comprehensible to every level of dev there. Your tech test needs to be that too. Make clarity – code, object relationships, flow of control, naming – a key goal.
9. ASSESSING YOUR LEVEL You can’t perfectly tell someone’s level from their tech test – but you can usually get a pretty good clue. • How good is the solution? Is it complete, is it clean, does it scale? • How much evidence is there of the standards of professionalism being simply business-as-usual for the candidate – vs. these standards being unfamiliar or a struggle?
10. HOW TO THINK ABOUT THE PROBLEM • Consider it primarily as an OO design problem. Try to express your solution in clear object-oriented concepts. ◦ Consider following well-known guidelines such as SOLID principles or GoF patterns. It’s a common expectations nowadays. Even if it’s not what the company cares about, you’ll still have clear reasons for decisions in your code. Following a philosophy – even if it’s not the company’s philosophy – shows you’re knowledgeable and teachable. • Focus on the core first. Make it good before spending time adding features. • Think about flexibility, generality, reusability. How much rewrite would your code/tests need if the problem statement changed in some way? • Evidence professionalism. There’s another slide on that.
11. WHAT ABOUT TIME LIMITS? “This shouldn’t take more than 2-3 hours.” – what should you do? Here’s what I’d do: 1. I’ll plan for that time window, and not overcomplicate my solution. 2. I’ll think a bit first – why start the clock before you know what you’re going to write? 3. I’d build professionalism into my submission from the start. 4. My README will explain my choices (and maybe list some good ideas for v2). – and – 5. I have existing small projects done well that I can use as timesaving templates: folder structure, dotfiles, binfiles, etc. all ready to be cloned over. This is a big timesaver and helps keep you from forgetting things.
12. THE IMPORTANCE OF THE README Of course you need the basics: installation, running the code, running the tests. Beyond that the README is your chance to explain your work – a quick guide to the classes, why you made certain choices, and perhaps areas to improve. The best gems all have a high quality README. Your test should too. It can also be a place to keep track of your progress as you go through the test. Start with your TODO list in the README, and move items out of it as you do them. What’s left at the end becomes the list of areas for improvement – things you would have done in a real project or if you had more time.
13. SOME GENERAL DO’S • READ THE PROBLEM. ◦ Don’t be someone who misreads or only partly fulfills the problem statement. • Use OOP. ◦ Part of showing you understand Ruby and how to use it well. • Use TDD. ◦ Sometimes it’s obvious someone didn’t. • Make it easy to run your tests and your solution. ◦ Your reviewer doesn’t want to spend extra minutes on Docker pull / build cycle. • Use a current, non-edge Ruby. ◦ Same reasoning as above.
14. SOME GENERAL DONT’S • Don’t do “just a script.” ◦ Note: a script wrapped in classes is still a script. • Don’t show off at the expense of clarity. ◦ Mentioned earlier. • Don’t overcomplicate the solution. ◦ Tech tests usually don’t require all that many classes / moving parts. • Don’t overdo extra features. ◦ If you feel you want to add something, be sure it doesn’t distract from the clarity of your solution – and that it’s not a lot of added burden to review.
15. WHAT IF YOU’RE DECLINED ANYWAY? Sometimes reviewers just don’t like your tech test. Try not to panic. Avoid telling them why they’re wrong. Instead I suggest this script. “I’m very responsive to feedback, and I’m always interested in improving my skills. Is there any feedback you’re willing to provide that could help me do better in future?” Then if they say yes and give you some, you can follow up with “Thank you. Would you be open to my doing the test over using this feedback, and resubmitting?”
16. The tech test is your chance to show us who you are, through your code and professionalism.
17. Thanks! Michael Mazour Technical Architect at Smart Pension Ltd. Get to know us at smart.co