Greenfield Projects: Interviewing Technical Candidates

How do you ensure that you recruit the right developers for you team? The interview process is important and focus should be on both technical skill and team fit:

A three stage approach is useful:

Stage 1:  The pre-screen ensures that a basic technical level is achieved by the candidate and this can be undertaken by the recruitment agency and HR team.

Stage 2:  The telephone interview gives the opportunity to delve deeper into the candidates technical knowledge and get a feel for how they define quality and ways of working.

Stage 3:  The face to face interview should remove any doubts form the previous code exercises, give both parties an understanding of the expected ways of working and establish a good team fit.

Pre Screening

A Kata that the candidate can complete at home and submit for review was used to screen candidates.  A Kata was selected from one of the many that can be found on the internet.  The Kata below is an example Kata that could be used:

The String Calculator Kata

Try not to read ahead, Do one task at a time

Make sure you only test for correct inputs. there is no need to test for invalid inputs for this kata

String Calculator

1. Create a simple String calculator with a method int Add(string numbers) The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for example “” or “1” or “1,2”
   1. Start with the simplest test case of an empty string and move to 1 and two numbers
   2. Remember to solve things as simply as possible so that you force yourself to write tests you did not think about
   3. Remember to refactor after each passing test
2. Allow the Add method to handle an unknown amount of numbers
3. Allow the Add method to handle new lines between numbers (instead of commas).
   1. The following input is ok:  “1\n2,3”  (will equal 6)
   2. The following input is NOT ok:  “1,\n” (not need to prove it – just clarifying)
4. Support different delimiters
   1. To change a delimiter, the beginning of the string will contain a separate line that looks like this:   “//[delimiter]\n[numbers…]” for example “//;\n1;2” should return three where the default delimiter is ‘;’ .  The first line is optional. all existing scenarios should still be supported
5. Calling Add with a negative number will throw an exception “negatives not allowed” – and the negative that was passed.if there are multiple negatives, show all of them in the exception message
6. Numbers bigger than 1000 should be ignored, so adding 2 + 1001  = 2
7. Delimiters can be of any length with the following format:  “//[delimiter]\n” for example: “//[***]\n1***2***3” should return 6
8. Allow multiple delimiters like this:  “//[delim1][delim2]\n” for example “//[*][%]\n1*2%3” should return 6.
9. make sure you can also handle multiple delimiters with length longer than one char

Knockout criteria and expectations for success should be established for the interviewers in advance to ensure each candidate is reviewed against the same baseline.  Success in the Kata leeds to a two stage interview process; a telephone interview and a face to face interview.

Telephone Interview

The telephone interview is used to gain an understanding of the way the candidate thinks.  Comprising of a collaboration coding exercise on a shared open source platform like http://collabedit.com/ and aptitude questions (ideas on achieving code quality, opinions of BDD/TDD, how to achieve Continuous Integration/Continuous delivery, software patterns, SOLID Principles, etc.)

Code Exercise:

Count the number of words in a string (including new lines) without using split.

Word String is as follows:

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 and 1.10.33 of “de Finibus Bonorum et Malorum”

The candidates should be asked not to use ‘split’ as the test is designed to review understanding of code structure and the candidates ability to think around problems.

The response required for this exercise is to return a count of all of the words within the string.  If the candidate did particularly well the second part of the exercise is for the candidate to discuss how they would count the unique words in the string or a file.

Face to Face Interview

The face to face interview should give you an idea of whether you will be able to work with the candidate, do they ‘fit’.  Ask questions around your work ethic, their attitude to criticism (Both about their work and the work of others), how they would start work with the team, their understanding of the delivery environment.  A conceptual code exercises can also be helpful, try a whiteboard session.  Coding without an IDL can indicate a candidates ability to conceptualize and think through a problem without using ‘quick tools’.  A code exercise with an IDL is useful for indicating how quickly the candidate can come to terms with a new problem in a real world situation.

Whiteboard session;

Given an array of length N objects

 

Where the objects can be one of three colours red, green and blue

 

Write an algorithm that’ll sort the objects 

 

you’re not allowed to use .sort().  Do use fundamental principles.

For more heavyweight candidates it is important to see they have a top down view on the program as a whole.  Take an actual problem in the code being built and ask the candidate to architect a service solution.

Measuring Code Quality

Code quality is vital for true continuous delivery in an agile environment.  Teams need to be sure that their code quality is at a standard that will not break the build in order to allow fast progression to live.  Teams also need to ensure they have a good quality continuous integration / continuous delivery pipeline.

In order to assess code quality across the business you will need to set a baseline.  From that baseline outline steps to show both the improvement of the team and of the business as a whole.

I used the grid below to work with my clients key service teams to create a code quality maturity baseline.

The example baseline table below gives clear indications of where effort was required for improvement  1.  In each of the teams (Viewing vertically) and 2.  where to focus effort across the business as a whole (Viewing horizontally).

Initially teams may be resistant, they may not want to discuss ‘code quality’ and have their service reviewed.  Work with Senior Team members to make it clear that the purpose of the review is not for reprisal, but to see where the business is currently and how the collective could improve and deliver benefit to the customer.  Combine this with a demonstration of the benefits of TDD (Test Driven Development), good Unit Test Coverage and the use of tools like stylecop and sonarqube through a working scrum team delivering shippable software on a two weekly sprint cycle to change attitudes.

In my experience, teams will began to look to the demonstration scrum team for ‘what good looks like’, joining the scrum ceremonies especially the retrospectives.

For my client, shippable code quality improved with the teams taking part in the programme.   Commits did not progress if they broke the build and acceptable test coverage was set at 80%.

Branching – A basic branching strategy

As you get more developers on your team you will probably need to think about branching in your source repository.

In a recent project the team were using GIT as a source repository and Jenkins for Build, Unit Testing and Integration Testing.

Sprints were managed in Jira and branch names were mapped directly to Jira card numbers. (The format was feature-x where x is the numerical id of the card. So, If I was working on card DCAP-123 my branch would be called feature-123.)

The diagram shows the process with a ‘Spike’ branch under construction to allow the team to work on experimental features.

Burn down or burn up – which is best?

Well it kinda depends on what you want to show to your stakeholders:

Burn down charts are great for showing progress in a sprint.  you can show Work in Progress (WIP), the actual burn and the ideal burn.  These three will give stakeholders and team members a snapshot of where you are in your build.  You can use it to give focus to certain areas to close the gap between ‘actual’ and ‘ideal’.  Burn up charts show the amount of work remaining on a project and a projection of work completed based on the current velocity of the team.

Burn-down charts have the advantage that they’re simpler — they only show one line.  However if you can stand a little complexity then I’d recommend burn-up charts as the more useful option for release management and stakeholder management.

Burn Down Charts

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.   The Scrum Master updates the values for WIP and actual burn after the daily standup.

Burn Up Charts

A burn-up chart tracks how much work remains on your project and whether you’ll hit your deadline. The vertical axis measures work remaining. The horizontal axis marks your iterations, and you should mark which iteration is your target end date for the project. After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date.

 

You can make burn up charts more sophisticated, showing  several scope lines, one for each release milestone. This way the team and the stakeholders can see the effects of, say, moving scope from one release to another.

Statements of Work – What type of thing should go in?

When you are putting together a team to deliver a project sometimes you may have to take on people under a ‘statement of work’.  The ‘Statement of Work’ should reflect what you want the individual to achieve during their time on the project.  The Statement of Work should be detailed and succinct, but you can find a good starting point with the headings below:

• Purpose: Why are we doing this project? This is the question that the purpose statement attempts to answer.
• Scope of Work: This describes roughly the work that must be done in detail and specifies the hardware and software involved and the exact nature of the work to be done.
• Location of Work: This describes where the work must be performed. This also specifies the location of hardware and software and where people will meet to perform the work.
• Period of Performance: This specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.
• Deliverables Schedule: This part lists the specific deliverables, describing what is due and when.
• Applicable Standards: This describes any industry specific standards that need to be adhered to in fulfilling the contract.
• Acceptance Criteria: This specifies how the buyer or receiver of goods will determine if the product or service is acceptable, what objective criteria will be used to state the work is acceptable. See Acceptance testing
• Special Requirements: This specifies any special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.
• Type of Contract/Payment Schedule: The project acceptance will depend on if the budget available will be enough to cover the work required. Therefore payments breakdown whether up front or phased will be negotiated very early at this stage.
• Miscellaneous: There are many items that do not form part of the main negotiations but are nonetheless very important to the project. They seem minor but being overlooked or forgotten could pose problems for the project.

Of course, if you are writing a Statement of Work you should always take professional advice to ensure you have covered everything, and this post shouldn’t be taken as a definitive guide.