Top 20 leadership interview questions which you must prepare in advance
 

Have you ever noticed that the questions asked during leadership interviews are so easy and everything went so well but still you were not selected? Or probably you could have answered slightly different then what you did. The questions seem so easy but your selection would be decided not based on how many questions you answered but the quality of your responses.  The key is to prepare well and that’s something many of us don’t do it very well. Whenever you go for an interview, you must write down all the questions post that interview and think through that what you could have answered or how would you have responded. The preparation is most important. If you attend 10 interviews, you would find, a majority of the questions are keep getting repeated. I am not providing an answer to any of the questions listed below as the answer depends on your role, the company you are going for an interview, culture, future expectations etc. etc.  There is nothing wrong or right in leadership interview. It is all about how do you articulate and respond to different situations. Following are must prepare questions well in advance in order to increase your chances of not only higher success rate but getting better role and money.

1. Tell me something about yourself?

Tip: You know too much about yourself and it is quite tough to articulate the most important part upfront. Prepare well for this question. This is something you would hear almost all the times in some or other form.

2. Explain your current project/s and your role?

Follow up question – Sell your product to me.

Tip: Preparation is key here as well. What you are talking should show your knowledge and strengths. Don’t forget to get that aligned for your job you have come for an interview. If you can answer “what is there for me” from interviewer perspective, you have won half the battle.

3. What is your biggest weakness?

Follow up question – What did you do to overcome your weakness?

Tip: This is the question where interviewer expects you to open up and further wants to know what you did about it. It’s not a perfect world.  It’s highly impossible that individual doesn’t have a weakness.

4. What is your biggest strength?

Follow up question – How did you leverage it to support your organization?

Tip: How can you align that with your upcoming job needs?  You’re a great cook but does it really help?

5. How do you motivate your team?

Tip: Provide your answer with an example.

6. How do you manage conflicts between two members or among the team?

Tip: Answer the question and justify with an example. Everyone can talk bookish theories while implementation gets more priority in this case.

7. Why should we hire you? What is that you could do which others can’t?

Tip: You should know your prospective company where you are going for an interview well in advance. Moreover, you should talk about how your success and knowledge align with interview company’s expectations.

8. Did you ever fail? Did you make a blunder? A decision what you have taken and you regret it?

Follow up question – How did you later get that corrected?  What did you learn from it?

Tip: Fail faster succeed sooner. If you have never failed either you are a god which is highly unlikely or you are faking it. Talk about the situation and be ready for follow-up question as an interviewer is more interested in knowing what did you learn and how would you avoid that situation in future.

9. Where do you see yourself in next 5/10 years? What are your short terms and long term goals?

Follow up question – What are you doing to achieving them?

Tip: You must be able to justify for what you say. I have seen people saying software development or managing a larger team but unable to align that with their future goals.

10. What is your passion? How do you keep that alive?

Tip: I say, my passion is reading and when asked what the last book you read is, you don’t have a concrete answer. Weird? Off course yes.

11. What are your salary expectations?

Tip: If you don’t plan this question or prepare to answer in advance, it is highly unlikely that you will be able to convince your interviewer with real expectations.

12. What do people criticize about you?

13. Why are you looking for a change?

Tip: No company is perfect and there are always challenges. Don’t talk ill about your current organization.  

14. What is the most difficult part of being a leader?

15. Tell me a situation where you had to make a tough decision which was supporting your company’s goal while that had a short-term financial impact?

Tip: Leaders take big decisions and you are one among them. If you are instruction follower you are not a leader.

16. Would you compromise your team member pride over company’s purpose?

Tip: There is no perfect answer for this. It all depends. To you, what is right is more important. You should have an example else you are in deep trouble.

17. What are three most critical things for you as a leader?

Tip: As a leader, one of the best things which I learned are people, business alignment and building relationships.

18. Did you ever fire anybody?

Follow up question – What is the process? How did you go about it?

Tip: Be honest about whether you have done or not. In this competitive world, you have to let go non-performers. You must know the process around it. (Read about Performance Improvement Plan)

19. How do you handle stress and pressure?

Tip: It is very obvious that you will have challenges. You can’t say that everything is great and I manage them so good. If that’s the case, you may not be even looking for a change.

20. What is your biggest achievement in your career as a leader?

Tip: If you don’t prepare, you may answer right but chances are slim that you would be articulate it well.

In case if you encounter any other question/s which you found it interesting, please post it in the comment below. Thanks in advance!!

TDD (Test Driven development)
 

There are lots of practices that need to be followed while doing XP as an agile methodology. And one of them is automated testing. However, there is lots of confusion in the tech industry if you want to test the behavior of the system or the subunits/parts of the system. First, lets us understand these terminologies. In this post, we will talk about Test driven development.

TDD (Test Driven development)

TDD or Test Driven development is an approach in which unit tests drive the development of the code. That is, when there is a new feature that needs to be developed, the unit tests corresponding to the feature is developed first before the actual code need to create the feature is coded.

Let’s take an example. Let’s say at a point of sale system, we need to calculate the bill based on the list of products picked by the consumer. Let’s write unit test corresponding to this code. (I have used C# based XUnit as the unit testing framework)

        [Fact(DisplayName = "SimpleBiller Should Calculate Total bill Amount")]
        public void SimpleBillShouldCalculate()
        {
            //Given
            var ProductsList = new List();
            ProductsList.Add(new Product { Name = "test Product1", Price = 5 });
            ProductsList.Add(new Product { Name = "test Product2", Price = 5 });
            var simpleBill = new SimpleBiller();

            //When
            var bill = simpleBill.GenerateBill(ProductsList);

            //then
            Assert.Equal(10, bill.TotalCost);
        }

In the above Unit test, we have 3 parts.

  • Given
  • When
  • Then

Given

This is the known part of the problem. i.e in mathematical terms, it’s part of the problem. In the example, we have initialized the variables and known things corresponding to the products (selected by the consumer) and the Biller object.

When

This is the business action based on which we are writing the code. In this case its GenerateBill action/method.

Then

The purpose of the tests is to ensure that the code/action does it properly as per the plan. In order to do that, we are asserting the assumptions/result of the method we are testing. In our case, we are asserting the total amount that the bill will have to be generated for.

Running the test

There are three stages of running the test.

  • Red – When we run the test now, it will fail as there is no code corresponding to the calculate bill functionality.
  • Green – In order to fix the above test, let’s write the real code corresponding to the above unit test/requirement.
        public Bill GenerateBill(IEnumerable products)
        {
            var bill = new Bill { Products = products };
            foreach (var product in bill.Products)
            {
                bill.TotalCost += product.Price;
            }

            return bill;
        }

Now, when we call GenerateBill method from the test, it will return the Bill with the total amount.

  • Refactor – With the above code written corresponding to the test, we are sure the functionality is correct as per the requirement. But the code is not optimal, as the foreach loop can be reduced to a simple C# LINQ  expression.
        public Bill GenerateBill(IEnumerable products)
        {
            var bill = new Bill { Products = products };
            bill.TotalCost = bill.Products.Sum(x => x.Price);
            return bill;
        }

Conclusion

TDD is a foolproof approach to developing software as per the requirement. The test also provides confidence to the developers on the edge conditions and other possibilities in the code. However, there is an alternative thought that TDD could waste developer time. Do you think, TDD is the right approach to software development? Please provide your comments.

Kanban – step by step implementation
 

You are ready to leverage Kanban in your project.  At this moment you are convinced that Kanban works, it could be a good tool for your project and you understand when this is to be used. The big question is how to go about it.  Let’s discuss that in simplest possible manner.

Visualize your work and existing resources – You need to understand answers to following questions.  What kind of work or EPICs do you have? How long it to complete them?  How many team members you have? What are their capabilities? Customer priority? Release cycle?  What is the existing set of processes used at your BU or org level? How do you get work and what is the priority? The delivery expectations?

Setup Kanban Board – Once you have an answer to #1, you can set a Kanban board. For that, you need various stages, criteria (Definition of complete for that stage in order to be ready to move the item to next stage). You can have a white board and sticky notes to build your kanban board. You can leverage tools like Trello instead of leverage whiteboard/sticky notes.  This may change over a period of time hence starting with Todo, In Progress and Done stages can be a good idea.

Define WIP limit – The WIP limit is assigned to each stage (Represents individual column). The WIP limit restricts team to add more items in the specific stage. This literally removes lots of waste. It does not allow you to focus only on one stage instead encourages continuous production.

Identify and Define Roles and Responsibilities – Kanban doesn’t prescribe specific roles but it is a good idea to have a product owner, scrum master and team member roles. Although in typically Kanban projects, the role of SM is very limited.

Start working – Start working on the model. Don’t be rigid on the number of stages, WIP limit, roles, and processes. This gets better over a time. Do not break the WIP limit rule. If you think the limit you set is not right, change it. This is most adaptive process hence most learning will be on the ground. The processes can be adjusted as you move forward.

Matrices/reports – You can have utilization, productivity, cycle time and other matrices. Do watch it closely as this would help you to stabilize the process per company need.  The cumulative workflow diagram would be a really good choice to constantly monitor as it gives you very clear picture in terms of where the project stands.

 

Kanban – Let’s get started
 

Kanban (refers to visual board or billboard in Japanese) is a lean scheduling tool that works on JIT (Just in Time) manufacturing concept. The JIT is a model in which products are built to meet pressing requirements over building it in excess.  This helps to improve productivity, reduce waste by limiting work in progress items, support continuous delivery and maximizing customer value.

Kanban board is a visualization tool as shown above.   The number of stages could of any number depends on your need. For instance, in my previous project, we were using

  • To Do – When the item is groomed and ready to be picked
  • In Progress – The item is picked and being worked on.
  • QA – The development is completed. It is ready for integration testing.
  • Done – Delivered to the customer.

The stages and conditions as I described earlier are subject to individual need. The Kanban process is highly Adaptive.  It does not prescribe any roles. Let’s look at some of the processes or tools in specific order (rigid to adaptive)

Waterfall – More rigid
XP
Scrum
Kanban – More Adaptive

The work in progress plays a critical role. This ensures there is nothing at any stage over produced which result in reducing wastage. There is not a secret formula to set a WIP limit. All you have to look at is how many members you have in time and how many items they can work for you to have expected utilization. When you start, it is perfectly alright to have wrong WIP limit. You can always change it as you move on.

Just to make it more clear, this is how I set up WIP limits for my previous project example where my team size was 11. All of them used to play the role of Developer as well as QA.

To Do – 5  – Wanted to restrict to a number of groom items as we had customer dependency to unblock individual item (Access and other dependencies). Once we get the access to customer environment, we cannot wait for a long time to get started on that.

In Progress – 6 – I always wanted individuals to focus on QA as well as unblocking backlog item to continue the flow hence I limit this to 6.

QA – 2 – Sound interesting. Isn’t it? Well, anything which is dev-done (typically takes 3-4 weeks of development), the QA work was limited to 2 days. Anything which reaches to QA, should be quickly completed and delivered to the customer so that I can recognize my revenue. The advance of two is, an individual must complete it in order to move dev complete items to QA. If the WIP limit is full, even an item is dev complete, it used to remain there.

In addition to above, I kept WIP limited to leverage pair programming benefit as well. I wanted on complicated items folks to pair program. The above number, I reached over a period of time. The initial WIP limit turned our to be wrong which was expected.

The Agile Methods explain some of the core frameworks or agile process tools similarities and differences.

Please refer the following blog for step by step process to implement Kanban in your project.

Kanban – Step by step implementation

Planning & grooming process for distributed (not co-located) agile teams
 

Most agile frameworks encourage team co-location to have

  • Better communication, mutual trust & respect
  • Better alignment and support
  • Lesser operational costs and smooth management resulting in a better outcome.

All of these are designed for achieving better results as a team. Unfortunately with globalization (offshore/onshore model), there are very few teams that are fully co-located.

In such a scenario, sprint ceremonies are often challenging when you are following Scrum or XP model. In this article, I am going to focus only on planning and grooming ceremonies. I have tried this approach in many teams in the past with significant success.

Planning and Grooming
Agilechamps – Planning and grooming

Assumption

In order to better understand the model, let’s assume that you have one sprint team with 12 members split equally into two teams and separated by multiple time zones. The product owner and Scrum master are co-located and duration of each sprint is 2 weeks long, starting on Tuesday. Assume the team velocity is 40 story points, completing approximately 10 features and 10 bugs in a given sprint on an average.  For this example, let us assume the teams to be located in India and the USA J

Approach

The product owner tries to ensure that at least 2 sprints worth of work is well prioritized at any given time. The team focuses on getting sprint work done during the first week of sprint. The team assumes 10 hours’ time for each USA and India team in each sprint to pre-groom stories. The teams spend some time each day pre-grooming stories and creating tasks during the second week of the sprint along with the continued effort towards their existing sprint goals. The goal of this exercise is to ensure that both teams have enough clarity on stories to be able to start working on them from day one of the upcoming sprint.

During this period (the second week), individual teams should communicate with the product owner or other members of the team to retrieve as much information as possible to flesh out requirements and discover potential blockers.

While this may appear a little tough in the beginning, it gets better over time as team members gradually become accustomed to the code base and business functionality, and are able to make better-educated guesses and assumptions about the stories. Initially, teams might even find themselves spending close to 10 hours a week in these activities, but the time needed drops off significantly in due course. This is especially true for teams that are less exposed to business or may be newly formed.

At this point, both teams have a better understanding of stories what they have groomed. During the planning meeting, both teams talk about each story they have groomed. I would personally suggest teams conduct sprint planning meetings on the last day of the sprint. This ensures that the first day of the next sprint is not wasted deciding what to work on.

Pointing stories is a group activity where inputs from all stakeholders can be considered while assigning points to stories.

Both the team collectively go with sprint commitments after the planning meeting.

Benefits

  • Combined planning meetings are short as at least one of the team has clarity over requirements for each story. I have often seen individuals get on to planning meeting with little or no knowledge about stories resulting in long meetings. This also results in only one team being engaged in the meeting while the others become impatient and disengaged.
  • Product owners are human. It is normal for them to not have all the answers up front. This approach gives them sufficient time to gather missing details; details that they might not even have considered necessary unless brought up by developers
  • The team gets enough time to groom stories since they often have questions for the business owners or for other teams that are easy to answer, but a response needs a turnaround time of a day or two because of time zone differences.
  • The team who has less context on business come up to speed with business, processes, and resolving dependencies wherever applicable.
  • A geographically split team doesn’t mean individuals have to work in isolation.

This model helps teams realize a number of benefits which include (but are not limited to):

  • Improved quality
  • Better commitment
  • High productivity
  • High morale
  • Better team bonding
Azure Functions in plain English
 

AWS Lambda and Azure functions are truly next generational in the sense of the cloud computing. These services simplify the amount of time it takes to move to a cloud-based solution. Following are some of the advantages of running services directly in functions/Lambda.

  • No infrastructure code
  • Easy scaling
  • Easy deployment
  • Gives focus on the business

In this article, we will explore how to create a simple azure function and execute it in simple 5 steps.

1.  Search for Functions in the Azure Portal and select it.

2. Click on “Create” and Create functions form should appear.

3. Enter the App Name, Subscription, Location and select “Create”. After it is created, you should see a page like this.

4. Select “Functions” from the left menu and on the right side select “Webhook + API” and click on “Create this function”.

5. Below screen appears where you can write code for the function and deploy the same. Edit code and select “Run” to update the deployment and run.

That’s all and functions are as simple as that. Hope this article helps in creating functions with Azure simpler. Please feel free to post your questions in the comments section.

Estimation – Planning Poker
 

What is a planning poker (& Facts)

  • Planning poker is a consensus-based technique to estimate the effort in an Agile project. It is sometimes referred as scrum poker as well.
  • Performed using a deck of cards (referred as planning poker cards). The Fibonacci sequence (i.e. 1, 2, 3, 5, 8, 13, 21, 34…) are printed on cards (most popular and widely used). One can use any other sequence which suits your need. For instance, doubling card numbers (1/2, 1, 2, 4, 8, 16, 32…) is quite popular as well. These numbers represent story points.
  • You can leverage software tools(tons of tools available online) over cards to make the process easy and compiling estimation for each story.
  • The teams come to approx estimate and keep getting better with time.
  • It’s a collaborative effort and team activity. The entire team is expected to participate in this activity. If your scrum master is going contribute technically then he/she should participate along with programmer, testers, DBA etc. If the scrum master is not going to contribute technically while he/she has a solid technical background then it is advisable to include him.
  • The PO may be included too if he/she has strong technical background.
  • It is derived from WBD (Wide Band Delphi), Analogous and WBS (Work Breakdown Structure) estimation methodologies.
  • The stories should be broken down enough so that estimation will not go beyond. One general rule is to break down the tasks further if it is scored 13 or above.  There are instances where you cannot really do that while in most cases it’s not very tough to do so.
  • The voting option can always be used when there is a conflict in estimate post discussion.
  • If the estimation is done using story points then its easy to sum them up to match velocity so that sprint commitment can be made.  The hours is not advisable as by definition user stories are a high-level description of functionalities hence chances are slim to get close to accurate hours when estimating.

Implementation

  • One of the team members is selected as moderator (Typically product owner or scrum master)
  • Every individual is given deck of cards with numbers printed on it. If the software product is used over cards, a session is created and everyone logs into that to select their number for every story.
  • The moderator reads out the story loud with all the details. The whole team discusses to ensure everyone has a fair understanding and missing items are covered.
  • During this discussions, any question which comes with respect to functional details, PO answers that.  Remember, it’s a collective effort hence anybody who has more context can clarify the doubt though a final decision is taken by PO when it comes to functionality.
  • Every individual secretly selects his/her card representing their estimate which is later shown to the rest of the team once everyone is done with their estimate for a given story.
  • If the entire team come to the same estimate, it becomes an estimate for a given story.
  • Team members which have higher or lower estimate compare to rest of the team would explain their viewpoints.  The team can take some time to discuss that further. If needed, this process is repeated for the same story or the whole team agrees on one final number.
  • This estimation process is repeated for every story.
  • It is perfectly alright to have a varying estimation as the team gets mature over a time and moreover, understanding of business and technology will keep getting it better.

Benefits

  • Better understanding of requirements because
    • The entire team is involved in estimation and
    • Discussions around each story specifically unknown areas.
  • It’s easy and a fun way to estimate.
  • The estimates are not dumped instead its collective team estimate. This leads to high morale, a greater sense of ownership, team responsibility and commitment.
  • Everyone has a say on the estimation. The equal voice whether an individual with zero or 10+ years of experience creates trust and positive environment.
Should I start thinking about switching from Scrum to Kanban?
 

I want to release anytime, I don’t want iterations, I want to skip estimation, I have challenges with self-organising teams, I want to change my priorities,  I need better visualization, I want to process that is more adaptable, Scope creep is my major concern, I am want to handle support tickets,  I am afraid of sprint failure and end of picking less work, I can’t break down stories enough to complete within sprint.

Scrum is great while the world is not a perfect place. You can always overcome challenges associated with it but if you have another Agile method is even more flexible there is no harm in leveraging that. I see many organizations are switching to Kanban and getting wonderful results. I don’t have the intention to move you from what you have been doing while I am just trying to initiate a thought process and philosophy around Kanban.

Let’s understand above in more detail with real time scenarios. A group of project managers gathered to discuss the challenges they have with the existing process with senior management.  Let’s look at some of the interesting areas what they have put forwarded on the table (I am sure you can relate one or more areas if you have managed agile teams)

 

Project Manager 1: (Team is afraid of Sprint failure) My team have very fewer items in sprint compare to what they can accomplish as they are scared of sprint failure.  Despite that, I don’t have successful sprints as one or items roll most times as we get blocked. I can’t allow my team to pick more middle of a sprint.

Project Manager 2: (Prod issues; Lot of support to other teams) My team builds new feature while I am expected to support some of the other teams for whom we provide back-end services. The requests coming from them is our top priority whenever it’s related to prod for them.  The amount of work which comes from different teams vary and we cannot assign fixed bandwidth to deal with those issues. Most of our Sprint we have one of these two situations

  • The sprint fails because we need to focus on supporting other teams.
  • We are done much before the sprint ends.  Pulling new work is not allowed mid-sprint hence we use that time for learning while this is not a great idea all the times.

Project Manager 3: (Support work; Tickets) I have all the support work. The estimation has been a challenge most times. A bug takes a day or a week, all depends as the product I work for is huge and we have most of newer members.  How can I make sure my sprints are successful and at the same time, we as a team don’t under commit?

Project Manager 4:  (Adaptive to more adaptive) My team hates too many ceremonies and processes. They think of having a lightweight process which is more adaptive over prescriptive,  is much better. All of them are experienced/committed and understand their roles and responsibilities.

Project Manager 5: (Time and material; Longer stories; Unpredictable work) We built adapters and I don’t see the benefit of breaking down and doing that in parts. We have a deadline for every adapter and we kept getting blocked. We are fine to wait as we are on “time and material” contract. Getting blocked from customer end doesn’t harm as billing don’t stop.  How do I fit in a work which takes few weeks to a couple of months?

Project Manager 6: (Frequent priority shiftOur priorities changes very frequently.  Many times we literally have to stop what we are working on and start something else. Getting new work done in next sprint doesn’t help as the work we are doing becomes useless even if that’s completed due to change in priority.

Project Manager 7:  (Customer or Sprint successOur company’s top priority is to manage customers and their expectations while we always focus on velocity and sprint success. This becomes challenging as in order to manage customer priorities, we compromise Scrum priorities or vice versa. Both are not good ideas. In the first option, you are disregarding a process resulting in low team morale and unpredictable outcome.  The later is not acceptable anyway 🙂

Project Manager 8: (The product owner struggles) The PO struggles to lock down the requirements for a week. He keeps adding work to sprint throughout the week, changing existing requirements and even providing/updating acceptance criteria during the sprint.

Projects Manager 9: (Team experience or complex work) My team has challenges with breaking the requirements or estimating the work.  The sprint success matters most to me (Why-Sprint-Success-is-Important). I end up being unhappy most times.

Kanban could be one of the solutions for most of the problems listed above. The comparison of Kanban with Scrum/XP and some of the core frameworks is available here

The Sprint success is really important when you talk about Scrum. The Sprint fails due to the variety of reasons like team experience, The challenges with breaking down stories, unpredictable work, Customer focus precedes team priorities, support work and many other challenges as listed above. In many times either we run too much to having successful sprint (By means of slogging or patch up work) or do not think of successful sprint at all. Both are not good options.

In my upcoming blogs, I would be talking in detail about how to use Kanban, best practices, myths and an easy shift from existing process to Kanban. Please provide your comments below. This would help me to cover all aspect in my next set of blogs on Kanban.