Good Code is Like Glass

I've been thinking recently about what qualities an employer wants to see in a potential software developer. Although there are plenty of other resources that have addressed this topic, I want to add my two cents.

In a previous article, I talked about how important honesty was in marketing a product to consumers. I also believe that honesty is important in all aspects of life, including selling your technical skills to an employer.

Nobody is perfect, of course. I'm not suggesting that you must represent the pinnacle of perfection. It is true that employers are interested in what knowledge you have regarding technologies they use, but more importantly, they are interested in your willingness to learn new technologies.

Software development is not a field where you learn the ropes and then that's it, you're done learning. Instead, it is a continual, never-ending process, and if you can demonstrate to an employer that you understand this concept and that you embrace it, then you've increased your chances of being hired.

Here is a list of some of the techniques an employer will use to try to rate you as a potential employee:

Evaluate Technical Aptitude Using Puzzles

As software developers, employers know that we love to program. Employers assume that we will try our best on some interesting feature of a new product, but the fact is that there are some tasks that may not be the most interesting to us. I believe this is where the puzzles enter the picture. An employer will use these to try to determine not only your thought process in solving a problem, but they will also be able to gauge how much effort you put into your attempt to solve the problem.

In my interview, I was very nervous, so I drew pictures and talked out loud to myself. This helped me relay to the interviewer my thought process as well. The best thing you can do is keep trying. You don't necessarily have to solve the puzzle, but you definitely want to attack the problem like your job depends on it. Because it does!

Evaluate Skills Based on Technical Questions

I'm not going to cite statistics on how much money an employer will lose by hiring inept technical people. Instead, I'm going to tell you that it is very frustrating to work with people who don't know what they're doing. I'm sure everyone has had an experience in college or in another group situation where one group member wasn't able to produce. This is where it becomes really important to be honest.

I know firsthand that there are employers who value honesty, and these employers make hiring decisions based on this honesty. In my interview, I was asked to rate my skills in Java on a scale of 1 to 10. I rated myself as a 3. I didn't rate my skills as a 1 because I had done some programming in Java, and I didn't rate it as a 4 or 5 because I had no formal training in Java. I was a C++ programmer. But I believe what made the difference for me was that I was able to demonstrate that I knew there were differences, I knew that I had a lot to learn -- especially since I never took a Java course. I made this very clear in my interview.

To prepare for the Java questions, I read online Java tutorials that specifically focused on interview questions. An employer will think very highly of you if you say you don't know much about something and then confidently nail almost all of his or her questions. Contrast this approach with that of the candidate who claims to be an expert in the field but then can't answer any of the questions. People who think they know something but don't usually end up breaking things whereas the person who is more humble will likely proceed with extreme caution when tinkering with their delicate systems.

Someone once said that code doesn't rust. I believe this is true. Good code can last forever, but good code is like glass; it can shatter into a million pieces if clumsy and inept programmers are allowed to handle it. Sure, version control software does exist, but is it really possible to rollback changes submitted by one bad developer on a project that involves multiple developers without losing the changes submitted by the other developers? I'm not that knowledgeable on how CVS rollbacks work, but even if it were possible to "uncommit" changes by one developer, there is a good chance that some of the code written by the good developers would break due to dependencies on the code written by the bad developer.

In addition to Java, interviewers will probably ask about HTML, CSS, and JavaScript. Since most applications are served in a Web browser, employers will be interested to know how knowledgeable you are on these topics. Again, be honest! An employer would rather hire someone who openly admits to not having a full understanding of HTML rather than someone who claims to be an expert but who has "divitis" or "tableitis". Unless you are being hired as a front-end designer, you can probably get away with not being a master of these topics, but claiming you know something you don't will only destroy your credibility.

Appearance in a Technical Job Interview

I was surprised to hear just how many people go to interviews without wearing a suit. Many candidates choose to not wear one, but I felt it would help differentiate me from other candidates. I was right, at least for myself. Although wearing a suit may not necessarily be the best approach for every candidate, you should definitely put some thought into looking your best and wearing something that will make you feel and look confident and competent.