Lets face it, traditional interviewing techniques absolutely suck when it comes to hiring developers. You read resumes, you do phone interviews, technical interviews, culture-fit interviews, tests and in the end you basically ‘go with your gut’ and hire people who might be good and still get it wrong half the time. Not an ideal situation. This is because developers are craftsmen and no amount of talk will tell you how good a craftsman is at what he (or she :)) does.

Why Traditional Interviews Fail

How much preparation time do you give your people when you ask then to help with the interview process? Chances are it is probably not much (if it’s anything greater than 5 minutes you’re already ahead of the game :)), so your interviewers end up reading the resume literally as they are walking to the interview and I am not even going to talk about actually preparing some questions in advance. With this level of forethought, how likely are you to uncover anything you didn’t already know from the resume? Even when people have some preparation time, how much training have they got in interviewing techniques? Interviewing is a skill just like any other, having great social skills does not a good interviewer make :). People don’t know the right kinds of questions to ask and even when they accidentally ask the right question, don’t know what to look for in the answer they are given.

So, lack of training and preparation can be an issue, but you can address that, does that improve the situation? It does slightly, still, what do you do during an interview to test:

• learning ability
• interpersonal/teamwork skills (outside the interview process)
• ability to compromise and still achieve objectives
• working to deadlines
• depth of experience in the skills that you need
• breadth of experience in a multitude of other skills
• etc.

All you can do is ask and take what you’re told as the truth. Not to mention the fact that many good people don’t do well when they are put on the spot during an interview process. Do you just discard those? You’re actually extremely fortunate if you’re interviewing someone based on a recommendation that you trust, but what if you’re not? Luckily, there is a much easier way to find out – let the craftsman show you what they are made of, get them to write some code.

No, Not On The Whiteboard

No, coding on the whiteboard or on paper, or even the 5 minute exercise on the laptop is not really coding. You need to put a craftsman into their element and then you need to step back and observe. Observe how they work, how they interact, how others interact with them. Seth Godin proposes that we need to work with our prospective hires for months, while that would be nice it may not be practical, but we don’t really need to go that far. I say one day can give you enough information to make a good decision. When you have a prospective candidate in mind, rather than iterating through rounds and rounds of interviews, put them into your team for a day and watch them work. After the day is over get your team together and let them tell you if you should hire this person or not.

The advantages of this approach are clear. You don’t need to assume culture fit (or do multi-choice psych analysis), you simply test it. You find out first hand from the people you trust if they would be happy to work with this person, after all that’s what they will have to do. You get a glimpse of the depth of your applicant’s skills as well as the breadth. You find out how easily and well they can grok a new system and absorb what they are being told. And you do all this in an atmosphere which is a lot less formal than an interview and one where a developer can feel a lot more comfortable. This is further enhanced if you ask your people to put the prospective candidate ‘through their paces’ beforehand.

Innovate To Attract The Innovators

Surely we can’t ask a person to spend a whole day working and interviewing before we even hire them. Can you not? Why not, are you not a compelling enough place to work? If your face is getting red right now – fix that first and then work on your hiring process. If you’re worried about inconveniencing a person by asking them to give up so much of their time for free, just imagine how inconvenienced you’ll be when you realize you’ve hired a crappy candidate 6 months too late. Be innovative and you will draw people who enjoy an innovative atmosphere, people who will be happy to take a day just so they can go through an interesting and different interview process. You need to become the kind of company that will attract the sort of employees you want to hire. Your interview process and the way you hire people is the first step. It is up to you if you want to take it.

__

For more tips and opinions on software development, process and people subscribe to skorks.com today.

__Image by kevincole

Just like other object oriented languages, Ruby gives an object ways to find out if it is equal to, greater or less than another object. Object comparison is extremely important, not only do we tend to often explicitly compare objects to each other e.g.:

ruby string1 = "abc" if "abc" == string1 puts 'they are equal' end

but objects are frequently compared and tested for equality ‘behind the scenes’, by core and library classes (i.e. ordering of objects in collections etc.). So, lets not waste any time and jump straight in.

Testing Objects For Equality

Ruby has three main equality test methods, ==, eql? and equal?. These methods normally live in the Object class and since all other Ruby classes inherit from Object, they automatically gain access to these three methods. Inside the Object class all there methods do exactly the same thing, they test if two objects are exactly the same object. That is to say, both objects must have the same object id. We can easily demonstrate this e.g.:

```ruby string1 = “abc” class MyObject end object1 = MyObject.new object2 = object1 object3 = MyObject.new

puts “Object 1 is == to object 2: #{object1 == object2}” puts “Object 1 is eql? to object 2: #{object1.eql? object2}” puts “Object 1 is equal? to object 2: #{object1.equal? object2}” puts “Object 1 is == to object 3: #{object1 == object3}” puts “Object 1 is eql? to object 3: #{object1.eql? object3}” puts “Object 1 is equal? to object 3: #{object1.equal? object3}”```

The output is:

Object 1 is == to object 2: true
Object 1 is eql? to object 2: true
Object 1 is equal? to object 2: true
Object 1 is == to object 3: false
Object 1 is eql? to object 3: false
Object 1 is equal? to object 3: false

As you can see, when two variables are referencing the same object, calling any of the three equality methods will tell us that the two object are equal. As soon as two variables reference different objects (even if everything about the objects is otherwise identical), all three methods will tell us that the objects are unequal.

Of course, it is not very useful to have 3 different methods that do the same thing. Usually with Ruby we will tend to leave the equal? method alone to always give us the ability to find out if two objects are exactly the same. The eql? and == methods however are open to be redefined in any way we like. It might still seem a little strange to have two methods that can ostensibly do the same thing. I will come back to this point a little later. In the meantime lets look at the == method (or operator if you prefer).

You can redefine the == method to give your objects custom behavior when it comes to equality testing. Lets do this for a Sock class:

```ruby class Sock attr_reader :size def initialize size @size = size end

def ==(another_sock) self.size == another_sock.size end end```

You may now compare your Sock objects in an intuitive fashion based on the size. More than that, by defining the == method on your object, you also get the != method for free which allows you to test your objects for inequality, very handy e.g.:

```ruby sock1 = Sock.new(10) sock2 = Sock.new(11) sock3 = Sock.new(10)

puts “Are sock1 and sock2 equal? #{sock1 == sock2}” puts “Are sock1 and sock3 equal? #{sock1 == sock3}” puts “Are sock1 and sock2 NOT equal? #{sock1 != sock2}”```

Which produces:

Are sock1 and sock2 equal? false
Are sock1 and sock3 equal? true
Are sock1 and sock2 NOT equal? true

But, what if you want to compare two objects to find out which one is greater?

Comparing Ruby Objects

The == is not only an equality method, it is also part of a family of comparison methods that also include, >, <, >=, <=, and !=. Whenever you need to be able to compare your object and not just test for equality, redefining the == method is no longer enough and you must take a different approach.

In order to give your object the ability to be compared to other objects, you need to do two things:

• Mix in the the Ruby Comparable module into your class
• Define a method called <=>, this is known as the comparison method or ‘spaceship method’

Mixing in the module is pretty simple, but how do you define the <=> method? This is also fairly intuitive, if you’re familiar with any other object oriented language. If you’ve ever used the Comparable interface in Java for example, you’ll be right at home. Essentially, the method must return –1 when you think your current object is smaller than the one you’re comparing against. If you think it is larger you need to return +1, otherwise you return zero (the objects are equal). Let’s have a look at an example:

```ruby class Sock include Comparable attr_reader :size def initialize size @size = size end

def <=>(another_sock) if self.size < another_sock.size -1 elsif self.size > another_sock.size 1 else 0 end end end```

Defining the spaceship method allows your object to use the whole suite of comparison methods (==, >, <, >=, <=, and !=) e.g.:

```ruby sock1 = Sock.new(10) sock2 = Sock.new(11) sock3 = Sock.new(10)

puts “Are sock1 and sock3 equal? #{sock1 == sock3}” puts “Are sock1 and sock2 NOT equal? #{sock1 != sock2}” puts “Is sock1 > sock3? #{sock1 > sock3}” puts “Is sock1 < sock2? #{sock1 < sock2}” puts “Is sock1 >= sock3? #{sock1 >= sock3}” puts “Is sock1 <= sock2? #{sock1 <= sock2}”```

Which produces:

Are sock1 and sock3 equal? true
Are sock1 and sock2 NOT equal? true
Is sock1 > sock3? false
Is sock1 < sock2? true
Is sock1 >= sock3? true
Is sock1 <= sock2? true

If you ask me, this is a pretty decent amount of functionality to get out of defining just one method. It is interesting to note that you can easily define all those comparison methods separately, instead of defining the spaceship, if you were so inclined.

Also, notice that you automatically get the == method by defining the spaceship, so you don’t need to provide separate equality behavior for your object any more. Although the Ruby built-in String class does define the == method separately from that provided by the <=> method, so you’re still able to customize the behavior of comparison methods even if you’ve already defined the <=> method.

Eql? vs ==

I did say I would come back to this one :). As I mentioned in core Ruby classes the equal? method is used to to find out if two objects have the same object id (are the same object). The == is normally used to find out if two objects have the same value (as you would expect). The third method, _eql? is normally used to test if two object have the same value as well as the same type_. For example:

ruby puts "Does integer == to float: #{25 == 25.0}" puts "Does integer eql? to float: #{25.eql? 25.0}"

This gives:

Does integer == to float: true
Does integer eql? to float: false

You are of course welcome to reproduce similar behavior in your classes when you define your equality methods. However it does seem a little redundant to me. If you need two object to be equal then you will probably want them to be the same type in the first place (the above example with integers and floats is the only exception I can think of), in which case you would make sure they were the same type even in the == method. If you don’t really care about type and just care about the behavior of the objects (which is entirely possible considering Ruby’s dynamic nature, with duck typing and all), then you probably wouldn’t test for type equality in either the == method or the eql? method. Basically the eql? becomes redundant.

There is only one scenario that I can see where the eql? method might come in handy. If you have to defined the <=> method, therefore giving your object an implicit == method, it may no longer make sense to redefine == separately (although as I mentioned above, nothing stops you from doing so). But if for some reason you need to keep the <=> equality behavior but still need even more custom equality behavior, you can always use the eql? method for this purpose. I can’t really envisage a situation where you might want to do this, but the capability is certainly there.

This leaves the eql? method as a rather useless one. From what I can see, it is defined and used by many of the core Ruby classes as well as the library classes so you need to be aware of it and know when it is likely to come into play. However I can’t really see you ever needing to define it for your own classes given that you have equal? and == already. I would welcome some discussion on this one. If someone known of a good reason to have the eql? method around then I would love to hear about it. As it stands, this is all you really need to know about equality and object comparison in Ruby. More Ruby discussion is coming up, so don’t forget to subscribe to my feed if you don’t want to miss it.

Images by The Artifex and rstrawser

It may or may not surprise you to know that the bash shell has a very rich array of convenient shortcuts that can make your life, working with the command line, a whole lot easier. This ability to edit the command line using shortcuts is provided by the GNU Readline library. This library is used by many other *nix application besides bash, so learning some of these shortcuts will not only allow you to zip around bash commands with absurd ease :), but can also make you more proficient in using a variety of other *nix applications that use Readline. I don’t want to get into Readline too deeply so I’ll just mention one more thing. By default Readline uses emacs key bindings, although it can be configured to use the vi editing mode, I however prefer to learn the default behavior of most applications (I find it makes my life easier not having to constantly customize stuff). If you’re familiar with emacs then many of these shortcuts will not be new to you, so these are mostly for the rest of us :).

Command Editing Shortcuts

• Ctrl + a – go to the start of the command line
• Ctrl + e – go to the end of the command line
• Ctrl + k – delete from cursor to the end of the command line
• Ctrl + u – delete from cursor to the start of the command line
• Ctrl + w – delete from cursor to start of word (i.e. delete backwards one word)
• Ctrl + y – paste word or text that was cut using one of the deletion shortcuts (such as the one above) after the cursor
• Ctrl + xx – move between start of command line and current cursor position (and back again)
• Alt + b – move backward one word (or go to start of word the cursor is currently on)
• Alt + f – move forward one word (or go to end of word the cursor is currently on)
• Alt + d – delete to end of word starting at cursor (whole word if cursor is at the beginning of word)
• Alt + c – capitalize to end of word starting at cursor (whole word if cursor is at the beginning of word)
• Alt + u – make uppercase from cursor to end of word
• Alt + l – make lowercase from cursor to end of word
• Alt + t – swap current word with previous
• Ctrl + f – move forward one character
• Ctrl + b – move backward one character
• Ctrl + d – delete character under the cursor
• Ctrl + h – delete character before the cursor
• Ctrl + t – swap character under cursor with the previous one

Command Recall Shortcuts

• Ctrl + r – search the history backwards
• Ctrl + g – escape from history searching mode
• Ctrl + p – previous command in history (i.e. walk back through the command history)
• Ctrl + n – next command in history (i.e. walk forward through the command history)
• Alt + . – use the last word of the previous command

Command Control Shortcuts

• Ctrl + l – clear the screen
• Ctrl + s – stops the output to the screen (for long running verbose command)
• Ctrl + q – allow output to the screen (if previously stopped using command above)
• Ctrl + c – terminate the command
• Ctrl + z – suspend/stop the command

Bash Bang (!) Commands

Bash also has some handy features that use the ! (bang) to allow you to do some funky stuff with bash commands.

• !! – run last command
• !blah – run the most recent command that starts with ‘blah’ (e.g. !ls)
• !blah:p – print out the command that !blah would run (also adds it as the latest command in the command history)
• !$ – the last word of the previous command (same as Alt + .)
• !$:p – print out the word that !$ would substitute
• !* – the previous command except for the last word (e.g. if you type ‘_find somefile.txt /’, then !* would give you ‘_find somefile.txt’)
• !*:p – print out what !* would substitute

There is one more handy thing you can do. This involves using the ^^ ‘command’. If you type a command and run it, you can re-run the same command but substitute a piece of text for another piece of text using ^^ e.g.:

$ ls -al
total 12
drwxrwxrwx+ 3 Administrator None    0 Jul 21 23:38 .
drwxrwxrwx+ 3 Administrator None    0 Jul 21 23:34 ..
-rwxr-xr-x  1 Administrator None 1150 Jul 21 23:34 .bash_profile
-rwxr-xr-x  1 Administrator None 3116 Jul 21 23:34 .bashrc
drwxr-xr-x+ 4 Administrator None    0 Jul 21 23:39 .gem
-rwxr-xr-x  1 Administrator None 1461 Jul 21 23:34 .inputrc
$ ^-al^-lash
ls -lash
total 12K
   0 drwxrwxrwx+ 3 Administrator None    0 Jul 21 23:38 .
   0 drwxrwxrwx+ 3 Administrator None    0 Jul 21 23:34 ..
4.0K -rwxr-xr-x  1 Administrator None 1.2K Jul 21 23:34 .bash_profile
4.0K -rwxr-xr-x  1 Administrator None 3.1K Jul 21 23:34 .bashrc
   0 drwxr-xr-x+ 4 Administrator None    0 Jul 21 23:39 .gem
4.0K -rwxr-xr-x  1 Administrator None 1.5K Jul 21 23:34 .inputrc

Here, the command was the ^-al^-lash which replaced the –al with –lash in our previous ls command and re-ran the command again.

There is lots, lots more that you can do when it comes to using shortcuts with bash. But, the shortcuts above will get you 90% of the way towards maximum bash productivity. If you think that I have missed out on an essential bash shortcut that you can’t live without (I am sure I have), then please let me know and I’ll update the post. As usual, feel free to subscribe to my feed for more tips and opinions on all things software development.

Image by djhsilver