Ok so you’ve got an interview, and they want you to write some code. They are checking whether you know what you are talking about. Someone with a good proceess will stand head and shoulders over someone without a process. Software development is about employing standards and processes, so you can write good, reliable code that’s easy to maintain, and easy to alter without it breaking down. They are not interested in the answer, so much as how you got there.

Solving Software problems - methodology

Since this is an interview question, then they want to see how you approach the problem. They won’t look too much at your code. In fact they might take someone whose code doesn’t even work, but who’ve ticked all the other boxes of the things they want.

This is how i would approach the interview:

1. Find out exactly what they want.
2. Provide your code.
3. Justify your code to them

Find out what they want

(i) will this code every be changed? (ii) do you want it testable? (iii) how many decimal points do they want? do they want it produced with agile techniques? (iv) how long do they want you to spend on it? (vi) e.g. what knowledge do they want to see: design patterns, OOP principles, procedural code ??

The answers to these questions will dictate what you will write in the interview and in the real world.

justify the code and the decisions you made

e.g. The above code is the best because blah blah blah

• It’s short

• It’s understandable

• It’s testable.

• Don’t have to reinvent the wheel.

• I’ve saved you $$ but delivering the project super quick with low maintenance.

In my opinion, building software is more about understanding and meeting needs/requirements rather than actually coding. Doing the above might push you a long way towards getting selected.

I hope this helps.