Habanero Jelly

I struck up a great conversation with a friend while we were socializing over the weekend. We were drinking beer and doing what we could to help make some habanero jelly. Making these spicy jellies has become a bit of a hobby for me lately - it's strangely satisfying to see 20 or so new jars of yumminess sitting on the counter after a hour or so of toil. I find it also particularly good and keeping me distracted from all the other things that rattle around in my head... not this time though. Something got planted in there that I couldn't get rid of.

The Google Spiral

So, back to the conversation: this friend is a electrical engineer/programmer type who has applied for various roles in his time - among them, Google, Samsung etc. I began wondering what they ask you during job interviews and he said that he's generally asked some kind of programming question. My ears pricked up and I wanted to know more.

After some thorough interrogation I managed to glean the following:

You have to work at solving the problem in front of them - discussing and working through it
C++ seemed to be the language of choice for anyone taking one of the roles he was applying for seriously
The number of whiteboard markers you're given varies, but can be as low as one...
His favorite/most memorable question he was asked was to develop an algorithm for a spiral search around a bitmap type image, starting in the top left corner and working your way around the edges towards the centre.

As best as he can remember, the above question was asked by Google, and it took all my restraint (and his too I think) to talk about what happened without him telling me anything about the solution or any tricks to solving it. We were both keenly interested to see what I would come up with in my own time.

Is it what you've got or how you do it?

As we were talking we did agree upon one thing, and that was that the interviewers were clearly looking for someone who could clearly communicate to them (during the interview) their thinking, logic, process, challenges and outcomes. And I'd like to further argue that you might be able to pass that interview question with flying colors without knowing a single line of C++ code, but by demonstrating your appreciation for the process of making software work, be good, reliable, understandable and unbreakable.

WHERE DID THE SPIRAL TAKE KODA?

Those that know me well can probably guess that as soon as our guests left, and the door closed behind them that I was scribbling away on a piece of paper. If you thought that, you're correct. I scribbled down some thoughts, potential issues, got a feel for the problem, and what I might need to solve it.

I spent probably 15 minutes scribbling away. Then, about 15 minutes fleshing out the framework of the solution, then about 30 minutes writing the code. For this particular problem, I'm happy to report that my approach worked first go.

There are a couple of lines of code that I am not 100% happy with - but I'm sitting on the fence. Those lines of code are needed because I didn't want to rely on assumptions to solve the problem, but instead build in situational awareness into the algorithm for decision making. The best way to explain this is by understanding how you would exit the routine: would you calculate a total number of steps based on the dimensions of the rectangle (width x height) OR use a no-more-valid-moves test to close out the solution. I prefer the latter.

What kind of attributes would koda look for?

Boundary conditions - how the code starts, stops, and any particular cases that might throw the algorithm off
Appreciation of the reason why you'd possibly be needing this code
Someone who doesn't rush in to implementation
Someone who considers testing as much as usage
Understanding the nuances (or at least attempting to) by breaking the problem down
How well you can communicate your thinking while you're talking it through to us

A comment about comments

Comments are invaluable - except when the comments you write are useless. Don't get bogged down in the idea that you need to describe each single step you take. Also, don't write down what you're doing - usually that is obvious and often WHY is vitally more important.

I can see you're assigning x to y with the phrase:

//Assign x to y
y = x

The following would be much more useful:

//y always takes the value of x after cycle is complete
y = x

Dust off Excel and Write some code

I'd love nothing more than to receive a few solutions to this problem. I used Excel VBA so that I can share that in a couple of weeks time. Before then, I'd love to get a few responses from anyone interested in contributing. I'd love to see how your brain works and see how you attack the problem.

Until next time, KODA