Back when I was a physics student, I came to the realization that I enjoyed building things more than I enjoyed spending time in the lab, which is what led me to programming. So during my job search, I started looking for companies that would allow me to use both of the skill sets I’d built up — math and programming. Spoiler alert: that led me to financial companies. And over the years, I’ve learned a lot more about what makes an ideal candidate in a coding job interview.
Before becoming CTO at Climb, I joined the team as a senior engineer. During that transition, I was fortunate to be surrounded by lots of people who were great at what they did, and because of that I was able to build a mental model of what a successful hire would look like. Below, I’ve put together a run-down of the problem-solving approaches I look for in candidates aspiring to join a software engineering team, as well as some ways to showcase your skills if you had a non-traditional software education (such as a coding bootcamp).
Problem solving in an interview
Being interviewed can often be daunting, so here are some approaches that could help you showcase yourself at your best.
Thinks in terms of systems, not just code
The code itself is just one piece of a bigger picture. Software engineering is like writing one chapter of a book, while other people are writing other chapters — and also the story is always changing. An ideal candidate focuses not just on writing the code but also how it fits into systems as a whole.
Writes code that's readable
The goal of your code should be to represent the way you look at a problem. There are a number of clean coding principles (DRY, SOLID, etc.) that you can use to think about your code, but the end goal should be to write something that helps someone else (or future you) understand your approach to the problem. Between a simple solution and a clever solution, simple is always better.
Spots issues quickly
At Climb, we often do a “code review” section of the interview. The goal is to understand how you can spot issues in the program. Things move quickly in tech — and when you have users visiting your site at every time of day, it’s important to catch problems quickly. That way, issues can be resolved as soon as possible, and our visitors can have a seamless experience.
Asks questions about security
This is specific to fintech, but if you’ve checked the news at any point over the last few years, you’ve heard about one of the many data breaches that have occurred. Protecting the personal information of our users is paramount (especially as a finance company), so I want to be sure a candidate takes security as seriously as we do. Often, I look for candidates to ask questions about this or will prompt them to do so. For an entry-level candidate, the goal is not to test for rote knowledge of security best practices, but to understand how to incorporate security as a constraint into your problem-solving process.
Can discuss trade-offs
At the end of the day, it’s about determining what’s most efficient. Sometimes, you have to find the right balance and make some tradeoffs to get to the best solution. I look for someone who’s able to figure out when to make tradeoffs between cleanliness, readability, and speed to create the most efficient code.
Understands business motivation
Climb is a mission-driven company. If a candidate doesn’t seem to get why we all come into work every day — to help increase access to career-advancing programs — chances are their work as an employee would reflect that. I want to know candidates are just as passionate about the company mission as we are.
Knows when to optimize (and when not to)
Sometimes you’ve just got to set priorities. Most academic programs (traditional or not) typically teach candidates the best way to solve a problem from a technical perspective. However, when building solutions within an existing system, often the question is not about finding one right solution but the solution that best covers trade-offs in speed, time to delivery, robustness, and feature compatibility. This is a gap that can be challenging to a candidate. To develop an approach to this, ask yourself: “How much time would I spend on this bug if it happened once/day, once/month, or once/year?“ Another way to solve for this gap is to give yourself a project to complete in two days — you will inevitably run into some decisions that you’ll need to address in the quickest way possible, and others in the best way possible. Knowing when you should focus on optimization and when you should let it be is crucial for overall productivity and helps a team run smoothly. Otherwise, you’ll get bogged down trying to do everything at once.
Demonstrates a practical approach to testing
One of our goals at Climb is to be always testing and experimenting in order to improve our product. At any company, the level of testing within a codebase can vary quite a lot, and no codebase is perfect, so every team wants candidates that can make their code better simply by their approach. If a candidate shows that they can run tests, that’s ok. If they demonstrate an ability to plan tests themselves, that’s good. What’s great, though, is being able to find a balance and differentiate between under-testing vs. over-testing.
Has the ability to adapt
Recognizes and validates assumptions
All problem-solving exercises contain assumptions, and often those assumptions don’t fully match up to reality. What’s key in coming across as a great candidate is being able to recognize your assumptions whenever you solve questions in an interview, and then take the next steps to be sure those assumptions are valid ones. Spoiler alert — this is a big part of the job, so showing that you approach problems this way goes far in making a good impression.
Technical skills aren’t the only factors important to the make-up of an ideal candidate.
A large part of your day is communicating and working with the team, so hiring managers also look at a number of soft skills as well, including:
- The ability to discuss multiple approaches
- Being able to clearly explain work
- Ability (and willingness) to dive into unfamiliar territory
- Collaboration and ability speak to collaboration
- A willingness to teach
- Curiosity, eagerness to learn, and willingness to ask questions
- A calm demeanor (we really value people being chill)
- A desire to help level up the team
Typically, a team looking for a new member is trying to answer a few simple questions:
- Can this person do the job?
- Can we work together with this person? (You spend most of your waking hours at your job.)
- Would we, as a team, be better with this person?
(Also note that you as a candidate are interviewing the team as much as they are interviewing you, so you should seek to answer those questions for yourself, as well.)
Finding a job after a coding bootcamp
If you have a traditional engineering resume, there’s a (somewhat) known path to get into a job. But for those who are hiring, the talent pool out there is actually much wider than it seems. We’re fortunate to be in a domain that doesn’t have a huge barrier to entry in gaining the skills I outlined above — all it takes is time and practice. There’s a large world out there, and it’s full of people who don’t have a traditional CS degree but could be excellent software engineers. The challenge comes in finding the right people.
If you’re coming out of a bootcamp or are not a “traditional” CS engineer, the biggest piece of advice I would give is to find a way to show off your work. Big things, small things, a weekend project — anything that will showcase your skills. Spin up a website, throw in your GitHub profile, add a couple of paragraphs on why you built what you built, and you’re already well ahead of the curve.
Then, when you present, talk about the impact (or the “why”) of what you built, instead of focusing on the “how.” The questions I’m trying to answer in an interview are: “Does this person add to our team? Do they bring something new or interesting to the table? Can they level up the team?” Do your best to show the interviewer that the answers to those questions are all “yes.”
Lastly, do not be afraid of using the cold email. Some of the best candidates I’ve ever hired have been people reaching out to speak about what’s next in their career. This doesn’t mean you should spam every person you know. Instead, think about sending the CTO of a company you like a well-worded, 3-sentence cold email that outlines:
Who you are
Why you like their product and a way you’d love to help improve it
What your ask is (internship, open roles, etc.)
There are plenty of great examples on how to leverage cold emails here.
When showcasing your work, especially for your first job, you’ll want to make sure whatever you build is (a) in a domain, language, or framework that is broadly used and (b) that you can speak about it in depth when you bring it up in a conversation — it’s your project, so I have no doubt you’ll be able to do so.
Lastly, one of the challenges in interviewing as a bootcamp candidate is that the traditional entry-level software engineering interview process is designed after the Google interview process, and this is optimized for a very specific kind of candidate: someone who just graduated from a 4-year CS degree. The questions are often posed in language and jargon that a CS major may recall because it’s fresh in their memory, and often create a barrier to non-traditional candidates. However, because interview processes are often designed as copies of the Google process, it’s entirely possible to bridge that gap with a little bit of preparation and reading — this article covers some good preparatory books that will help you cross that gap.
Finally, I wish you all the very best in your job search! It’s not always easy finding that first job, but I hope that these approaches help you showcase your talent. None of us got to where we are without other people helping us, so if you need any help figuring out an approach or connecting with someone, I’m here to help — feel free to reach out to me at firstname.lastname@example.org or on twitter at @arj_shiv!