I went to CA Tech today (ca.com) for a possible position on their team.  I highly enjoyed the opportunity, but of all the interviews I’ve had, this one was more interesting because of the thoughts I had after having time to reflect.

This follow-up interview consisted of meeting the team, introducing the company, and the interesting part: a skill exercise.  There were 4 possible exercises to choose from, which were worked on with 2 employees on another computer, both computers controlling the process as needed.  I selected to write a Poker routine.

At first, it seems easy, though after pondering the problem, you begin to realize there is some complexity in being able to tell that “Ah Kh Qh Jh 10h” is a “Royal Flush” hand.  And this is where I noticed (after having finished the process) that trying to solve this can be approached multiple ways, and some might seem obvious and some only become obvious upon reflection.

This is the point: while solving the problem directly by trying to just build the solution piece by piece shows your technical ability to find solutions, I had to ask whether or not it might also be appropriate to tackle the problem (at least in part) as one might an actual project.  It would be overkill to go through every project task process in detail, but couldn’t I at least work out the design conversation at a high level, just as one would when working on their team?  For example, we need: an object to represent what is in the hand and whether the hand is a real one you might get from a deck of cards, objects to represent each card in the hand including card rank and suit (a few others come to mind), and maybe a few other things.  The conversation could discuss the pros and cons of how far to modularize such a program, what kinds of tests to create, etc.

In the end, I’m not sure how interviewers look at such an approach, and one could definitely take the approach too far, but there is something to be said for being aware of a requirements process and the manner the requirements translate into a good development process, such as recognizing that in order to detect a straight hand, it will be really helpful to sort the results and keep more information on each card than just what it is called (rank, suit, etc.)  Once you have that conversation, it becomes more apparent that the efficient method is to use a sparse array for the entire deck, making it far easier to determine if a hand is a flush, for example.

Maybe next time one of us needs to solve a problem like that, talking out the issues first could help us candidates get to the best answer more quickly, and it helps interviewers see how we could be an effective team member.