If we analyse a software industry and companies in it, we can distinguish two main types of companies: service-based and product based companies. Depending on which type our company represents, we may tackle the technical interview process differently.
CliftonStrengths is a tool that builds self-awareness and helps us identify our strengths. See an example of how this affects our careers and how we can work to grow knowing the results
Understanding how to choose the right document type is crucial to separate fast-changing documents from more stable ones. This will help you keep our documentation up-to-date
Writing a personal worklog is a useful technique that helps you store knowledge that you get as you work through challenges in the project. It serves as a personal knowledge base which means that you don’t have to solve the same problem twice.
For the past few years I’ve been strugling to find a perfect structure of the technical interview. In this article I share thoughts and advice that helped me find the sweet spot of the technical interview
If our company reaches a point where the product is too big to keep in mind how it works, more teams need to be introduced. This usually results in incorrect knowledge distribution. According to Conway’s law the system will eventually adapt to the new organization structure. But until this is achieved, people can become frustrated and leave. We can act proactively by identifying gaps and reducing them. A tool that can help us with that task is the team knowledge matrix
The organization may thrive until the smartest guy leaves. If that’s the case, and just one person out was enough to move the company into panic mode it means the bus factor is alarmingly low. In this article I present ways to improve it.
