The most important job a software developer has is solving problems. A job that does not pose challenges is non-productive or at least plain boring. It is easy however to get trapped in the routine of everyday maintenance tasks which require patience more than innovation and it can have a negative effect on the sharpness of your problem solving blade. So how can you stay sharp and fit for the problems to come? As it turns out there are quite a few ways!

Stay in touch with the basics

Try to skim through basic concepts in computer science once in a while. Stacks, queues, different kinds of trees and other data structures are building blocks of every serious software system and they are also fun things to work with. Wikipedia is a great source to refresh your memory on these topics. Data structures are of no value without algorithms though. Never let your knowledge of algorithms get rusty. Remember. Good programmers, know their algorithms!

Work Out!

A good way to kill some time is to solve programming challenges. You don’t need to find a new solution for a NP-hard problem. Just try your hand at something very simple. Like rotating a matrix, or reversing a string. These problems help you remember the basic operations you will need in your everyday tasks.

Recently I stumbled upon HackerRank. It is a great place to challenge yourself and then compare yourself with other fellow programmers! If you feel more confident you can also try to help other people in their computer science problems in Computational Science section of Stack Exchange.

Read, Read and then Read some more!

There are great books in computer science that you’ll enjoy reading. I personally take great pleasure reading Introduction to Algorithms. It covers various topics in CS. I like the unique way the topics are organized in this book. If you don’t like the mathematics, you can safely skip those parts and enjoy the rest. I like this book so much that I have created a GitHub repository called CormenAlgorithms dedicated to implementing all algorithms in this book in C#. You are welcome to join if you feel like it.

Let me know what you think

If you know other ways to stay a good problem solver, please share it so we all can use.

A while ago we decided to hire a senior software developer for Meridian. The reason was I was leaving and they wanted to replace me with a new me! I participated in all the interviews and was responsible for asking the technical questions. I didn’t have much experience interviewing developers but it was a great experience.

Hiring programmers is not easy. The problem I had was that the resumes were generally much better than the actual person. You see this beautifully crafted documents full of carefully picked keywords compiled to impress recruiters and employers. But, in the face to face interview there is no sign of that glory. Good thing we don’t hire anyone just by their resume.

So what is the problem? Why are resumes much better than people? I have a few thoughts on that. There are two important problems with resumes these days. Oversell and Overconfidence.

The oversell problem is much more obvious. Finding a job is in fact a marketing practice. You are the seller and the employers are the potential customers. You want to seem bigger than you actually are because this is how marketing works. The other important player in the equation is the recruiter or hiring agent. It is amazing how many of the technical recruiters are in fact non-technical or at least not-that-technical. What do you think recruiters look for to find their candidates? The answer is keywords. Hiring is a keyword game. It is now customary to have a table of categorized keywords in your resume. Heck! I have a keyword table in the first page of my CV. You know why? Because it works. You will get indexed by search engines. You will get noticed. People will find you and offer you interviews. Apparently getting an interview is an achievement of its own. You have done a hello world app with AngularJS put in there. You’ve read about MongoDB or Closure the other day? Put it in there. You’ve heard that Ruby gets you hired? You know that Scrum is cool but your company have never done a project in Scrum? Don’t worry. Just put them all in your resume.

I don’t think that’s the developers’ fault though. They want jobs, the education sucks, not everyone is a social media junky and new frameworks and programming languages pop up every day. It’s a mess. It’s hard to keep up and funny enough, everyone expects you to do it. So what’s the quick and easy solution? Just lie!

Let’s talk about Overconfidence now. The vast majority of poker players think they are naturally talented and better than their peers. But becoming a really good poker player, takes study and hard work. It is the same with programming (or any other profession for that matter). Part of the problem of overly good resumes is that developers genuinely think they are good. Sometimes we don’t want to lie. We really think we are geniuses. From the 7 or 8 candidates that I have interviewed, almost all of them claimed to be fully proficient in C# and .NET. The form they had filed beforehand clearly stated that “Fully Proficient” means they can write text books on the subject. I really was intimidated by the look of the resumes. I’d tell myself what am I going to ask these people? Wouldn’t that be awkward if I ask a silly question and they start laughing at me?! But then, in the interview, everything changed. I would ask simple questions about delegates, generics or extension methods that anyone with 8 years of experience working with .NET framework and claiming to be a world class expert should be able to easily answer, but no. It was a bit disappointing and heart-warming for me at the same time.

Maybe, you would point out, that expecting everyone to remember every technical detail in a framework is not fair. You’d be right. How about the basics? Algorithms. I asked candidates to represent a graph in any form they want. None of them remembered adjacency matrix. When I asked them to find out if a graph is tree or not, again none of them knew about the relationship between the number of edges and nodes in a tree. Is this asking too much? Ok. How about XOR operator. Do you know what does XOR operator do? More than half of the candidates couldn’t answer the question. It was the same with dependency inversion, design patterns and SOLID principles. Everyone tells you they know them, but the reality is different.

Life for a programmer is sometimes isolated. Whether it is the nature of the work that requires constant focus or the habits of the practitioners, the result is you become isolated for long periods of time.

You create something from the scratch and it feels amazing. And then you get carried away. You will start to appreciate your abilities too much. You can easily become satisfied with what you already have and you will stop learning and pursuing the latest development in the industry.

I think a good programmer should never stop learning, should never stick to one technology, one programming language or one operating system and should never lose touch with the basics of computer science. And of course a good programmer should never be overconfident.