How We Interview

We have a team over 25 iOS developers at the moment. Despite this is a pretty large number we're still looking for more people to come. In short, that means three things:

  • We've got a lot of interviews every week
  • Many collegues want to take part in this process and sharpen their interviewing skills
  • You can apply too - our team and projects are really cool!

Till the last time this process was pretty chaotic. We didn't clearly understand what to ask, how to process the results and how to compare different candidates for one role. So I spent some time on researching and organizing it with a great help from my collegues - and we developed a noticable system.

Divide et Impera

This is just another story inspired by problems encountered in Rambler.Mail application. Our AppDelegate was really huge. And that wasn't great at all.

Spotlight, Handoff, state restoration, push notifications - all of this technologies require specific logic. Apple provided us with the only visible solution - AppDelegate class. And we put these methods in it. Besides system callbacks, this class seems like a nice container for other things as well - CoreData setup, analytics integration, checking different permissions and showing onboarding screens. At the end AppDelegate becomes a real mess, which is hard to read and understand.

The Story of One Unit Test

What makes a clean test? Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code. What makes tests readable? The same thing that makes all code readable: clarity, simplicity, and density of expression. In a test you want to say a lot with as few expressions as possible.

Robert Martin, Clean Code

It's very easy to turn your unit tests into an unreadable and unmaintainable mess. The main reason of such attitude is a wrong understanding of test cases role. It's not "write once, never read". It's not just in verifying your methods behaviour. Unit tests are all about documentation. It's "write once, refactor often, consult daily". The easier a test is, the more it tells to a developer.

Promises and Ads

A promise is a really simple and easy to understand pattern. In general, it's just an object that represents a result of some action which is not finished yet. That's all, nothing more.

This simple concept reduces a complexity of asynchronous code a lot. Imagine that you don't have to write these awful nested completion blocks - every operation is synchronous. You just ask your service to return data - and it returns you something to work with.

Using UIWebView with VIPER

I was working on Rambler.Mail project for the whole year. It's a client for one of the most popular Russian e-mail providers. The application itself is rather ordinary, it has the very same features you'd expect from an e-mail application - and nothing more. However, I spent a lot of time building a solid and maintainable architecture for both business logic and presentation layers.

One of the most interesting features was a rendering engine for displaying e-mail content. I won't dive into implementation details - all you need to know at the moment is that we used UIWebView and WebViewJavascriptBridge - a great library for bridging native code and javascript. The result system was monlithic, difficult to understand and reason about - undoubtedly not the best piece of software I've ever built.

Before I had a chance to refactor it I was switched to another project. To my great surprise I've encountered there a very similar task - I had to build a rendering engine for displaying blog posts. This time I was prepared well - I already knew how NOT to build such systems. So, instead of spaghetti code, I've used another approach - the cell containing UIWebView was built using the VIPER architecture.