Sample interview question

Ten months ago we decided to do something pretty bold: we made our interview open book! You can read about our thoughts and motivation in the original blog post.

We’ve had an overwhelmingly positive response to this idea as well as a significant increase in the number of people applying and interviewing with us. We’ve also had a fair number of candidates who withdrew from the process after going through the questions, either permanently or temporarily so as to take some time to prepare.

However, despite the increase in interviewing stats, the ratio of interviews/hires stayed flat. More than that, we noticed an even greater discrepancy between knowledgeable candidates and those whose interview ends early, than before we had made the interview open book. This seemed very counterintuitive to us, as we expected that by having access to ALL interview questions (and we do really only ask those listed on the blog) and also by having described IN DETAIL what we expect and how the interview goes (it’s a discussion, not a Q&A session, we’re interested in how people think, not necessarily what they know), none of the interviews would end early and we could have meaningful discussions on technical topics with the candidates.

Alas, most of the time, this is not the case. So, after racking our brains for some time, we came to the conclusion that it might be a case of “it’s not you, it’s me”, i.e. we haven’t been clear enough in what we expect from the interview and how the discussion goes. To rectify this, this blog post attempts to describe a conversation based on (what usually is) the first question we ask and how candidates answer wrongly, as well as what would be the right way to answer.

Please read it through, play it out in your head, and then decide for yourself if this is a conversation you’d like to have and a company you’d like to have it with (and hopefully work for).

The conversation

Takes place between the interviewer I and the candidate C. There is also a N(arrator) which comments on things in the background in a…well, narrator voice :)

The exchange below might happen in the precise sequence depicted or you can also imagine some lines might be skipped. In general however, it is how it goes in a “fail” case.

I: can you please describe how you would implement the Observer pattern? What classes (and maybe interfaces) are involved, what methods/functions do they have, how do they communicate with each other? Also, are there any things that could go wrong that you should be aware of and prevent?

C: The Observer design pattern is a behavioral design pattern that allows a Subject to send a message to multiple interested parties. The parties, observers, can do some work then the Subject notifies them.

N: While technically correct, this answer has completely missed the point of the question. We are pragmatists and we don’t want nor expect definitions. Moreover, the candidate didn’t pay attention to the question: it asks specifically for code, classes, methods, communication. The answer generally described the pattern while not answering the question in the least.

I: You have correctly described the pattern, however the question was very specific about the implementation. Can you describe, in code, how YOU would implement it.

C: Ok so I would have an Observable and an Observer. Then the Observer would get added to the Observable. Moreover, the Observable would have a Notify method which would notify all of the added Observers.

N: Again technically correct, again no code, just a generic explanation.

I: Ok, so concretely, what classes would you write, what methods, how do they call each other?

C: So there is an Observable class and an Observer class. The Observable class has an Add method and a Remove method and internally adds/removes Observers from an internal list. Then it also has a Notify method which when called iterates through the Observers and notifies them something has happened.

N: Ok, some improvement here, but far from clear. There is no mention of what methods the Observer class has, what parameters they take (maybe some payload specific to the type of notification?), who and when calls Observable.Add and Observable.Remove. Also, there is no mention of interfaces. Finally, there is no mention about multiple event/notification types.

I: Ok so when the Observable iterates through the list and notifies the Observers, is there anything you should take care of or be aware of?

C: Well, there could be double notifications, for example if an Observer is registered twice.

N: Again, technically correct, but this is not a concern of the Observable. If someone registered an Observer twice, it is their problem, not the Observable’s to solve. To make an analogy, if you subscribe to a newspaper twice, it’s not the newspaper’s responsibility to make you aware or even just detect it and send you only one newspaper per month. Truth is, they don’t know: you might really WANT two newspapers (maybe you’re giving one to your grandparents who can’t manage a subscription themselves).

I: What happens though if one of the Observers, say the 5th in the list, fails, has an error?

C: Ah, in that case we could implement a try/catch block so that this one Observer failing doesn’t prevent the others from being notified.

N: Good answer…but incomplete. A better answer would come also with some error handling policy. For example, if you’re implementing a generic observer pattern, your Observable might want to expose a way for the user to actually find out that something went wrong, what exactly went wrong and with which subscriber. More than that, your Observable might let the user decide what to do: keep notifying, stop or take some other action. Reactive Extensions is a good example here.

I: Ok, that’s good. Is there anything else that could go wrong here? For example, what if one Observer blocks, never returns from the notify call?

C: We could implement a timeout and if it doesn’t return in N seconds, we move on.

N: Again, good idea, but we’re looking for CONCRETE implementations or at least the mechanism of how to do it. In this particular case, the mechanism even depends on the framework and/or programming language we’re in. The general approach is to “notify asynchronously” so that you can still react after a while and detect a timeout, but the mechanics of how to implement this in practice differ greatly (or might even not be possible at all!) depending on the tools you use. Also, once we go down the “async” way, there is a host of other issues to account for and ideally there would be a discussion around those or at least a hint the candidate knows they can occur and we need to think about them.

I: Ok so now that we have a working Observer in a local, in-process scenario, how would you implement this in a distributed app? Suppose you have a service that’s your Observable and a number of other services that are interested in events this Observable might publish. How do they subscribe/unsubscribe, how does the publishing work etc?

N: Here we’d expect a discussion about not only the concrete interfaces of the services, but also about common pitfalls in distributed/cloud computing and how one could solve them: reliable messaging (what if an Observer service is down when the Observable tries to notify it?), duplicate messages (how to detect?), out of order delivery (in case of multiple event types that need to be sequenced) etc

I: Finally, what are some potential disadvantages to using this pattern and what could you to do mediate them?

N: Here we’d expect the candidate to mention increased complexity, harder to trace code execution or message delivery as well as potential memory or information leaks. As far as techniques to deal with these issues, the candidate could mention documentation, (distributed) tracing and application profiling.

Conclusion

As you can see, a fairly “innocent” question about what is probably the most widely known and used design pattern (after Singleton :]) can evolve into a fairly complex discussion. I hope it’s also clear that the discussion is not academic or theoretical. It touches on real-life issues that we (could) run into every day. It brings up topics an engineer should think about, such as design choices, failure scenarios and choosing the right technologies or frameworks for the needs at hand.

This question exemplifies how our interview discussion goes. Again, we don’t ask for definitions and we don’t ask “API questions”. We’re interested in principles as well as how to (very) concretely implement them in practice. Ideally, the candidate should know the answers and be able to have a conversation on the topic. Failing that, we will still be very happy if the candidate can deduce the answer, with help from our side of course. In both cases though, we want clear, concise and pragmatic answers and approaches. Basically: we want the problem thought out and solved (ideally in more ways than one). This is, after all, what the job is about.

Links:

Written by:
Adi.jpg
Adrian Hara

Managing partner and geek wannabe