The Programmer Skill People Rarely Ask About In Interviews

When I started programming in the early 80's there was no Internet, no StackOverflow, no blogs, no easy way to get help on a programming problem. You either figured it out for yourself or went to a library or asked a coworker.

Today the entire programming world is at your fingertips.

A lot of it is crap, or inappropriate, or out of date, or downright dangerous. The skill today is not only in finding programming solutions, ideas, examples or even entire frameworks but being able to evaluate them in your context. So why is such an important skill rarely discussed in a job interview?

In my first job at General Dynamics I was asked to implement a source code prettyprinter and someone mentioned I should use a recursive descent parser. I had no clue what that was. The library had some books with of course had no examples in code. I was handed a PL/1 program which supposedly used one but I didn't understand the language at all. Eventually I figured out how to use this but it did take a few months. In another project I had to calculate trigonometric functions for which I needed algorithms (and a lot of help since I never had taken a trig class). Again, the library gave me some theory but no code. Today I know what I did was less than optimal.

Later that decade in my first startup we were developing the Trapeze spreadsheet (story coming soon in another blog post) and all we had to go on was K&R C, a 68K assembly book and 3 folders of Inside Macintosh. Everything we did was basically what we could figure out or maybe found in an old math book.

Today these stories are laughable. Right now if I need to do something I don't know I can search the entire world to find people who have done exactly the same thing, or something similar, or maybe some ideas that might lead to a hint of what I might do. The idea that this would someday be available would have not occurred to anyone in the 1980's - free information, free code, free help? Programming was mostly lone people struggling to invent something no one had ever done (or at least communicated with anyone). I do admit sometimes to be amazed today at how easy it is to find 100 people who have answers to my questions.

Of course the big downside is curating all the wonderful stuff on the internet. It's not so much finding information since it is everywhere and Google knows where it lurks, but deciding on whether it fits the need, has sufficient quality and belongs in whatever context you might use it in. The real skill comes not from cutting and pasting your way through the day but knowing when you should.

Google finds everything and forgets nothing. Lots of solutions to problems, code samples, frameworks and discussions become obsolete. Many were never correct in the first place or applied to narrow circumstances. Deciding what to trust and use requires a lot of editorial sense and that takes both patience and experience. Since the people who write the information and code can be of wildly varying quality and you generally don't know them at all you have to be careful.

Open source is an awesome way to find code you can use (providing the license allows it!) but not all of it is equally useful or dependable. I've gone looking for something and found many different people have built something similar - then it became a chore to decide which fits the need and is good enough for us to depend on. Sometimes these frameworks or libraries may contain a wild variety of options that we won't use. It may be good code written by a smart programmer, but can we risk putting code in an app but only use a small part of it? How do we manage updates or can we make modifications without breaking it? In commercial products you might have to add features not in the original open source item's design, are we now making it less stable or dependable?

Techniques on how to solve some issue may be meaningful only for a single point in time. Using a solution that only applied to one OS version might be incorrect for later versions. Sometimes even reasonable answers that were well received can later be found to be wrong. You have to have a critical eye to everything you find.

None of this should be surprising, you have to look at your own code the same way. I have found people tend to trust what they find on the internet as if appearing on your screen makes it correct. There was a commercial I saw recently where a character says "They can't put anything on the internet that isn't true." Another character asks "Where did you hear that?" and they both answer "On the internet."

I love finding answers as well as helping out the community on stackoverflow.com but even with this wonderful resource there are still lots of bad, incorrect and speculative answers that could lead you astray. Even with such a large resource there are still questions no one can answer so sometimes you have to hunt around Google to find any angle you can that might give you an idea that might lead to a solution even if there is nothing precisely what you need. I often dig around many deep pages in a search just to see if there is anything that might help. Even finding an explanation to an obscure exception or error message can be useful. It's awesome when you find a search with exactly one reference and it explains everything!

To get back to the original point, people never ask about this in interviews which has always confused me. Today finding and curating solutions, examples and open source is a necessary part of being a programmer. It's a skill you have to learn and use almost every day. Especially in today's polyglot world, where even building a simple web application requires more different technologies than probably existed when I started my first job - you can't know everything yourself. You have to be able to enhance your brain with the collective brains of millions of fellow programmers, yet still pick the right brains to build on.

I have known programmers who simply fail to ever look for answers and struggle to solve things on their own, often resulting in solutions that have been rejected by everyone on the internet as downright pointless. Sometimes people are afraid to look in case they discover they can't understand any of them. Other programmers seem incapable of doing anything on their own without google-copy-paste. Neither extreme really works - you have to be able to find and discern.

The other big benefit from looking around for answers is you learn a ton of stuff, even if you don't need it immediately. So many times I've looked for X, found some mention of Y, and later on remembered Y when it became useful. You can even learn from the questions people ask which is why I read StackOverflow's iOS questions every day in addition to all the other sites I read to see what's going on.

Knowledge is so trivial to find these days compared to when I started, yet so much more necessary given the high complexity of programming today. You just need to have a critical eye and make sure you get the right stuff.

Maybe we should sit an interviewee at a computer with a browser and ask a question and see what they do. Might be an interesting addition to interviewing. After all it's a valuable skill you might want to hire.