So, what does that question have to do with software development. Well believe it or not it’s a rather good example of a counting argument. If you look up this example, you’ll come across the term the “Pigeonhole principle”. In mathematics, the pigeonhole principle states that if* n* items are put into *m* containers, with *n > m*, then at least one container must contain more than one item. This theorem is exemplified in real life by truisms like “in any group of three gloves there must be at least two left gloves or two right gloves. This seemingly obvious statement can be used to demonstrate possibly unexpected results; for example, that there are two people in London who have the same number of hairs on their heads.

The first formalization of the idea is believed to have been made in 1834 under the name Schubfachprinzip (German for “Pigeonhole Principle”). The principle has several generalizations and can be stated in various ways. Though the most straightforward application is to finite sets (such as pigeons and boxes), it is also used with infinite sets that cannot be put into one-to-one correspondence. To do so requires the formal statement of the pigeonhole principle, which is “there does not exist an injective function whose codomain is smaller than its domain”. There are advanced mathematical proofs that build upon this more general concept.

The mathematics behind the sock dilemma above is as follows:

- 1 Sock – You can’t match a pair of socks with 1 sock, so obviously this wouldn’t satisfy the task.
- 2 socks – least amount you could attempt, here’s what’s possible to pick up:
- 2 red left
- 2 blue left
- 2 blue right
- 2 red right
- 1 red left, 1 blue left
- 1 red right, 1 blue right
- 1 red left, 1 red right
- 1 blue left, 1 blue right

This doesn’t guarantee a matching pair and the odds that you would get a match is certainly at the lower end.

- 10 Socks – At this point, we still can’t guarantee that we would end up with a matching pair. It’s entirely possible (although at a lower probability) that you could pick out 10 left socks, just as it’s possible that you could pick out 5 pairs of matching blue socks. The problem is that it doesn’t guarantee within 100% probability a matching pair.
- 11 Socks – This really is the magic number. This is where the probability of getting a matching pair jumps up to 100%. For example, you pick out 10 left socks, there are no more left socks in the drawer, the 11
^{th}sock you remove is guaranteed to be a right sock, thus creating a matching pair, even in the improbable event of removing 10 left socks in a row.

**Why is this something that we can ask a software developer?**

Well the answer is simple, answering this question requires some underlying skills. Understanding probability, understanding the terminology used in the question (i.e. **Guarantee** a matching pair), and demonstrates the ability to visualize a problem. All these skills fit into the software development process. Understanding your requirements, executing efficient code, the ability to visualize a problem and work around it. In my opinion soft skill puzzles absolutely deserve their place in the recruitment environment for certain industries.

Soft skills tests don’t just have to have an analytical or mathematical base, they can also be used to determine other characteristics. Such as the ability to ask the right questions, or even ask questions at all. Let’s look at another simple soft skill test.

**But again, why is this something that we can ask a software developer?**

This is the kind of strange interview question that you can get sometimes, it’s an absurd question to have to try and answer seriously in-front of other people. Often questions like this have no correct answer, they are designed to be unusual. The purpose is to simply gauge a candidates reactions to a situation that might not make sense. Will they be creative in their answer and come up with a unique solution that shows that they have applied some critical thinking? Or will they question the task, finding out more requirements, where the restrictions are, and where there is room for movement. Both of these are skills that developers require, the ability to look at a requirement and find a unique solution is often very important, or simply being able to politely challenge a requirement and get to the fundamentals of the request.

**So… Soft skills are important then I guess?**

Absolutely! If all you do is ask a candidate to solve function after function, debug problems, or complete mathematical equations you’re simply testing their * current *abilities in a restrictive (Don’t get me wrong there is some merit to these tasks) way. It’s also important to understand if that candidate has the underlying skills to learn, be adaptive, think on their feet, and communicate effectively. These all play a role in how well that person is going to fit into an existing team. If you find yourself put infront of one of these questions, don’t feel uncomfortable, just jump straight in and be analytical and creative.