Thursday, April 9, 2015

The Compatibility Pattern: Designing adaptive classes

Any non-deprecated system, soon or late, faces challenges. Some of these challenges are quite common. The two following items represent just a fraction of those:
  • existing file storage doesn't satisfy current/coming space requirements
  • the data model need to be modified/extended to comply with new requirements

Today I’m going to describe a design pattern, which can be applied in a variety of situations (including the two above) and eliminate the pain of code re-write.

So, for the sake of simplicity let’s concentrate on a single scenario. Let’s assume we have an existing system – which is operational. Let’s also assume that “EntityA” is an entity in the data model of the system, and the records of that entity are processed by some business logic: “LogicA”.  So far the system used to operate just fine. Now – new requirements come in – which introduce changes to “EntityA” and the “LogicA” as well. Specifically, new “EntityA” records should be treated differently than the “old/current” records. For the sake of simplicity, let’s limit the changes in “EntityA” by just one new field “Field2”. So here what “EntityA” will look like:

image

where “Field1” is an existing field on the entity. Note, that I intentionally don’t mention the types here as its irrelevant in this context.

Also, let’s assume that “LogicA” is already encapsulated in a class with the same name, as follows:

image

Now, back to the new requirements, which affect “LogicA”. The simplest way to handle the change would be to modify the “LogicA.ProcessData” method. However that won’t be maintainable. Think about any future changes – affecting the same logic. After several such changes it’ll be really a mess and it won’t be easy to figure out how to change something  to impact only specific version of entities. So the simplest and design-wise proper solution would be to introduce new LogicA_New handler for the new entities and put the decision logic of instantiating the proper logic in some factory class. The following diagram depicts that case:

image

Note, that the abstraction of the handling logic into separate classes is an implementation of the Strategy design pattern.

This model allows future expansion of the system by just defining a new strategy/logic and updating the factory method, to return the proper handler type. Handling logic deprecation is quite straight forward as well, and can be handled in the reverse order: the factory method is updated to remove the obsolete case and the appropriate logic handler is removed.

Hope this will save you some time in the future.

Wednesday, April 1, 2015

The interview process

Looking back - there were many times I’ve went through an interview process for different software development positions in different companies. To be more precise – there were around 20 interviews I’ve went through. Frankly saying, it doesn’t matter what kind of company you’re interviewing for – 60% of the technical questions will be very similar (of course, there are rare exceptions to this rule). And if you’ve gone through at least 5 interview processes, you probably know what to look for - how to prepare for those questions.

Why ? Because most of those questions you’ll be asked will be just formality and well known mathematical problems. It’s just a matter of filling in a checkbox whether you’ve answered a question or not – and the chances you’d be ever dealing with that kind of problem during your day to day work – are almost 0! To answer these kind of questions you’d need to just have walked over any similar problem in the past. Most of those share very similar solutions.

These 60% are the bad part of the interview process and I call – THE INTERVIEW TAX. Because you have to learn those anyway even if you won’t be dealing with anything close to those questions.

Now, let’s talk about the other 40%. Those divide into three categories:

  • Thinking questions
  • Practice questions
  • Design questions

1. Thinking questions

These may easily be unsolvable mathematical problems as well. And the interviewer is asking you the question and also ask to think loudly. This is important as what he/she wants to observe – is how you think. Or – do you think at all. I know it’s funny, but I’ve seen people just having no ideas on how to solve a problem.

On the other hand, the problem can be really simple as well – very trivial – but the discussion around it will be like building a knowledge graph: you say something, you get another question on what you said, you answer again, and again get a new question – which slowly takes you away from the original topic. These discussions can take hours (luckily the interviewer will have a schedule).

2. Practice questions

The questions here are simple coding questions in your preferred programming language (unless the company has strict requirements about the coding language). In most of the cases – even a pseudo-code will be fine. These questions are aimed to verify your coding skills – like properly handling validation, corner cases. In the end you most probably will be given also a task to write unit-tests for your code. The interviewer may have noticed a mistake in the code, and sometimes want you to catch it – so be careful to do so. If you’ll write a code and the tests you’ll write won’t handle it – that’ll be reflected negatively for you.

3. Design questions

This is my preferred topic. Unfortunately these are quite rare questions during the interview process you get asked. I believe those are the most valuable ones as those will be giving answers on how well you’ll be doing your work – if you’ll be hired.

Anyway – here you may be given some real-world problems – and you’d have to solve it – by describing a system from a high level. The system can be very small or very big – depending on the responsibilities you’re being considered for. But even on the smallest systems (a simple example is an elevator or an alarm clock) some important skills can be seen.

I hope this writing will be a good overview for one who is looking forward for an interview and also for those who host interviews – to improve their existing processes, if they fall in the 60% category.