(1) The Open Question (5 mins)

What makes you a good developer? When you start to write a piece of code what are you aiming to do other than fulfil the functional specification?

Mark Did they have a development strategy?

[0] [1] [2] [3] Comment:[ ]

How did they perceive themselves to be good developers?

Comment: [ ]

The Candidates Approach (10 mins)

(1) Appreciation of how to construct good software?

• What are interfaces for? How do they help you design a system? (Interfaces define by contract).
• How can inheritance go wrong?
• What might you do about it?
• When do you think copy and paste is acceptable or unacceptable as a development methodology?

Mark

Do they know how to write good software?

[0] [1] [2] [3] Comment:[ ]

(2) Attitude to coding – (Pick one or two from this section)

(a) The Pragmatist: You are coding a change and some of the existing code and it is a real mess. The mess has almost certainly just grown up over time. You think you can sort it out in about 20 mins and the testing will be covered in the work you are doing.

Do you make the change?

[yep, if they say no then check what they quantify to be small enough to change]

When would you not make the change?

[when the testing is way beyond the scope of your change or there was significant question over the business logic. In the later case you might chat to your boss about it]

(b) The Big Picture Improver: You are implementing another change and you see that something has been done really really really badly. It is so bad that it takes you 3 days to work out what is actually going on. Once you have done it you realise that there is a much simpler solution that you could code up in a couple of hours that would sort the whole thing out.

Do you make the change?

If not what do you do?

[no you chat with your manager about it]

Mark a) Did they appear pragmatic?

[0] [1] [2] [3] Comment:[ ]

b) Will they take an active role in improving the app or do they just code what they are given?

[0] [1] [2] [3] Comment:[ ]

(c) Understanding Testing during Refactoring: You are refactoing a piece of code. In that piece of code there are a few statements that you don’t think do anything useful. You want to make a clean break in the new piece of code and don’t want to include any unused functionality.

The piece of code is reused a lot so the testing burden is high. Your options are:

1. Move the code as is to the newly refactored class
2. Remove the code and remember to check it at the end.
3. Do something else.

(Explore what they think in this situation. Do they mention testability of the code?)

(b) Your boss tells you he doesn’t think that code is used. How does that effect your decision?

[either do it but make sure you have sign off that it is on his head or do something else]

(c) The code resets an id to 0. You think this reset will have been performed already in all relevant cases. Is there anything else you could do?

Mark (a) (b) (c) Did they make an attempt to get rid of this potentially useless bit of code? Did the way that they dealt with it seem plausible?

[0] [1] [2] [3] Comment:[ ]

(3) Testing Methodology

You fix a bug. You are new and this bug is in a highly reused bit of code.

How do you test it?

How do you establish that you have covered all the test cases?

[You ask about. If you are not sure you note the test cases that you have made and submit them to the test team when the code goes to testing.]

Mark Do they invoke confidence that they can test in a code base they don’t understand?

[0] [1] [2] [3] Comment:[ ]

(4) If design skills are not up to par:-

How do you feel about being mentored?