I recently spent a few months preparing for and interviewing for a new software engineering job. Here are the tips I'd give to someone preparing for a job hunt.

How to use leetcode

  • Start at the beginning, problem 1, and simply work through problems from top to bottom. Actually try to solve the problem by submitting a working solution, don't simply read the problem and then read the answer.
  • Set a short timer when you do a problem, and stop when the timer goes off. Around 25-45 minutes is the amount of time you'll get to solve these problems in interviews. This way you'll get used to coding something in this interval of time. If you don't solve the problem, simply read the solution, code it up and move on.
  • Use your best language. I did 100+ leetcode problems in Python to try to learn Python but I performed much better in interviews using my best language, Ruby.
  • Pay for the premium version of leetcode so you can read the paywalled solutions. Also, get a copy of Elements of Programming Interviews in Python, the solutions in this book are the best I've seen.
  • Don't spend a lot of time studying "hard" problems, esoteric data structures, or clever solutions that only apply to one problem.
  • Learning leetcode is about recognizing the big themes (read and write times to common data structures, a few techniques like dynamic programming and backtracking) and developing quick muscle memory.
  • Some of my favorites: the N-Queens problem, the Sudoku solver, building an LRU cache.

How to use coderpad

  • Anyone can use this for free, so load it up before your interviews start and try it out.
  • Almost all remote tech screens will happen in coderpad. Learn to use this software, it has a few helpful features. For Ruby it has the pry gem, Rspec, and pressing Control+Enter runs your code.
  • After your program runs, the binding (including your variables) are still active in the REPL in the right-hand column.

Ruby on Rails questions

I actually ended up solving very few leetcode-style problems during these interviews. Virtually every technical question that involved me typing code was about my everyday Ruby on Rails skills. I was asked to write a Rails app from scratch, write Rspecs for an untested Ruby program, refactor a Ruby program, and other things that I do every day at work.

There's no need to prepare for these questions, since they're the skills you use every day.

Remote tech screens

The first five minutes are critical because you need to find out what the interviewer wants you to do. Try to ask questions and find the criteria so you know how you're being measured.

  • You might be judged on simply writing a fast, working solution, as the leetcode solver does.
  • Some interviewers want you to write tests, some will tell you to stop if you start writing a test.
  • Some interviewers want you to create classes.
  • Sometimes the interviewer "hides the ball" and will only say things like, "just code what comes naturally," or "I just want to see how you think," without test cases or revealing their criteria.

Before writing code, tell the interviewer what you're about to do, because they might tell you not to bother with that idea. Also, you should explain the naive or obvious, inefficient solution to the problem. Sometimes the interviewer will ask you to code that up, and it turns out there isn't a second, more clever solution, the naive, slow solution is the right answer! Keep in mind during a tech interview that you don't know if you're passing or failing.

Odd fact: I used Array#combination twice and both times it was the crux of a problem. Learn this method!

Taking about coding

These interviews are a conversation with an engineer about your work experience. Before you start interviewing, read through your recent PR's and practice telling the story of them to a fellow engineer who doesn't know your company's internal abbreviations and lingo.

Stay positive--don't criticize your current employer or colleagues. It looks bad and is time wasted you could spend showing off your knowledge.

What you're going to do is have a few anecdotes ready, that are useful as answers to various questions. For example, one of my stories was about a massive effort to upgrade a gem. I used this story to answer questions about both "leadership", and "a technical challenge I overcame." I had another story ready for "working with a difficult colleague."

  • One of my stories was about writing a rails middleware, which allowed me to talk about how rails and rack fit together, puma (and other web servers), API's, and dealing with external dependencies.
  • Another was about using Docker to run platform services locally for development.
  • I talked about a recent PR review comment I wrote speeding up an integration test that runs in the browser, which allowed me to talk about dealing with race conditions with capybara. I put specific numbers to this story: I sped up a scenario from running in 90 seconds to 23.
  • I also talked about a page load time I reduce by removing an N+1 query which resulted in an 8% speedup. Try to have some specific numbers available.

For all of these stories I was ready to go deep into technical details if my interviewer asked more specific questions.

Only one interviewer was interested in my side project, in the end the only experience that really mattered was code I had running in production for my job.

Asking questions

In every interview you'll get a chance to ask questions. Be prepared for this by reflecting on what is important to you. For me, I decided I wanted to work somewhere with

  • strong engineering practices like testing, design, and a sensible deploy process.
  • transparency, including how the business is doing
  • a history of internal promotions as opposed to always putting new hires in senior and leadership roles
  • mentorship and growth

My go-to question for technical interviewers was to ask about a typical deploy. This question is both easy to ad-lib an answer to and very revealing about internal processes.

During the initial phone screen with a company, it's ok to make sure both sides are in agreement about the positions on things like the job title and salary range for the open position you're interviewing for.

Nuts and bolts

Find a great recruiter! Take notes when you talk to your recruiters, I learned a lot from them, and found opportunities I didn't know existed.

Make a Trello board tracking status ("tech screen upcoming", "tech screen completed", "onsite upcoming", "offer", etc.). During this process I had some form of interest from 12 companies, it's impossible to remember where you are with all of them. And sometimes you'll need to follow up with companies to nudge the process along.

All companies who rejected me just ghosted me, I never got a rejection notice after an interview.

Take notes during the calls. It is impossible to remember this much information all at once, and if you make it further in the process with a company you'll become more interested in that information.

Use a headset for phone calls.

I didn't do this, but if I did it again I'd make a public calendar where people could schedule blocks of time with me.

Be ready to explain why you're looking for a job.

Overall, this process took five solid weeks from sending out feelers to signing an offer letter I was thrilled with. I talked to 12 companies, met a ton of new people and made some connections I expect to last a long time, even at companies besides the one I signed with.