четверг, 16 февраля 2017 г.

Search Algortihms in the Real World

In the middle of my university life I had a very strong desire to build a computer game. I was studying for a software engineer and still understood little about most of the software applications. At the same time I loved PC games, which clearly brought me to the idea that I should produce one - the one with the best gameplay, of course. Many of the guys with the same background had that wish and like most of them I didn't succeed.

I spent a fair portion of my free time thinking over the game's design, writing the explanations in a textbook and studying computer graphics. The problem is that in these activities I focused on the things that were easier to comprehend for me. I liked to think through game mechanics - for example the way damage is dealt to the player. I worked this question out on a very detailed level - in many cases descending to the names of C++ classes and of course laying out the calculation rules. With graphics, I focused on trying to make primitives move around the screen using OpenGL, because moving stuff looked like an essential part of game development. This all happened where neither setting, nor even key game features were defined - I hardly settled with the genre. Instead of looking at these high-level concepts of the game, I grasped the details, which I could easily stick into my head, without even understanding what are the key building blocks that I will have to construct a video game from. Speaking in algorithms language, I was doing a depth-first search not wishing too see the entire tree that I will have to traverse eventually.

Recent observations at interviews and during the normal work process brought me to the idea that such a mistake is common among many younger developers. When put in front of an unfamiliar problem they tend to catch some detail that they understand and pursue it to the deep. Because they don't take time to step back and take a look at the problem as a whole, they may end up with weak solutions suffering from various illnesses that happen in the software world. Most likely you will see multiple leaky abstractions and dozens of lines of ad-hoc code in the programs produced this way. And of course don't be too optimistic about finding there clearly separated layers, constituted of the objects that comply with Single-Responsibility Principle.

After acquiring reasonable development experience we tend to replace the depth-first strategy with the breadth-first search. This happens not only because older developers are slower beasts, but more due to the acknowledgement of importance of the full context for the correct solution to the problem. The mistakes committed earlier make us approach both high- and low-level decisions with great respect to the surroundings and see the drawbacks of diving into details before thinking of the solution as a whole.

This obviously makes a lot of sense when we speak of software design and architecture definition, but actually the same breadth-first strategy is applicable to such activities as coding and bugfixing. For example, when analyzing a bug it is tempting to follow the first breadcrumbs seen in the data in an attempt to understand the issue, but this way one may end ep trying every possible hint and spend hours exploring dead-ends. Alternatively, one may take time to fully understand the context of the issue, appreciate its complexity and collect as many facts as possible before even trying to make assumptions regarding the cause of the problem. In this case he will be able to see clearly which guesses are worth a deep investigation and which can be ignored altogether.

There is a similar situation with, for example, writing blog entries. For some people it is natural to produce a good article  simply by letting their thoughts flow onto paper. For others producing a reasonable piece of writing requires planning it and doing a couple drafts first. I don't belong to the first kind and going the depth-first way always results in frustration and wasting lots of my time on a couple short paragraphs. To be honest, sometimes its very hard for me even to produce the first draft from the start to the end - details kill me on the way. Instead, I begin with a rough outline consisting of several key points, then gradually add several sub-points to each of them. Only after this two-tier plan is there, I would start expanding the sub-points to rough sentences, which make a foundation for the draft. This looks very much like traversing the tree of the future blog post with the breadth-first search algorithm, except for the fact that here nodes and leafs are themselves created by the search process.

While I have enough development and writing experience to understand these things, sometimes I still find myself using the details-first approach where breadth-first search is more appropriate. To some extent, this happens because there is always eagerness to produce results and the depth-first path always seems short and clear - until you start going. But at the same time, it may be the case that in absence of the right words to distinguish the two strategies nothing forced me to make a conscious choice - the analogy with the search algorithms came to me only recently. In addition to making the choice clearly visible, it also brings the criteria for picking one of the two approaches. When you need to devise a good solution or just to understand a large and potentially complex problem, breadth-first search will work better - the theory says it guarantees the best result possible. If, however, you need the result early and don't care about its quality too much - for example when building a quick prototype to get an idea of the look and feel of a future product - you'd better use the depth-first search, as it usually yields faster. Sounds obvious, but somehow just having this analogy with the algorithms world in mind seems to make the task of selecting the right approach to any problem easier.

понедельник, 16 января 2017 г.

My 2016 Management Reads

It's the middle of January, so everybody must have already published their version of summary for 2016. I will try to catch this leaving train and list several of the books that I read last year and found particularly useful for everyone whose job involves management. There are actually only two items that are directly related to management, but I still believe that all of these books are particularly useful - sometimes even essential - specifically for those of us, who hold responsibility for guiding others and tackling a wide range of organizational problems. At the same time, all five titles will likely be interesting to any human, no matter what they do for a living.

Dale Carnegie - How to Win Friends and Influence People

This widely known piece of wisdom is among the most precious jewels which I found last year. The stakes are high you read it long ago - I'm unhappy I got to it this late. Even if you did, it may be a good idea to refresh it in your mind. Speaking on the way one should treat people to build lasting and fruitful relationships, the book is crucial to study for anyone, whose job is to lead people, communicate the goals of an organization to them, help them acknowledge their mistakes and grow professionally. The things that I learnt from it helped me provide clearer feedback to the members of my team, understand better what my bosses want from us, explain to the team our objectives and overall build trust-based relationships with the people I work with. To be honest, when I first heard about the book I thought it must be a box of dirty tricks that allow one make others do what they please. In reality it turned out to be a pretty sincere practical study of the principle "treat other people the way you want to be treated" and its implications, touching on many strings of the complex nature of human's ego.

David Allen - Getting Things Done

While it's difficult for a book to compete in value with How to Win Friends and Influence People, David Allen's guide to personal efficiency certainly manages to do so. My regrets about reaching it only in 2016 were even stronger than with Carnegie. The book doesn't touch a lot on the topics of managing people and business, but rather dives deeply into the problems of managing oneself. However, personal efficiency of a manager is a key to the efficiency of his team. The fact that the book not only gives advice on how to get productive, but also inspects many psychological questions around succeeding at one's job makes it a must read for every manager in the world because this way it shows how you can teach your directs to succede. Besides that, the key focus of Getting Things Done is the way one manages information, ensures that progress is made on every active goal and validates the goals themselves. This sounds a lot like the responsibilities of a software development manager, so it will be educating for everyone holding such a position. If you feel almost sold, check this article where I sum up my takeaways from the book.

Nassim Nicholas Taleb - Antifragile

The next book could win the "Most Controversial Reading" award if I made a kind of Oscar for the things I read. The Taleb's style of writing as well as his intense reproaches toward certain broad categories of people and fields of study sometimes bothered me a lot. On top of that, the book is not concerned with management in any particular way. At the same time, the ideas given in Antifragile have a lot to do with change and risks and how we can live with it - the topic that is very relevant for managers. Taleb speaks a lot about the ways one should chose what to invest in and how to secure yourself from unnecessary risks. Most of his ideas are applicable to any area of life, including software management where one frequently faces the need to chose from a wide range of technologies, projects and potential employees. Even if it is difficult to perceive the book as purely practical and career-boosting it is certainly educating and offers fresh points of view.

Cyrill Northcote Parkinson - Parkinson's Law, and Other Studies in Administration

This is another classic that I checked in 2016 and one more must read for everyone involved in any kind of modern organization - no matter what's its size or which role you hold in it. In a grotesque form, looking very much like a collection of unreal anecdotes, the book shows how organizations tend to lose efficiency. It is a great fun to read in the first place, but its anecdotes do show real threats that a company or a team may face. Beside telling how things can get bad it describes quite realistic indicators of the fact that something unpleasant is already happening. Thus, in addition to entertaining you, Parkinson's Law will help you assess the state of your organization or spot the moment when it takes the wrong turn.

Ichak Kalderon Adizes - Management/Mismanagement Styles

Finally, because the article is supposed to list the books I would recommend to managers, there should be at least one that has the word "management" in its title. Management Styles is the first book by Adizes that I read and it looks like the right pick. It provides a great model explaining what managers should do, what they actually do and why these are different things. The focus of this part of Adizes' writing is what kind of managers are encountered in the wild and - especially useful - how most of them fail at their duties. It actually gave me a framework that allows to remember that there are several areas in which I should work and makes me spot my own deficiencies when I fail to pay enough attention to one of them. While this was most valuable for me, the book also covers many aspects of managers' and non-managers' behavior and helps handle colleagues better and know what to expect from them. I definitely recommend it to everyone and will myself study other works by the same author - there is likely more great advice to find.

These five titles played a great role in my personal development this year. Of course that's not enough to satisfy one hungry for growth, so there are lots of articles and other sources of valuable information, like podcasts, but these are a different story. As for the books, in 2017 I certainly resolve to read more than last year and will start with Herding Cats by Hank Rainwater and some other book by Ichak Adizes. If you read one of these, please share your thoughts and takeaways in the comments. In this new year I wish you more great books, that will both entertain and educate you!


вторник, 20 декабря 2016 г.

Interviewing Developers: triggers, part III

The series:
Interviewing Developers
Interviewing Developers: triggers, part I
Interviewing Developers: triggers, part II
Interviewing Developers: triggers, part III

This post also appears in my other blog.

In the two previous posts I focused on certain behaviors of an interviewee, which may indicate problems with their ability to become a good developer in my team. I covered quite a lot of such aspects that push me towards saying "no" and now it's time to show that I can be positive as well. Positive triggers also help conduct an interview, although rarely shorten it, because they make you eager to speak more to the person. In this post I will list some things that make a good impression on an interviewer, explaining why they are good and thus showing what I look for in potential hires.

Candidate: "If you're interested, I'd like to explain the broader context of my previous job / project / task"

Just basic politeness and showing awareness of the fact that the interviewer may have their own plan and time limits change a lot. However, combined with a person' willingness to share his or her specific past experience it is even more powerful. In many cases an interviewer has to spend a lot of energy to get a reasonable picture of the candidate's background and has few options other than squeezing the bits of information out of the person, so one who offers a clear explanation themselves makes a head start. This positive impression may be further amplified with occasional dives into technical details - for example, down to a brief explanation of a class hierarchy - because this likely indicates both an ability to communicate efficiently and a desire to dig into things and understand them. Finally, note the initiative - sometimes it might be the most important aspect of a future employee - it means they have ideas and fuel to make them happen and your organization will only have to stir them in the right direction.

Candidate: "So we stick that thing into that stuff and …"

This one may sound unprofessional and stupid, but trust me, an ability to explain complex technical constructs using the simplest common language terms (yes, I qualify "stuff" for a term) usually indicates that the person does understand the solution being explained very deeply. Of course, whether you understand what they are telling or not makes a lot of difference and I speak only of the case when that explanation is comprehensible. If it is, you will likely find that it is easy to discuss both the edge cases of the same problem and similar but less familiar issues with the developer. That happens because a person using less formal terms in their speech has already internalized the knowledge being communicated - not just remembered some bits about it - and can play with his or her mental model to adjust and adapt it for other scenarios. This trait of a powerful mind is something that you would terribly like your teammates - especially, developers - to have.

Candidate: "Polymorphism is <reasonable explanation>. Imagine we have a base class called Person…"

Bless the people who provide examples for abstract ideas without being asked directly! Examples help every party involved in communication understand the topic better and spot new questions and ideas. While this merely makes the task of answering an interview question easier to do right, the real value is that the person shows that they are able to see the implications of an idea and view it from different angles. A developer who quickly comes up with examples and tries to view a problem or idea in concrete figures usually thinks realistically and understands the context better. Such a person quickly grasps the real world problems that a piece of software tries to fix and can transfer this understanding to their colleagues. As for an interview, they try to make it easier for you through their usage of examples and this alone deserves some respect.

Candidate: "We were using ASP MVC 2, which is kind of old, so I decided to learn Node.js and built a personal web-site / game / whatever with it"

Here I barely need to explain anything: desire to learn and develop on one's own is what makes great professionals. They also don't blame their boss or organization for not giving them an opportunity to learn new things or work with the hottest new technologies - they simply learn whatever they find appropriate when they feel a desire to do so. On the other side, any developer may occasionally get a bit tired with their day job and issues associated with it. A person with a positive attitude feeling their own responsibility for their growth will be able to help themselves through such uneasiness by means of a personal project. It is true that such a side activity may distract someone from their job, but the stakes are high it would rather improve the way the developer attends to their duty giving them extra energy and ability to bring new ideas from the outside world.

This is far from an extensive list of positive interview triggers and there are dozens of things that will make an interviewer like a candidate. Still, I will stop right here, because the things said are enough to give a good indication of what I value when sitting on the hiring side. I must have highlighted this a thousand times, but any hiring decision is based on a lot of factors and no single one of the triggers that I mention should be treated as a basis for yes or no. Still if you have a collection of such triggers in mind they may help a lot navigating you through the process of acquiring a new team member.

An interview is about finding a great person to close a gap in your team, so it is important to note both positive and negative edges of the candidate's personality. The goal is to check whether the candidate is a good fit for the open position, the team and your company's culture - that's why I pay that much attention to the communication abilities and personal traits. Of course, the most important purpose of the interviewing process is to avoid hiring the wrong person - hence the relatively large number of negative triggers in the previous posts versus few positive ones in this one. At the same time, noticing the good aspects is also important - especially when these show that after being hired the candidate will keep growing professionally, help others and improve the way they and their new team do the job.

In conclusion of this short series I wish you good interviews - on both sides of the process - and welcome you to share the bits that help you learn more from them!

четверг, 8 декабря 2016 г.

Inerviewing Developers: triggers, part II

The series:
Interviewing Developers
Interviewing Developers: triggers, part I
Interviewing Developers: triggers, part II
Interviewing Developers: triggers, part III

This post also appears in my other blog.

Last time we looked into several responses that I don’t like to hear during an interview. In this post I will add more examples of candidates’ phrases, which usually indicate weak potential for becoming a worthy team member. Next time, to finish on a good note, I will switch to positive interview triggers, but today let’s keep a bit negative.

Candidate: “I’m tired of writing code. I want to be an architect in your team.”

The funniest thing about this is that I usually hear it from 23–24 years old guys, who have at most a couple years of commercial development experience. It is clear that a candidate with this kind of background is hardly fit for a software architect’s position, but it is also difficult to consider them as a developer because they admit they don’t want to do programming anymore. What’s worse, I believe there are few (if any) good architects who don’t wish they could spend more time coding. Somehow the love for programming comes together with good software design skills and the lack of it means one can’t go far on the technical side of the software development world. The simplest rule here is: never hire for a knowledge-based position someone who doesn’t like its core — they will likely be both inefficient and dissatisfied.

Candidate: “That wasn’t my responsibility”

Usually this comes in response to questions like “Why did your team chose to implement X and not Y?” and “Why did you use that framework instead of this one?” If we speak of junior and mid-level developers we indeed must assume that someone else was in charge of making both product and technical decisions, but it is also true that good developers usually care enough about their work and team. This means they do question the decisions made by the team or the company and try to understand the reasoning behind them instead of blindly doing what they are told. It is also common for them to say “we” about the team — even after they left it — and assume some responsibility for its results. If a person does otherwise, it may indicate a lack of curiosity and ambition, both of which are crucial to becoming an effective team-player and growing one’s skills with time.
Candidate: “I was good but the other developer made incorrect decisions and so we failed”
This one is a refined version of unwillingness to take any responsibility — particularly, for failures. I bet, when asked about the reasons behind one of their successful projects that same person will claim full credit for that success. The problem is that such a person is likely a poor team-player. Clearly separating oneself from their team instead of saying “we” tells a lot about the person’s ability to make the team more effective, collaborate and help others. I definitely don’t want to hire someone who will do poor job and then blame the whole world in their failure — such people learn little, don’t work very hard and thus rarely succeed. Moreover, blaming others doesn’t make you look reliable and trustworthy — even outside the interviews.

Interviewer: “Which of your recent achievements make you feel proud?”
Candidate: “There wasn’t anything like that — just common work.”

While treating this response in a strictly negative way might feel too much, it is nevertheless very informative. Even with purely routine work a good employee will discover a way to optimize his day-to-day duties and will feel proud of doing so. The same way, even people who truly believe that they are inferior to others and the results of their work are flawed will likely find something to be proud of if they are willing to assess their achievements. Conversely, candidate’s inability to identify something worthy among their results means they are unprofessional, because a professional always reflects on what they do, looks for ways to improve that and definitely has a thing or two to name as their valuable accomplishments. You don’t want to deal with someone who shows little initiative and lacks a purpose, do you?

In these two posts I tried to outline possible characteristics of a person I wouldn’t want to hire. Like I said before, neither of the triggers mentioned in this or previous post can make me reject the candidate — they only give me a hint on what to look for and which skills and aspects of personality to analyze. It helps spend less time on interviews and also allows me to maintain a clearer understanding of the traits that I expect and don’t expect from the great developers, QA engineers and analysts we are looking for. I promise to return with a more positive attitude in the next post and review the behaviors that make candidates look good to me.

четверг, 24 ноября 2016 г.

Intervieweing Developers: triggers, part I


Recently I explained the key principles that I follow when interviewing developers, but didn't cover an important aspect - the triggers that may significantly influence the flow of the interview. The trick is the more you do interviews, the better you deduce the character of a candidate from some of their behaviors. In particular, I certainly learned to notice particular responses that the candidates we don't hire may give. Even though one can't base the final decision on a single phrase, these triggers may both save some time and allow to avoid fatal mistakes. To begin with, here are 4 phrases that I heard from some developers.

Candidate: "Normally I work in IDE, so I can't solve this exercise on paper"

I've seen this one several times and it always came as a surprise. Yes, we love paper-programming! We ask quite some practice questions, but hardly ever give the candidate a laptop. I acknowledge that developers rely a lot on the comfort of IntelliSense, ReSharper and ability to run the code and tests that a laptop with an IDE provides. At the same time, offering to do an exercise on paper we want to check certain things about the candidate and refusal to undergo this check is what brings me closer to rejecting.

The idea behind coding without an IDE and compiler is that it allows us to see how a programmer makes assumptions about their task and tools and acts under a healthy portion of uncertainty. In other words, paper-programming focuses more on how you think and approach programming, than on your ability to brute-force the solution by trial and error. I interpret such a dependency on one's tools as unwillingness  to think and work under unfamiliar conditions, which for me means being unable to adapt to temporary difficulties and generally far from what we call a professional.

Candidate: "It doesn't matter that I can't solve the dumb programming exercise - I am good at real problems!"

Here it is dead simple: no, you aren't. Not unless you can show that and the "dumb" exercises are here exactly to allow you to do that. The purpose of sample problems is to verify certain skills. that we expect our potential employee to possess, and to see what kind of mistakes they make. If a person fails at this it doesn't mean we won't hire them - in many cases we spot what we need even behind a failure. But if someone tries to sell us the idea that, while they can't solve our mostly simple tasks, there are some mythic problems that they address easily, that is a sign of a phony, who speaks a lot, but does little. I don't think that loud yet empty bragging is characteristic of a great developer, be they junior or senior, - I believe they either succeed at a task or accept the failure and use the discussion to analyze their solution and spot mistakes there.

Candidate: "I don’t remember the theory - it's only practical considerations that are important"

It's not that our job is about reciting some "Introduction to OOP" book to each other, but it certainly hurts when people respond this way to a question like "what polymorphism stands for?". I expect some respect for the theory simply because it helps do our work better choosing the most suitable solutions and gives us a language to communicate with each other. Because the questions I ask are quite basic, those who fail to answer may have difficulties understanding software requirements and commit stupid mistakes. I'm pretty sure that someone who doesn't remember the key principles of OOP or can't explain the internals of a hash-table from the top of their mind can do good as a developer, but not when they denounce knowledge. Here, in addition to an attempt to gain my confidence by empty talk, I see reluctance to learn, which means I would have to invest a lot of time and effort into bringing the person up to the team's pace and establishing communication with them - the time and effort that I likely won't have.

Interviewer: "Could you please elaborate the answer and explain your reasoning?"
Candidate: "I just think that's the correct answer"
Interviewer: "What makes you think so?"
Candidate: "I just think so"
I was very surprised when I had this dialogue for the first time, but it was real and happened to me more than once since then. Sometimes I meet people who just come across a thing that looks like an answer to the question and try to sell it to me as though that's simply the answer that I need. As I must have repeated several times already, I am looking at the person's reasoning and striving to understand them better - not just trying to check whether they are able to guess a number. Even though it makes me feel somewhat stupid, it's not even the fact that this dialogue comes after I give some hints to indicate that the answer is incorrect that is most annoying. The problem is that such attitude shows that the candidate is bad at explaining their solutions and will hardly be able to contribute to a discussion of a complex problem with their ideas, not to speak of guiding other programmers and any kind of seniority. Even worse, like all the phrases above, this one is a sign of refusal to exercise one's brans - a very unlucky feature for a developer.

As you can see, these triggers show something about the person's approach to solving problems - not about which technologies they know or what tools they mastered. I pay that much attention to this aspect because it is relatively easy to teach a curious and thoughtful programmer a new language or a nice trick, but way more difficult and unrewarding to attempt raising a good developer from a person who doesn't want to study and sometimes even to think.

Even though hearing any of these phrases doesn't mean I would instantly stop the interview and refuse the candidate, they greatly impact the outcome of the interview. I have seen other managers hiring people who failed to solve an exercise or answer a couple questions and did that myself too. Still, I haven't yet met a person who behaved in the manner described above during their interview, but gave enough reasons to hire them nevertheless.

There are a couple other ways in which a candidate can draw my attention - both in positive and negative ways. I will get back to these in future posts. In the meantime, what do you think of these triggers? Do you believe they are valid or should interviewers be more forgiving?


вторник, 25 октября 2016 г.

Interviewing Developers


Our company has been experiencing rapid growth during the recent years, which means we were hiring a lot. Managing one of our teams I took my part in the process and conducted a significant number of interviews. When I first faced the task of evaluating a candidate for the software engineer position a couple years ago it felt very awkward and difficult, but over time I developed a general approach that helps me go through the interviews easily and quite efficiently.

Of course the key point about the interview is which questions to ask. In the beginning my attempts to come up with relevant and challenging ones were very painful. I struggled a lot and jumped from one topic to the other always being sure that I miss something important. However, when we speak of technical knowledge and skills, it turns out that the most fruitful questions to ask are quite simple. For example, I usually focus on basic textbook-level Object-Oriented Programming and C# topics. Keeping things simple you may quickly see that the candidate demonstrates only shallow knowledge and, which is more important, inability to explain technical stuff in plain and simple words with reasonable examples. Such an outcome means an end to an interview - if a person can't discuss basics they likely won't be able to reason clearly about the complex stuff that your team deals with. On the other side, the potential employee may show great ability to articulate the subject and its practical implications in such a way that you see the experience behind their words and learn quickly that you're not wasting time with them. In this case you may proceed with more complex problems, but this is rarely necessary unless you're looking for some very specific skills. 

Simple practice exercise have the same advantages and provide enough insight into the way the candidate reasons and knows his tools. Even the easiest programming problems usually give enough room for mistakes and bugs and allow to get a good evaluation of a programmer's skills. It may be a good idea to challenge the candidate with some really serious coding puzzle, but you definitely don't want to start with that. Because the technical interview is to large extent about assessing candidate's abilities to analyze problems and explain solutions we also always offer a logic problem. Being an exercise suitable for the 5th grade or something like that, it still tells a lot about the way a person would analyze the situation and draw conclusions, not to speak of their explanation skills.

Still, you don't want you candidates to spend the whole interview fighting boolean algebra, so you will need some reasonable practice problems. One good place to look for these is the domain that your software models. It is usually enough to spend a couple minutes thinking of what you do on duty to come up with a couple great yet moderately difficult problems. Just keep in mind that these should not require too much context or be too large, so that you can stick them into the timeframe of the interview. For instance, my list of practice problems includes an SQL question that I faced when developing one of our features - it is a pretty real-life yet very simple and thought provoking problem.

While technical questions usually take the most of my interview time, I also dig into the personal experience and attitude. Our HR talks to every candidate before I get to them, but I still find it very important to discuss the potential employee's background and soft skills. Anyway, I have to check whether the person will fit into the team and will be able and willing to do a good job. In additional to usual questions on their duties on the last job I love to ask for a couple achievements, which they feel proud of - people are frequently taken aback and start to dig for their best, which makes the answer very valuable. In addition to unveiling the candidate's experience, such questions allow to assess personal traits. For instance, I can learn a lot about the person's involvement into their job - good candidate would usually be able and happy to speak about their duties and achievements, explain them in depth and do it in such a way that I will get interested even with little context. The way a candidate speaks of his tasks and situation in the office also tells a lot about their attitude and motivation and may uncover teamwork-related risks.

To ensure that both technical and non-technical questions are informative and easy to handle I have them written out carefully and usually ask the same ones, mostly in the same order. Even though this might not seem important, it plays a great role as it prevents hesitation and fears of forgetting something crucial. Additionally, if I follow more or less the same path through the interview, it becomes easier to utilize past experience to spot patterns in the way candidates respond and dive deeper into certain subjects. Finally, this helps to compare candidates to each other, which is quite hard otherwise.

Another aspect of conducting interview, that I find very important, is to be kind. When I am open, attentive and helpful I can definitely learn more about a person than if I demonstrate them my superiority or show that I want to get away as fast as possible. A candidate in an interview usually puts enough emotional pressure on themselves, so there is no need to introduce any artificial stress. This helps not only throughout the interview, but after it as well: I may decide to make an offer and in this case I'd better have the person willing to work with me - not being frightened to death.

Thanks to all these tiny how-to's I got much better at doing interviews, but I still face certain issues. In particular, sometimes I pay too much attention to the person's communication skills. While their ability to speak and listen means a lot and helps both integrate them into the team and teach whatever is important to our business, there are many valuable hires in the world of programming who might be a bit tough to talk to. I also tend to try too hard to find pros about the candidate - in particular when it is already obvious that I won't hire or recommend them. I constantly fight this trait, but it requires a degree of discipline to cut off all of my willingness to understand the person better and say a firm "no" quickly. One inevitable consequence is that my interviews take a lot of time, but at least I know how to shorten them.

Still, the most unpleasant problem about interviewing and hiring may come in the process of making a hiring decision. It can be really tough when I think good of the candidate, but at the same time have a feeling that something's wrong with them. In most cases such sensation means no offer - even though I can't explain what bothers me, the hesitation is a good indicator of hidden problems, which may surface later. In spite of knowing the general rule "doubt = no hire", I sometimes have a hard time making the "no" decision and need to work on that too.

Despite these issues, the simple practices outlined above, like having a regular question list and focusing on candidates' reasoning abilities allowed me to become more efficient and confident on the interviewing side. In particular, this helped to hire several great team-members who have already delivered great results and became valuable employees. Overall, interviewing is not too difficult a process, but it takes some time to get it right. I'm still actively working on improving in this area, so please share your insights and how-to's!

понедельник, 26 сентября 2016 г.

The Inmates Are Running the Asylum

I recently finished reading The Inmates Are Running an Asylum book by Alan Cooper, which dives deeply into the question of how software design should be performed. There are great many interesting ideas and a lot of thoughts that anyone working in a software company may want to consider. Even though I can't agree with the views of the book to the point, I liked it and will try to cover both the thoughts that fascinated me and those that seemed questionable.

At the core of the book lies a simple idea that when we are going to manufacture something - possibly that's a piece of software - we should design it upfront and do that properly. Design at its core means establishing the overall structure of the product mainly from the point of interactions with users - down to UI design, but well beyond it. The term 'properly' is an equally sophisticated thing and expands to many different recommendations, warnings and tools. Some that stand out are: finish working on the design before you start coding; detach designers from coders; use certain techniques to channel design and limit the scope effectively.

The idea that we should put some effort into design before development can hardly surprise anyone. Even those who preach that a programmer should just hack the code till the product is born would likely agree that certain amount of careful and structured thinking has to precede creation of the first lines of code. The explicitly stated suggestion that coders should not do design and even that the designers should better be somewhat isolated from those who program is more controversial. Still, it makes a lot of sense, because programmers (and I speak of myself in particular) tend to focus on implementation details and reduce the domain to the level of their apparent technical capabilities. This strongly affects the point of view and ability to see what we are going to build, for whom and why - we mostly pay attention to how it is going to be built. At the same time, software should be designed not just to be buildable, but to deliver value in an easy to use manner. Our ability to provide value to the users is usually limited by poor understanding of their needs - that's something that most of the programmers faced at least once during their career. With usability we fail in a more subtle way - we make the thing easy to use, but only for the folks that look like ourselves, because that's what our experience and customs drive us to. In most cases, however, the users are people with a very different background, so we unwillingly make sure that they have hard time with our product. While these claims may raise some disagreement, they look valid, even though are not always the best to follow from the practical point of view.

At the same time, I couldn't agree with denouncing of the act of prototyping. The reasoning for claiming it bad is that prototypes tend to stick and in many cases to become the first version and the core of the final product, being least suitable for that due to their nature. That happens because programmers don't like to throw their creations away and managers, avoiding what looks like wasted effort, like it even less. While it definitely can be very hard to get rid of the code that is already written, I still don't think that the technique of prototyping a part of the solution should be disposed of. We should simply use it with care and be ready to dump weeks of our work into a waste bin because the goal of a prototype is not to serve as an actual basement for the final version, but to provide grounds for decision making that brings us to the finished product.

What makes the book very practical and valuable is the design tool that Alan offers - personas. The idea boils down to making up a narrow set of characters that depict future users of the product and allowing these fictional dudes to wholly drive the design process. Interestingly, the book suggests that the design team should give each persona a name and photo, assign user roles and thoroughly describe their background. Such characters would allow to speak of the product in terms of the needs of concrete, although unreal, people who are expected to use it. I must admit that I have never tried this approach, but it seems very powerful to me, because it gives a framework to ask proper questions about the thing in the making and to ensure that design stays on the right track, as we develop the product exclusively for our personas. This means that if there is no persona that needs a particularly fancy button, the button will never make it into the final design. The book goes even further with this suggesting that in most cases it is not right to subside to the customer's attempts to squeeze another feature from the development team unless our personas justify it. This idea rests on the assumption that a good design based on the right set of characters would cover the needs of the user, while anything that is injected into the product in spite of the design will give birth only to inconsistencies that will eventually ruin the software. Sure, rejecting client's request is a tough thing to do, but there is something to the idea of declaring clearly what your user looks like and staying by that declaration - it could certainly make some of our creations more consistent.

While I liked most of the core ideas in the book, it still raises concerns in regards to its practical applicability. The problem with the entire design framework presented by Alan Cooper is that it requires great upfront costs with the possibility of getting nothing but experience as an outcome. The biggest share of these costs comes in the form of the time spent without delivering any kind of a marketable product. In the modern world, when everyone strives to squeeze time to market as much as possible, it is difficult to take a path that promises to double it (in the best case). It also seems nearly impossible to incorporate this design and development methodology into an existing process - it can work great from the beginning, but when there are established constraints of an existing product, anyone trying to inject a serious design into a working motor will likely fail.

Overall, I definitely recommend this great practical book to anyone working in the software industry, as it gave me a new perspective into the development process and explained some very useful tools like personas. It also conveys greatly the idea that usability is born - or buried - deep under the hood of any software and can't be just added on top of a finished product, which is something that you want to keep in mind. Finally, a ton of examples - both related to software and beyond the industry - show that many things that we use nowadays are designed poorly and are still hard to use, which means there are lots of opportunities for making the world a better place.