What do you do when you receive a meeting request without agenda? Unless you are pretty confident (which is a rare case, except that you are the organizer) what is the goal of the meeting, decline it!

Meetings are necessary evil of teamwork - you want to share opinions within the team, but meetings distract you from other important things you've got to do. The key thing here is "they distract". You want to keep this distraction minimal, you want meetings to be focused and productive. And this is what agenda is all about. It helps to stay focused on the issues that need to be resolved by the team together and it allows everybody to do her homework by thinking out all of the agenda's items in advance. Meetings without agenda can take twice and trice as much time as the same meeting would take if the agenda was sent beforehand. This is especially true if the meeting is a conference call.

What would you do when you send meeting request next time?

Microsoft VSTS Process Templates homepage features Cognizant Feature Driven Development process template. Cognizant adds many (too many, actually) new concepts to FDD so that the process looses its elegant simplicity and focus. Instead of focusing on bug-free feature implementations with low deviation in development time they introduce a concept of "bug". Simple and powerful process indicators dominated by sophisticated work items state transitions. If there is a choice, I'd use "original" FDD even without tool support.

More information on "original" Feature Driven Development:

Feature Driven Development portal
Agile Software Development using FDD
FDD Overview Presentation

This is actually a repeat of my older post from my old blog. But it is summer again, so why not?

Here in Ukraine you can more and more often hear people asking "How were they grown?" when they buy some vegetables. Especially when they are going to buy early vegetables that are difficult if at all possible cultivate by "usual" process and get harvest this early. What this essentially means is that people are interested in the process used to achieve the result. Why they would want to know that? Because this helps customers evaluate quality of the product. It helps customers understand internal characteristics of the product they are about to buy. And here not only the process or quality assurance procedures itself matter but also the ability to effectively communicate benefits of the process to win customers' trust is important.

The same thing happens with software development. We want to build trust relationships with our customers. But this means that we have to give them a look at what is going inside, we have to provide transparency for the customers. It is extremely difficult and sometimes very inefficient to build trust without transparency. So think twice before replying to customer's "How are you going to achieve this result?" with "Just trust us. We will do it."

More on this topic in David Anderson's post "No Trust without Transparency".

Just came across this series of podcasts published by BBC World Service – The Handy Guide to the Gurus of Management. Going to listen to them in the nearest future.

If you happen to not know who is Jim McCarthy watch all the video episodes of his “23.5 Rules of Thumb” presentation and read his article “21 Rules of Thumb for Shipping Great Software on Time” based on earlier version of the presentation. Jim left Microsoft to continue his research in the field of team dynamics. The result of this research is The Core: set of commitments and protocols to enhance productivity of teams.

If you think downloading The Core PDF is a waste of time and traffic – just read the thoughts of a bootcamper. Or watch an episode of Jim’s presentation right now.

If you are reading Joel’s blog you probably have read his post about New elevator technology. While this is an interesting idea from pure technology viewpoint, another idea came to my mind…

I believe that USA (together with Singapore, Hong Kong) is the place where such technology was likely to emerge more than in any other country. And almost certainly (alas) such technology could not be invented in Ukraine. Why? Because there is no demand such kind of elevators usage optimization, simply there is no places in Ukraine where it can be applied. Even if a man has a bright ideas he has to be in the right place at the right time for his ideas to blossom. Unfortunately, the factor of place still can limit the greatness of accomplishments one can do.

Mankind has to go a long road as yet to overcome limits imposed by all sorts of divide on the achievements of human race. I hope that in future we will more often learn about technology breakthroughs made in places we now know as “developing countries”.

I guess, it's not news that you should prepare for the interview. For interviewer it is about learning candidate's resume and thinking out questions that the candidate is supposed to answer or discuss. Depending on the candidate's level my questions of course will be different, but in general I would divide them into following 3 categories:

1. Academic. These questions are concerned with more of a theoretical knowledge of the candidate and usually assume more or less exact answers. Something like "What is garbage collector? How does it work in .NET?" Also I try to put such questions in a way that will allow me to ask follow-up questions and elaborate the topic. E.g. if candidate says that there is generational garbage collector used in .NET, I would go ahead and ask what other types of GCs the candidate know and how they compare to generational GC. (Unfortunately, not so many candidates can take up a talk in this direction) If candidates know nothing about generational GC they usually compare .NET GC to Java by saying that .NET GC is "much better". Asking for more details is logical next step :)
2. Experience. Here I usually start with "What is your greatest professional achievement you are really proud of?" Then questions go to most remarkable notices from the resume.
3. Discussion. Questions or rather topics that allow more or less informal discussion. Often I just ask questions that I'm just curious about which are relevant to candidates experience or interests. Something like "How long does it take boost libraries to compile?" and so on about "usability" of boost. For me this section of interview is not about knowledge, but about opinion. I kind of assess candidate's general ability to think and present his thoughts.

Actually, if I see that that candidate feels comfortable on the interview I may use fourth category: provocative questions. Questions or assertions that go against common way of doing things or accepted knowledge with weak or irrational reasoning behind. I just need to say it confidently and ask the candidate for opinion. Well, sometimes I play so good that after all I have to say that it was just a joke and in reality it is somewhat different then I was saying.

Also the interview I try to create an atmosphere that helps to make it easier for the candidate to show his best. And I ask tricky questions only if I see that candidate can handle them. Interview is not about showing the candidate how miserable his knowledge or experience is, but about making him show everything he knows and can do.

If you are going to interview somebody be sure to check out The Guerrilla Guide to Interviewing by Joel.

Is this going to be an interview for engineering position in .NET? You may find useful these sets of questions for interviewing .NET developers by Scott Hanselman: ASP.NET Interview Questions and What Great .NET Developers Ought to Know.

As a Business Unit manager I often interview candidates for engineering positions at Dnipropetrovs’k office of SoftServe. Recently I also was involved in preparing my guys for interview with client. So I know both, dark and light, sides of the interviewing process.

From my experience the most important this on the interview is to know the goal of the interview. When you interview somebody know requirements for the position candidate is applying for and know what qualities you want to discover in the candidate during the interview.

In fact, when I interview someone for junior position my main goal is to see potential for growth supported by ability to think and learn. For senior positions, I expect candidates to be able to apply their experience to solve open-ended problems and have their own opinion.

When you prepare for interview know what the person on the other side of the table expects from you. Is she only interested in technical expertise? Will your communication or leadership skills also be assessed? Will she try to see how you work under pressure? If you have answers to such questions, you will be able to prepare for the interview much more efficiently.

Did you know that several interviews from Founders at Work a available on-line here? I very much enjoyed stories of Joel Spolsky and Steve Wozniak to consider buying a book.