Engineering interviews at Increase

Let's face it: engineering interviews are far from perfect, often diverge from what we do on a daily basis, and provide lossy signal for how well someone will perform in a role.

In a parallel universe, both the candidate and interviewers would spend ample time together building something of significance and working through everyday challenges in order to gauge mutual fit.

We put this guide together to help relieve the anxiety of interviewing and help you best prepare for what’s ahead. We’d love to hear your feedback!

Coding interviews

Coding interviews are hard!

  • They exercise muscles that many engineers, especially senior engineers, often haven’t used in some time.
  • The format of coding interviews can be stressful (think of how many more typos you make writing code when someone is looking over your shoulder).
  • Coding interviews often involve writing code in a style you don’t write day-to-day (when’s the last time you implemented even an extremely basic algorithm at work, or code that had no dependencies on anything else?)

During your interview at Increase, you can expect 2+ interviews where you spend ~all of the session writing code. We strive to make these questions resemble real work problems - you don’t need to implement a breadth-first search or a priority queue. You shouldn’t need to run out and buy an algorithms textbook. That said, a little preparation can go a long way. Here are a few tips to prepare:

  • Pick the language you’re going to work in up front. None of our problems are so specialized that it makes sense to pick a specific tool on the fly.
    • If you self-identify as a frontend engineer, this language should probably be JavaScript or something that compiles to it.
    • If you’re on the fence about what to use, we recommend a dynamically-typed, interpreted language like Python, Ruby, or JavaScript. Fundamentally a lot of coding interviews (at Increase and elsewhere) involve reading in some data and transforming it into some other shape (often a hashmap/dictionary - the programming interview’s best friend). When you’re still iterating on what that shape/transformation looks like, the static type systems in languages like Java, C++, and Go often get in your way and burn a lot of time and focus. We’ve observed lower pass rates on coding interviews in those languages for that reason. But if one of those languages is what you think and dream in, use it!
    • If you’re using the same language you use at your current job, make sure you’re not overly-reliant on internal libraries and tools. For example, writing C++ at Google is not like writing C++ outside of Google.
  • Spend an hour or two typing simple code in the language you’re going to use. This doesn’t have to be solving super hard LeetCode algorithms; it’s more about warming up your “thought to code compiler” so that you’re not forgetting basic syntax/how to use the standard library while in a stressful interview setting. Start by aiming for volume of code, and then take some time at the end to see how clean you can make it.
    • Some basic things you could do as a warmup:
      • Open a file, break it up into words, and replace each word in the file with how many characters are in the word.
      • Print how many seconds it has been since your last birthday.
    • Previous years of the annual Advent of Code programming challenge are great for this. There’s a nice ramp-up in difficulty and the problems are fun. https://adventofcode.com/2022/events
  • Show up to your interview with a file open that lets you print “hello world” in your language of choice, and make sure you can run it. If you’re comfortable sharing your screen during your interview, we encourage you to use your local environment. Otherwise collaborative online editors like https://repl.it are great for this.
  • During your interview, tests are your friend. It can be really useful to write a few simple tests before you start working on your solution, as this lets you clarify your understanding of the problem, notice edge cases, and take a second to think about what your solution will look like before diving in.
    • In an interview setting, you don’t need to pull in a unit testing framework - printing “success!” is great! But if it makes you more comfortable, feel free to set up a simple test suite ahead of time.

API integration interviews

We spend a lot of time integrating with external APIs and manipulating response data based on business logic. For this interview, that’s exactly what you’ll be doing! Here, you’ll build a small application locally that makes HTTP requests to an external system and manipulates response data. It’s useful to make sure you’re able to make successful network calls (GET/POST) in your preferred language and environment. Practice paginating through lists, handling network failures, and traversing response objects.

To warm up, you can:

Project review interviews

Project review interviews are a great way to showcase the amazing work you’ve already done and highlight a project you’re proud of. It’s of course worth noting that you should avoid any proprietary or non-public information.

Project review interviews are fairly open ended and can go in a number of directions. It’s great to pick a project where you have reasonable breadth and depth over the problem and solution space. You, of course, don’t have to be an expert, but you should be able to reasonably discuss the project for an hour. If you’re having trouble recalling a worthwhile project, here are a few questions to spark your memory:

  • What’s a project where you learned a lot about a system or domain?
  • What’s a project where you or your team overcame a challenge you initially thought was impossible?
  • What’s a project that required a non-trivial technical design?
  • What’s a project where you had a “lightbulb” moment?

It’s daunting to recap a large project, especially if you worked on it years ago. Spend a few minutes before your interview jogging your memory by writing down key moments in the project and things you want to make sure you hit in your interview. Diagrams can help too, but are often not necessary to communicate details of a project. To add structure here and help with recall, it can help to cover things like:

  • Why was this project initiated? What were the business goals and expected outcomes?
  • What made this problem challenging to solve?
  • How did you approach the problem?
  • What was the largest technical challenge or decision made?
  • What limited your design, if anything?
  • What alternative solutions were considered? How did you weigh trade offs?
  • What would you have done differently if you could go back?

System design interviews

Before you jump into this interview, make sure you’re comfortable with the tools you’ll be using. While there’s no substitute for in person whiteboarding with someone, we tend to use Whimsical, but you should pick the tool you know. Make sure you’re comfortable drawing boxes and arrows - you’ll be doing a lot of that during this interview!

The hardest part of this interview is getting started because of how open ended it feels.

A great way to navigate the problem is to first lay out all the sub-problems to solve up front. Take the notorious system design question of “what happens when you press Enter in a Google search bar?“. You could just dive right into the details: the keyboard actuator in the switch of your Enter key closes, completing a circuit that signals to the chip on your keyboard that a particular keycode should be transmitted to the ‘network’ layer of your keyboard, which could be Bluetooth, etc. You could spend the full interview just talking about the keyboard and its interface to your computer and never get to meatier parts of the system, such as Internet Service Provider routing, the Border Gateway Protocol (BGP), reverse proxies at the data center, load balancing, etc. While this question is overly networking heavy, it’s a good example of how you should first lay out the high level components at the start of the interview. From there, you can choose to dive into one component at a time, or ask the interviewer where they’d like to start.

Here are a few questions to get started:

  • How does this system reliably and scalably receive a request?
  • How does the request make its way to your application code?
  • What kind of data store would be useful (if any)?
  • What guarantees would you want from your data store?
  • What is the schema of your data?

At its core, this interview dives into building an application that users can interact with over the Internet in a safe, scalable, and reliable way. It’s helpful to think through previous systems you’ve built and the infrastructure they relied on.

Lastly, assuming we’re in a cloud based environment, it’s useful to think through modes of system failure and how they make their way into application code. For example, what happens when a web server stops responding?

Increase is not a bank. Banking products and services are offered by Grasshopper Bank, N.A., Member FDIC, First Internet Bank of Indiana, Member FDIC, and Core Bank, Member FDIC. Cards Issued by First Internet Bank of Indiana, pursuant to a license from Visa Inc. Deposits are insured by the FDIC up to the maximum allowed by law through Grasshopper Bank, N.A., Member FDIC, First Internet Bank of Indiana, Member FDIC, and Core Bank, Member FDIC. FDIC deposit insurance only covers the failure of the FDIC insured bank.