How to interview for remote software development positions

I put up a post about how to go about getting a remote software development job and it seemed to get a bit of attention on reddit. One of the questions I received on the reddit post was the details of the technical interview portion I went through. I figured I would write about that in detail here.

So far, I’ve had five interviews for remote software development jobs, three of which I passed, one that I didn’t pass, and one that I never attempted because I didn’t feel like doing the take-home coding challenge that they presented me with. So out of the ones I’ve attempted, I passed 3 out of 4, and interestingly enough, all of those interviews, including the one I didn’t pass, were pretty similar in structure.

All of the four interviews seemed to follow this “code review” format where you get on the phone or Google Hangouts and either go over some code together or just have a friendly conversation about programming in general. There weren’t really any specific interview questions to prepare for. In fact, none of these interviews were interviews you could prepare for by studying books like the classic “Cracking the Coding Interview” or reviewing your CS fundamentals. You either have a firm grasp on the common topics of software development (which you should if you have previous work experience) or you don’t.

Generally during these “code review” interviews, I was to supply the code that we would go over. The interviews were language agnostic, but I tended to pick Ruby on Rails codebases as the companies I were interviewing for were Rails shops, thus I thought a Rails codebase would be the most relevant for the job. But I’ve had coworkers who interviewed with other random programming languages like Clojure and still pass the interview. Finally, the interviews didn’t feel like interviews at all, but a pleasant conversation about code with another fellow developer(s), just like the ones you probably have on a regular basis with your coworkers.

For example, during one of the interviews, one thing I was asked was about an ActiveRecord method that I wrote that neither of us knew whether it touched the database or not. So we fired up the rails console, ran the method directly in the console to see whether it made any SQL queries. So that wasn’t even an “interview question” per se. It was just us talking about how we should avoid making database queries when possible as they can be expensive.

We also talked about general scaling things, like caching, throttling spammy ips in the middleware, and etc. So yes, none of these interviews really felt like your traditional programming interviews at all. They felt more like a conversation that I would normally have with my coworkers. Although, I can see how it would feel like these are difficult technical interviews if you don’t have a firm grasp on these topics, but most developers with a few years of experience should be familiar with these topics to talk about them with confidence.

Sometimes, we talked about more specific topics about the tech stack I was interviewing for. For example, when I was interviewing to be accepted as an Android developer for Gigster, one of the questions I was asked was that if I knew the difference between RecyclerView and a ListView, which we talked about, and then we went on a tangent about how I thought Java is super verbose and how Kotlin seemed a lot prettier and elegant. Again, this interview too felt more like a friendly conversation with a fellow developer.

Overall, I think if you know your stuff, and have a few years of professional experience under your belt working on real live production applications, these interviews shouldn’t feel like interviews at all, but more like a friendly tech-conversation with other developers.

About the Author Chris Jeon

Software developer currently focusing on Android development.