Interviews and Coding Ability Gradation

I’ve had the chance to interview a few people lately. It’s just getting started, my calendar includes 3 interviews this week.

There are 2 parts to the interviews I give. In the first part, I like to talk about general interest in what’s going on in our field. In the second part, I ask people to code for me.

First Part: Passion

I ask about tech news websites that the applicant is using, if any. I ask about blogs that are read. I ask about RSS feeds that are reviewed.

I also like to ask “what’s going on right now in the industry? what’s the buzz?”

Another one I’ve been using: “what’s the next programming language you want to learn?”

I’ve been wanting to ask about portfolio. If you have been programming for a few years, I’d like to think you could show me something you’ve done. If we expect artists to bring a portfolio of their work, can’t we expect the same from programmers?

Personally, I’ve got 3 webapps up and running that I’d like to show and talk about. The thing you see in my glittering eyes and my wide smile is passion. I’m looking for that in others.

Second Part: Skills

At this point of the interview, I probably already made my opinion.

But I’d like to see some code too.

At first, I thought I would ask people to code: group_by. This is something I coded myself a few times, in Ruby for fun and in Javascript for practical purposes. However, I realized that it was not something I’d like to code under pressure. I decided to water it down.

What I used for the last 2 interviews was: any or all. Let’s just say that the results were not… productive. The problem with ‘any or all’ is that you either get it or you don’t. I needed better resolution.

One of the problems is that function pointers are just not part of the repertoire of most of the programmers I know. Thank you Javaschools!

I decided to change my approach. I decided to combine bullet-in-the-brain-easy programming with elephant-in-the-room function pointer enlightenment.

Here is the coding test I came up with. I’d like to get some honest opinions. Also, feel free to use it for your own interviews.

*** If you want to have a go at the test, everything that follows could be considered a SPOILER. (Thanks Fred) ***

Now, I believe there are 3 outcomes out of the questions in this test.

• brute-force code all 3 questions (worst)
• brute-force code all 3 questions but realize that there’s something wrong (better)
• abstract away the act of summing from what is being summed up (best)

I’m going for reactions, insights and skills.

I want to believe that I don’t have to resort to FizzBuzz.

I submit my own answers. I spare you the inner private class magic that would be required in Java.

Read Full Post »

history substitution vim trick

One of the tricks I’ve been using recently is:

vim `!!`

1. ` (backtick) which is used on the command-line to substitute, in-place, the result of a command
2. !! (double-exclamation) which is replaced by the history mechanism by “previous command”

In short: open in vim the result of the previous command, which would be a list of files.

When I’m programming I always have a shell open. I use that shell to find (pun intended) interesting files.

Here are some commands I could run iteratively until I find the proper set of interesting files. Note that I would usually only include the -l flag to grep after I have confirmed the content.

# all files, recursively, containing 'each'
grep -Ril 'each' *

# all rhtml files, recursively
find . -name '*.rhtml'

# all ruby filers, recursively, containing 'each'
find . -name '*.rb' -print0 | xargs -0 grep -Ril 'each' 
# -print0/xargs -0 credit goes to dmiessler's find page

# all subversion files containing conflicts
svn status | awk '/^C/ {print $2}'

On the command-line, you are only limited by your knowledge and your imagination.

If you are unsure what good these commands are to you, because you have “better tools”, I invite you to read Oliver Steele’s The IDE Divide.

Read Full Post »

explicit iteration considered harmful

Part of my journey, over the last year or so, to understand functional programming have led me to paradigm shifts and discoveries. One such discovery was: any? and all?.

Before going into the reasons of why these functions must be part of your toolkit, let me show you example code.

list = ['cat', 'dog', 'snake', 'crocodile', 'spider']

# any fit those size requirements?
list.any? {|x| x.size > 6}    # true
list.any? {|x| x.size < 4}    # true
list.any? {|x| x.size > 40}   # false

# all fit those size requirements?
list.all? {|x| x.size > 6}    # false
list.all? {|x| x.size < 80}   # true

# any is 'snake'
list.include? 'snake'         # true
list.any? {|x| x == 'snake'}  # true

# any starts with 's'?
list.any? {|x| x =~ /^s/}     # true
# all starts with 's'?
list.all? {|x| x =~ /^s/}     # false

The high-level description of any and all is that they are functions, part of Enumerable, that take a block. This block is a test that any element must satisfy or that all elements must satisfy.

What makes any? and all? interesting is that they are semantic. Suddenly, your code doesn’t just iterate over a list, it states its intent: I’m looking to see if any/all items fit that condition.

In fact, to me it makes such a difference in meaning, that I started to convince people I work with to use the words ‘any’ and ‘all’ when giving me specifications: “Do you mean to say that I should transfer to operator when any order has been cancelled or when all orders have been cancelled?” Not only does it forces people to be more rigorous when it comes to specifications, my code starts to look very eerily like the specification itself

transfer if orders.any? {|x| x.status == 'CANCELLED'}

Let me revisit this, any? and all?:

1. make your code shorter
2. more readable
3. semantic
4. closer to natural language and specifications

Let me push this further: in any language that supports higher-level abstractions and blocks/closures, outright iteration should be taken as a sign that you are doing something wrong.

Of course, sometimes, iteration is what you need. I won’t talk about those cases. What I’d like to communicate is that, more often than not, iteration is used in places where much better tools could be used.

In Ruby, some of the tools that could be used instead of each are:

• any?
• all?
• collect (aka map)
• detect (aka find)
• grep
• select (aka find_all)
• include? (aka member?)
• inject
• min/max
• partition
• reject

Referring to Enumerable might be a powerful productivity boost.

Armed with this knowledge, I’d like you to stop yourself next time you iterate over a structure and ask: “What am I exactly trying to do here?”

Read Full Post »