What to expect from a Quant Platform Software Engineering interview
The Quant Platform team, part of software engineering, develops and maintains the software at the very core of G-Research’s business. As G-Research continues to grow, our team is aiming to expand aggressively as well, and we’ve put a lot of work into getting our hiring process as efficient and pleasant as possible. Our main goals for the interview process are to:
- Identify the best software engineers
- Hire engineers with a diverse set of skills
- Waste as little as possible of your time and our own time
- Ensure you understand the role, and will be a good fit in the team
Associated with this are things we are aiming to avoid:
- Avoid hiring on biases that are unrelated to quality software development
- We don’t want to hire people on the basis of whether they’ve read a programming interview question book or recently looked at how a red black tree works.
- Avoid candidate success being based on whether they happen to get a strict or lenient interviewer
Two years ago, our hiring process was a lot like the hiring process at many software companies. You would come in, sit down with a pen and paper in a room with whoever was free at the time, and they’d ask you whatever question was their personal favourite, with a clever little trick that they like.
Whilst this method can and does hire good software engineers, it can easily miss out on some quality engineers who are excellent at architecture, or writing easy to understand code, but aren’t great at programming puzzles.
So what components make up our interviews today?
In order to achieve our goal of not wasting your or our time unnecessarily, we will ask you to complete the first stage of the interview at home. We recognise that this takes some of your time and we respect that, we’ve reduced the rest of the interview process by a corresponding amount of time. Doing this means that we save some candidates unnecessarily traveling and or taking time off work. The homework consists of a single question that should take you a couple of hours. You can use any language and tools you like – we mostly work in C#, but we don’t require you know it before you start, so we want to give you an opportunity to show yourself at your best in the language you’re most comfortable with.
Face to Face interviews
If you’re successful at the homework question stage, we will normally conduct the rest of the interviews face to face (exceptions may be made for international candidates). You will have the choice of doing the interview over two half days, or one full day, whatever is more convenient for you. We understand you are probably interviewing at other big name software companies, so we want to make it as convenient as possible for you to interview with us.
This stage aims to most accurately reflect how software is written in the real world. You’ll be set up on a computer, with a fully functional IDE (Visual Studio + Resharper / IntelliJ) and an internet connection, so you can search Stack Overflow or whatever else you need. In the IDE there will be a project set up with a small code base. We will give you the simple task of adding a feature to the code. However, the code isn’t set up in a way to make this feature easily testable. We’re interested in seeing how you refactor the code to make this change testable, what test cases you add, and what other improvements you make to the code while you’re in there.
In this interview, we’ll ask you to design a system for us. The goal isn’t to find out whether you happen to know how systems of this kind tend to work, or for you to have a full spec for us by the end. What we want to see is how you grapple with a business level problem. Can you come up with a number of different solutions to problems and describe the trade-offs of each? Can you ask us the right questions to find out the parameters that influence the design?
As much as I lambasted earlier the old-fashioned sit down and write some clever algorithm style question, this still has some value as part of a well-balanced interview process. We’ve taken some actions to make this part fairer:
- Absolutely no clever tricks: We don’t want to assess you on whether you’ve seen the question before. If you’re getting stuck we’ll prod you in the right direction.
- Questions from a set pool: We have a small set pool of questions, complete with how well to expect candidates to do, and some example hints or extension questions, this reduces sensitivity to who the interviewer happens to be.
This is also our chance to see if you understand the properties of basic data structures, and can do simple complexity analysis.
At G-research, we know that software engineers are the best placed to recognise other high quality software engineers which we are looking for. This is an important reflection of the flat structure of the company and explains why up until now, all of your interviews will have been conducted by engineers. However, the time has now come to meet some managers. All of the development managers at G-Research come from a technical background, so they may well ask you a technical question, but this is also a chance to talk about what you’d like to get out of the role, career progression, and generally make sure the job is a good fit for what you’re looking for.
Meet the Team
After all that, we like to give you an opportunity to meet the team that you’d be working with in a more relaxed setting, normally with food and drink. This is a good opportunity to ask any final questions you have in an informal setting.
I’d like to emphasise that the reason we test for many different things, is not because we need everyone to excel at every one of them, but rather because we want to give people as many opportunities as possible to impress us.
We’re much happier with where our interview process is now, but there’s still always work to be done, we continue to review our interview processes, and solicit feedback from both our successful and unsuccessful candidates.
Jack Mills- Software Engineer