Few notes about Interviews

During my work, I’ve made many interviews with the candidates.

Most of them were for my projects.

It’s a really important fact since it gave me an understanding of my mistakes and successes: I’ve worked closely with the people I’ve selected.

After all these experience I want to share some of my conclusions about interviews:

  1. Avoid situations and questions which cause pity for the candidate or make him feel bad. Don’t ask deep questions if you know that candidate is weak in the area etc. Results: all these bad feelings will not affect your decision and it will be objective. From another hand, the candidate will be not demotivated and will show his best.
  2. Candidate should be motivated to get the job. He should demonstrate an interest in the work described by you. Results: if the candidate has no motivation even from the start- it’s a small chance that you’ll change it in the future. If the candidate is not motivated after the interview – you need to reject him and think if your speech about the future work was motivative. This is the next point.
  3. Your speech about future work should inspire. You should be motivated to find the candidate and say correct words for each of them. Results: the candidate will feel it and choose your offer if you’ll make it.
  4. The best question for an interview is a question related to future work, without a single answer, but with a range of answers which are depending on the knowledge of the candidate. Don’t be focused on deep details or logical games if it’s not specific of your work. Range of answers will give a room for creativity. Results: it gives you much more information about candidate knowledge in the area you really need.
  5. Pay attention to the soft skills of the candidate. It’s critical since most future problems with all employees are not in the technical area, but with communications, responsibility, ability to support your team culture, etc. In my practice, I split the interview into 2 parts. 1st part is just to detect soft skills. Results: you will save your time and nerves.
  6. Be open with the candidate. Don’t lie about future work. Result: the candidate will not leave the job if he made a balanced choice knowing of all future challenges and profits.
  7. Mentor the candidate in a friendly manner. Provide him technical advice, recommend some books to read, etc. Make him feel that he leaves the interview with the new knowledge, in a good mood. Results: even if he will not pass, it’s a high chance that he will be back with the new knowledge.
  8. Make a short practical test. Prepare some technical task which is close to the real work. See point 4 from above. I prefer to leave the candidate alone for 20 minutes for some code refactoring. Result: the real work is the best test for the skills. This is the next point.

Finally, I want to highlight the following conclusions I made:

The best check for the candidate is a real job.

Unfortunately, exists such type of people who can speak nice and pass all your questions, but the real job is hard for them. Anyway, be ready that all issues will appear during the real work with the candidate.

The recommendation of the candidate is highly important. Especially from a trusted person.

Try to get feedback about the candidate from the past co-workers. It will give you really strong arguments for your decision.

Trust your feelings and intuition.

A big piece of our experience is hidden inside of intuition. Some candidates will cause you to doubt, although all questions will be well answered. Don’t ignore your intuition. I prefer to have one more interview later when the reason of doubt will be clarified and should be checked. After some time I follow the rule – I reject the candidate if I have doubts.

Listen to each other! Good luck with the interviews!

Communities. Beginning.

Before I’ll start, let me describe our company: it’s an international IT-company with 900+ employees, providing software development and IT-consulting.

Around 2 years ago I got the opportunity to boost the technical level of the company.

A not easy challenge, but it was a great opportunity to try my approaches and visions.

In the beginning, it was different kind of questions to solve. Let me share the most important of them: 

  1. How to identify directions for improvements?
  2. How to form the team which will make it possible?
  3. How to make it work not one time, but day-by-day?
  4. How to make it work with a small budget?

   I don’t remember how it happened, but a wonderful answer to all these questions came from my subconscious: let’s build communities for each work area: Business Analysis, Java Development, JS Development, DevOps, Quality Assurance and so on.

Let’s clarify my understanding of the Community:

Community – is an open informal group of employees who are interested in knowledge sharing in a specific work area. 

Let me highlight few words:

Open – it means that all employees can be a part of the community. No restrictions related to experience. Why? Each person can be helpful! Sometimes proactivity and creativity of the young people are vital for the work process.

Informal – it should be a friendly and homelike atmosphere between community members. Why? It should easy to share knowledge and even small achievements. Members should be loyal to the experience of each other and ready to help. There is no community without easy communications. 

Interested – means not-indifferent and proactive. Why it’s important? An indifferent employee has no energy to get or share the experience. Such employees are more like zeros for the community. In all cases, they are welcome. Important note: be sure they don’t demotivate other community members. Such kind of people exists as well. 

So how communities will help with the questions from above? Let me answer in a different order and elaborate community idea.

  • How to form the team which will make it possible?  

Let’s begin with regular Meetups where community members will share knowledge, discuss trends, new approaches, problems, solutions. Here it will be possible to identify the most professional and proactive employees for other activities. Additionally, we can select the most experienced member to help with community leading. Let’s call them Community Lead. The most regular meetups members will form the Community Core. This formation will be really useful with performing of the most important and complex work.

  • How to identify directions for improvements?  

It will be possible during meetups discussions. Especially during discussions of the new trends and existing problems. Additionally, we can send regular Newsletter with the review of existing trends, useful resources and so on. Responsible member will get new experience and share it with the whole community. All of these will cover one big goal: Aligning of the company with future trends, but it’s not all. Community efforts can be applied to cover more areas: mentoring, training of employees, providing consultations and help other employees and projects, knowledge mining (research) and sharing, organizing of technical events (i.e. Hackathons), Sales Support and so on.

  • How to make it work not one time, but day-by-day?  

With the structure from above and regular activities (i.e. Meetups, Newsletters etc), Communities will become an integral and permanent part of the company. After some time it will be possible to identify, describe and support related processes to make them stable and effective.

  • How to make it work just with a small budget? 

The secret is that Communities are helpful not only for the company but especially for the employees themselves: they get new skills, new experience, help, field for creativity. Just for free! As a result, the company can pay just for extra efforts like community leading,  meetups organizing, newsletter preparation, but as a result get a really great profit and help. 

I hope the concept of communities has become more understandable and simple. 

Unfortunately, the greatest difficulties in creating something are rooted in details.

The devil is in the details

Let’s highlight the top of problems met on my way to communities building. 

  1. How to find initial community members?
  2. How to communicate with the community?
  3. What the best format of the meetup?
  4. Who is the best Community Lead?
  5. How to make Community processes stable?
  6. How to motivate employees to join the community?
  7. How to launch a pure technical community with many introverts inside?
  8. How to apply community efforts in the best way?
  9. How to make the community part of the company processes?
  10. How to measure community profits?

Like in movies, let’s answer on these questions in the next posts. See you! 

By the way: let me wish you a happy and prosperous Happy Year!

silhouette photography of group of people jumping during golden time

Invisible man

What does come to mind if you need to asses your colleague? What areas do you usually measure?

Let me mention some of them:

  • Knowledge in the technical area
  • Professional approaches
  • Ability to work in the team

During my practice, I’ve detected one more important option.

But let me describe the situation I’ve met:

Due to some reasons, it was no daily stand-ups on the project. One of my team members worked for a long time on the task. The task was quite complex with different hidden stones inside.

The problem was that he provided his status only on my request. Results were hard to check and he always shifted the deadlines. As a result, after a month of work, when it was an internal assessment it was hard to evaluate his efforts and skills. He was like an invisible man for me. It was not clear how professional he is.

Another colleague was confused as well. She said a great phrase:

He has low VISIBILITY.

Yep. That is the perfect word! I’m using it now for some set of professional approaches.

After thinking let me summarize what I mean under Visibility:

Visibility is the ability of a person to provide timely and tangible information about his current work results.

Tangible means that the results can be easily checked: it could be a pull request, test case, user story, demonstration, charts, video recording, report, email etc.

Note that results of work can include even the list of blockers provided by email.

Problems we meet are the results of our work as well.

Timely means not right before the deadline but provided in an iterative way, right after receiving any tangible achievement.

What is the profit from visibility?

For the manager and the whole team I see the following points:

  • It makes it easy to check actual results and plan the future work and deliverables
  • It reduces delays in development and unexpected problems and results at all
  • It makes possible timely handling of the problems
  • The results are visible for the team and the customer
  • It avoids unpleased moments during work result assessment

For the employee itself:

  • It works as self-marketing. If your positive results are visible for management it increases your karma salary: your achievements will be not ignored and will be used during the assessment procedure.
  • If you speak openly about your problems, it’s a big chance that your team will help you to resolve them
  • If you make your work results tangible it means that they became better quality
  • It avoids unpleased surprises during your work assessment

Why Visibility is so important? Let’s imagine that the profits from above are revoked.

In the context of the situation from above, I’ve made additional conclusions:

Daily standup increases the visibility for the whole team. Avoiding this practice badly reflected on each team member.

The manager should describe to the team how to become visible. Keep it in mind that visibility is not usual for some people.

High visibility is a part of high professionalism!

Be visible!

photo of a turtle underwater
Photo by Belle Co on Pexels.com


In our world, we’ve to remember and plan a lot of things.

Let’s summarize what it could be:

  1. Meetings at some time and place (i.e. weekly status call or meeting with friends)
  2. Actions to do for some day and time (i.e. send some important report)
  3. Actions to do for some date (i.e. congratulate colleague with the birthday or fill timesheet, check task progress)
  4. Actions to do in near future without an exact date (i.e. analyze some unimportant email)
  5. Actions in the far future (i.e. review article)
  6. Recurring meetings and actions
  7. Notes (i.e. articles to review)

As you see it’s a lot of information to remember in our world. Often this information is critical: nobody wants to miss an important deadline, meeting or just the birthday of the best friend. The problem is that:

Constantly trying to remember things drains energy and causes stress.

Fortunately, we have a lot of tools and approaches how to take all this pressure and worrying off of your head.

Let me share my way to this goal.

  • A long time ago I’ve started with the simplest solution: writing in a paper notebook/organizer with sheets marked with dates. It resolved some pain , but a lot of things still became unhandled:
    • Not easy to move actions to the next days. You need just to copy paste them
    • Not easy to handle actions without dates
    • You need to have the notebook near to you
    • No notifications about events
    • No way to handle recurring events


It’s really important to add notes fast since nobody will wait for you during discussion.

It should be easy to move notes from one day to another! It’s important since it’s impossible to finish all the available work in one day.

Notes should be always near to you!

It should be possibility to save reccuring events and actions.

It should be the way to mark some events or actions as important/unimportant.

  • Then I have moved all meetings in calendars based on the email apps(i.e. Outlook Thunderbird). It resolved a lot of pains related to meetings and events with exact date/time, but different items were not resolved:
    • Actions without date and time are hard to handle
    • Actions in the far future can be easily forgotten
    • Not clear how to add notes

A lot of actions have not the exact date and time.

  • I’ve introduced small colored stickers for actions without date and time. It was easy to fill them and it was really motivative when you completed the task and throw related sticker out in a basket. But:
    • It’s easy to forget notes about action
    • Stickers are not always near to you


It’s perfect when completence of actions motivates!

  • Using whole day events in the calendar tool for actions without exact time. It made all my notes located in one place. Additionally, it was easy to move them between dates. But:
    • It was hard to separate meetings and actions without exact dates. All thing displayed as events. As a result, it was around 20 events for one day.
    • It was not possible to plan for actions without a date.


It’s inconvenient to see the mix of meetings and actions without exact time.

Then I’ve searched for a good tool for actions and finally found it by recommendation of a colleague:

  • I’ve moved all actions and notes from the calendar to the Todoist app. This tool covered all requirements I’ve described above! Additionally, this tool has the intelligent way how to shift actions: it suggests the most convenient day for action and more other things. Also it motivates to complete the actions with different approaches as karma and daily limit.

Now I’ve separated apps for meetings and actions on desktop and mobile as well and finally, it’s easy to see the meetings for the day and get reminders for them and handle actions from Todoist.

As a result, I recommend to use calendars i.e. Google Calendar, Outlook for meetings and the Todoist app for other kinds of actions.

Please let me know if have any questions or notes! Enjoy!

postit scrabble to do todo
Photo by Breakingpic on Pexels.com

Meetings Log

Meeting without action items looks like chatter.

But it’s STILL CHATTER if action items were defined, but not checked how they are handled.

I think you will easily remind such kind of meeting when action items are defined in words or even defined in the follow-up email, but not handled or just forgotten after the next followup.

I’ve asked myself how to make the action items not be blah-blah-blah items, but action items: when people will return to them till they are not done.

Actions items should initiate real actions!

On the last projects, I’ve moved from followup emails to Meeting Log.

And it works great!

Meeting Log is a simple Confluence page with the history of the meeting.

It’s just simple grid with the following columns:

  • Date and Type – date of the meeting (in the past or in future), and type (i.e. Technical, Weekly etc).
  • Agenda: Reporter + Agenda. It’s easy now to plan the future meetings. All team members can easily to add items for the meeting in the future etc.
  • Action Items: Actor + Action.  Action initially marked by some visible sign that it should be handled by Actor. During the next meeting, we check the items with signs and remove them if the action is performed. It can be different results of action: email is sent, the ticket is assigned etc

It looks like this:

Meeting Log

With such a simple solution, our action items mean real action: we’re returning to the items with a sign and check them till they are not completed with any result.

The only problem you will meet is to make it filled by the responsible team members. In my case it was easy: BA fills it instead of follow-up, TL fills technical log to not forget what was discussed and what tickets should be created.

I hope it will be helpful for you!

Don’t hesitate to put your comments if you’ve any questions.  Thanks!

Side note: Confluence provides a rich set of macros to make this process easy and good looking (i.e. generation of the question mark, select date, select actor etc)

Open questions:

  1. Is it possible for Artificial Intelligence to take this routine with Meeting Log filling?
  2. Probably in Confluence we need to use checkboxes instead of questions marks.

remington standard typewriter in greyscale photography
Photo by Pixabay on Pexels.com


Project Agreements

It’s not a secret that

during the life, project team including customer creates a large set of internal agreements and rules.

It covers all possible areas: management, communications, development, release process, quality assurance, requirements etc.

Examples of agreements:

  • Sprint length is 2 weeks
  • TL is responsible for newcomer introduction
  • Customer dev team should inform about infrastructure changes.
  • Jira tickets for the business feature should be marked by “Feature” label
  • The weekly status call should go in the following order.
  • DevOps should notify the team about a critical update of environment
  • Git commit message should be in the following format
  • All shared files should be located in the project folder (link)
  • To get access to the Production Server you should use the following guide.
  • The configuration of the server should be done in the following way

Some of them look simple and clear, some of them are complex, but most of them are covered by the same problem:

Huge number of project agreements are not documented. They are hidden inside of team members knowledge. They are not official, but exist.

It’s totally the same case I’ve described in the post about informal things.

The effect is known:

Unofficial things makes the situation unclear and not manageable. It breaks the work process.

So what does it mean for the project:

  1. Agreements are working from time to time.  They work not like agreements but as important recommendations.
  2. Team members and customer easily break the agreements since they look not important and actually not fixed.
  3. Agreements are hard to share and improve.
  4. Hidden agreements became “hidden stones” for newcomers and project at all.
  5. Agreements are lost and forgotten with team members rotation

On my projects I applied the simple and clear solution to avoid the situation from above:

Team should document all project agreements as soon as they created.

To make this possible I do the following things:

  1. I create the Confluence page called Work Agreements for all kind of agreements which are applicable for each team member and customer. It has the simple structure: it contains the table with Agreement #, Agreement short name, Agreement definition itself. In the top, I add the Table of Contents for simple navigation across agreements.
  2. I create Development Agreements for common technical agreements and page for each technical area (i.e. Frontend, Backend, Mobile).
  3. For each Agreements page, I select a responsible person who will take care of agreements fixation, improvement and agreements implementation. Project management (i.e. PM, TL, Scrum Master) is responsible for the whole Agreements process.
  4. For other project areas (i.s QA, DevOps, Design/UX) we create pages as soon as the first agreement defined

Now when the team creates an agreement (ordinary during standup and retrospective meetings), responsible person documents it in the dedicated page.


  1. The team and customer has a strong understanding of what agreements they have.
  2. It’s easy to approve agreements with the whole team. It’s important since if the agreement is documented and confirmed by each team member it’s some kind of mini contract of the project. Each team member undersigns it.
  3. It’s easy to appeal to the agreement if it is broken. Agreements protect the team members and management from useless arguing and discussions.
  4. Agreements with the customer can play an important role in critical situations. It some kind of internal contract which can protect the team.
  5. The customer is satisfied as well since his agreements are supported by the team.
  6. It’s easy to improve agreements if they are written.
  7. It’s easy to share agreements. They can be reused in the future projects!
  8. Introduction of the new team member is simple. The newcomer is on the same page with the team.
  9. After some time, some sets of agreements can be grouped and used as policies and guides.
  10. Technical agreements can be used as points for refactoring: technical agreements should be supported not in words, but in code.
  11. DevOps agreements can be used as points for automatization.
  12. Design agreements can be used as the basis for a Style guide.

I wrote you that agreements can be reused, but don’t forget that it’s possible just for the most common items.  Each team is unique and should come to the agreement during the work process. Something that works in one project will not work in another.

In addition, the team should understand the importance of agreements. To make it work, the management should initiate the process by documenting of some important rules.

From my experience, it’s not hard to motivate the team, since even the initially fixed agreements will demonstrate the profit described from above.



group hand fist bump
Photo by rawpixel.com on Pexels.com

What is your orientation?

I often notice that people can be separated into the following groups based on how they get satisfaction from work they do.

  1. Tool-orientated
  2. Process-oritented
  3. Goal-oriented

Let me describe what I mean.  Imagine that a project or a business is a marathon with the finish line.

  1. Tool-orientated people. They like to run in their special boots and sportswear. During the project development, they enjoy playing with the “tool”: it can be some process methodology, framework, service etc. The big concern that they are just focused on playing. If the new tool will arrive and not used – they will be really unhappy and leave the marathon before the finish line. Do they bring profit? Yes, of course: they are brave to use new technologies and they are geeks, they like to dive deep into the details. I think many good experts started in this group.
  2. Process-oriented people like just to run in their own manner… doesn’t matter where is the finish line. They are interested in some work area of the project and they do it in their own way.  They do it well, not restricted by tools and have a good vision of the process they do.  The problem is that they can forget about the work goal. Additionally, they are losing their satisfaction if it’s not possible to make things in their way. From another side, they do they work and will go till the finish line. Not in the top, but still with good result. It depends on the trainer who will remind them about the goals 😉
  3. Finally, Goal-oriented people. They like to meet the finish line … anyway. As a result, they are winners and they like it. It doesn’t matter what tool to use and how. The Goal is their God.  What could be wrong?  They’re using not perfect tools, they can use them in a wrong way, they can bring down other runners. Yes, they are not perfect. But hey… winners are not judged!  The project is completed. It’s good for management, good for the customer and…  quite stressy for the project team 😉

Of course, people are not dedicated just to one group and the project is not just marathon.

All people make some profit for the project, especially in the right place.

But let’s be frank:

If you need to win, you need to be a Goal-oriented person.

Make your choice, but don’t be indifferent to your work!