Hiring Developers

Hiring Developers

Hiring is a topic that almost every software engineer has an opinion on. I’d like to chime in as well, but first I’d like to speak about the skills I think a good developer should have.

• How to use Google. Not just searching stackoverflow, the answers we seek are often found in the documentation or in blog posts by other developers. The better their Google-fu, the quicker they’ll find the solution and get on with shipping your product.
• Reading and absorbing information quickly. Picking up other people’s code seems to be one of the harder tasks developers face, judging by how much code gets abandoned. Devs also need to read documentation which can be dense at times.
• Writes clean, maintainable code. From the simple things like giving descriptive names instead of int a; and void compute() to the not so simple like building clean abstractions, it ensures that your code remains in a healthy state. Doing this requires additional effort, which not everyone is willing to put in.
• Communicates well. Describing systems can get complex and people who can explain their thoughts about them in a clear, concise manner have an advantage. If they can also commit those thoughts to the project’s documentation, that would help future maintainers as well.
• Is pro-active in improving the code base and product. Nobody wants a person who works half-heartedly on your product. A dev could contribute by refactoring existing code, trying new libraries, improving the tooling their fellow devs use or making useful suggestions for the product.
• Is a team player. A good developer should be able to work well with a team, should be willing to listen to the suggestions others and help maintain a calm, friendly atmosphere.

I think pretty much everyone can agree that these qualities are very desirable in any developer. But the one big one I’ve left out is problem solving ability. The story goes our company is building solutions to big problems and we need the people who are the best at solving them. This ability is guaged by asking questions like implementing Dijkstra’s algorithm, inverting binary trees or my personal favourite, finding the optimal way to burst balloons that are lined up, where each balloon has a weight and bursting a balloon gives you points equal to the product of … you get the idea.

Many large and successful software firms like Google favour this approach favour this approach for a number of reasons.

1. It reduces the impact of biases that the interviewer might hold. No useless questions like “tell me about yourself”, “what is your greatest weakness?” etc that introduce a subjective element.
2. Its easy to make many of these questions. Most interview questions become public knowledge eventually but you can replenish your question pool by the time they do. (arranging k books in m ways on n shelves)
3. Luck doesn’t appear to play much of a role so the process no longer seems arbitrary.

These are valid points. But it is my opinion that while cracking the coding interview requires a lot of practice, practising balloon-bursting questions doesn’t make you a better developer. I think it makes you better at solving questions similar to balloon-bursting. I have yet to see the approach needed to solve this (dynamic programming) be useful in shipping a feature, or squashing a bug, or planning a system’s architecture.

Questions about arcane data structures and sorting aren’t useful either. Almost all programs don’t use anything more complex than arrays and maps, and the standard library is used for sorting. If you actually need Red-Black trees and quicksort in your program, wouldn’t you look it up first? Why bother asking a candidate to code from memory?

Judging Intelligence

I think it would be helpful to recognise that these questions were widely used in interviews not because they were good at judging quality, but rather because they were easy to ask and prepare for. If our aim is to find out if a person is smart or not, then we’ve chosen an exceptionally tough problem to solve.

IQ tests are out of vogue today, but its worth remembering that for the better part of a century, it was a widely held view that they were an excellent measure of intelligence and predictor of success in life. Similarly many companies continue to use GPA as a proxy for hard work and smarts

People who advocate for algorithms based problems are similarly certain that they are a good judge of intelligence. However, I feel there is significant confirmation bias at play - they look at developers who are good at both dynamic programming and software development and claim a link between the two. If they work at a company that recruits based on this, then most of the developers they know are good at both. From there they conclude that one is definitely because of the other.

I feel the sooner we abandon the algorithm approach, the better. There is a correlation between balloon-bursting ability and effectiveness as a developer but there is no causal link. That means while there are people good at both algorithm questions and software development, there are also good developers who are bad at balloon-bursting and professional balloon-bursters who are bad software engineers. It is as meaningless a data point as a score on an IQ test or college GPA or even a person’s height (height is correlated well with career success).

Alternate approaches

Right now most companies copy the Google approach, implicitly trusting that if it were proved to be bad then Google and others would switch and they could switch too. I don’t think this is likely to happen. People in general find it difficult to admit that they were wrong about something, and its even more difficult for a large organisation. We need to evaluate alternate approaches and move to that, rather than waiting for the behemoths in the industry to show the way.

Resumes also suck at predicting quality of candidates. Though it is difficult, we should try to test for the skills we actually need in developers as outlined in the beginning. Some people are already trying to do so, and are trying novel approaches.

Some give candidates full access to Google, mimicking real world conditions better. Another scrapped resumes altogether. Will expand on this section

https://terrytao.wordpress.com/career-advice/does-one-have-to-be-a-genius-to-do-maths/

vs

http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html