You’re a talented software engineer looking for your next position.  Maybe you’re eyeing the FAANGs so you start researching how they do their technical interviews and you discover they like to ask algorithm-type questions – Reverse a linked list in place, Print the kth level of Pascal’s Triangle, Does string contain substring – and have you design Dropbox, Twitter, or some other system of their choosing.

Then you apply to FreeAgent.  You go through our entire interview process and think “Where was the algorithm question?  And why didn’t I have to design Facebook?  The big companies are asking these questions, why didn’t you?”  It’s true, we don’t ask algorithm questions during our interview process nor do we ask you to design an arbitrary system.  Let me explain why.

The Dreaded Algorithm Interview

I’ll be honest with you.  I used to ask an algorithm question.  Return the longest English word one can generate from a 4×4 grid of letters (the Boggle challenge – feel free to email us your solution).  And you know what?  Some of us liked the question because, like algorithm questions in general, it can tell you a lot about a candidate in a short amount of time – how they approach a problem, their critical thinking skills, how vocal they are during their thought process, if they understand recursion and time and space complexity, can they code up a simple solution quickly, what they might be like to work with.  But these types of questions are stressful for a candidate and can require a lot of studying and practice ahead of time.

At some point we realized one’s ability to solve the Boggle challenge didn’t correspond to the person’s success here.  After thinking about why there seemed to be no correlation we determined that of all the things the algorithm-type questions can tell you about a candidate, we cared about slightly different things.  Additionally we decided that if none of us liked doing them during our own interviews, why would we subject our future colleagues to them?

While working at FreeAgent you won’t be writing bespoke algorithms or trying to find ways to improve QuickSort, and we’ve never had to reverse a binary tree as part of our day-to-day work.  We deal with a complex subject matter (taxes and finance) so being able to model, design, and code an extendable, readable, and maintainable solution is more important to us than if you can remember how to write a depth first search.  Taxes are hard enough without throwing spaghetti code into the mix.  This means the algorithm questions weren’t a good fit for us or our prospective coworkers.

We give candidates a take-home Ruby challenge instead – write an API given a list of requirements.  The challenge shouldn’t take too long but knowing that we all have lives outside of work and hoping to reduce the stress of interviewing, we give candidates as much time as they need to deliver a solution they’re proud of.  Once we receive a code submission a group of FreeAgent engineers will evaluate it.  Your solution and any follow-up conversations are what help tell us how you approach a problem, how good your coding skills are, and – what we found more important – how you model and test a solution.

The System Design Interview

Many companies have a system design interview where they ask you to design something of their choosing.  These are good questions because the interviewer can really dig into specific areas to see your thought process.  Do you attempt to simplify the problem before you get started?  What assumptions do you make about the requirements?  What’s your naive approach?  How would you then scale your solution?  What are the security risks?  These are real questions you should be asking yourself while working on a project so it’s important for a company to get an idea of your abilities in these areas.

Instead of giving you a system to design we change it up a bit in our technical interview by asking you to describe and whiteboard* a system you’ve worked on in the past.  We’ll look for you to answer questions like why the system was designed that way, what tradeoffs did you have to make and why you made them.  We may challenge you on some of those decisions or offer alternative approaches to see how you go about evaluating them.

We feel we get the same information out of this stage as other companies while using a less contrived situation.  The downside is it’s harder on us as interviewers.  If I ask you to design a system of my choosing, I’ll likely have a “right” answer in mind already.  Our method forces us to get to know your system and then question it.  The upside is it helps us see how you approach real-world projects and how you are at explaining a system to someone unfamiliar with it.  Both of which are things you may have to do during your actual day-to-day job here.

*Note: If we happen to be in the midst of a global pandemic, instead of having the technical interview in our Edinburgh office, we’ll use video conferencing (but what are the chances of that happening?).

Trade Offs

Now, dear reader, you may be thinking it takes more effort on our part to answer similar questions about a candidate than if we’d used algorithm and contrived system design questions.  You’re not wrong.  Between getting a group to read through, understand, evaluate, and then chat with you about your code challenge submission, and learning and questioning a system design you’ve chosen we put a lot of time into our hiring process.  We’re ok with that.  Not only do we want to make the interviews as stress-free as possible for our candidates, we feel this process gives us a more accurate gauge of a candidate’s abilities as they relate to FreeAgent.  And, that way, we get candidates that are the best fit for us.

FreeAgent is blessed to be of a size where we can still take the time to evaluate each candidate in this manner.  Maybe someday we’ll no longer have the ability to do so but until then put away your copy of Cracking the Coding Interview and instead immerse yourself in the world of good programming practices and system design.  We look forward to seeing what you come up with.