Last night, I came across this article talking about the difference between an employee who is passionate about the company and an employee who is passionate about their work. Rarely does a blog entry come along that matches up so exactly with my own ideas.

The best nugget of wisdom comes in the form of the “four-question test” that identifies if an employee is passionate about their work:

• keeps up with trade/professional journals
• knows who the key people in the industry are
• would spend his own money, if necessary, for better tools
• if they were NOT doing this as their job, they would still do something related to it as a hobby

When applied to software developers in particular, I would add “participates in open-source software efforts” to the list as well. This relates closely with the 4th question (concerning hobbies), but goes deeper — it suggests that not only does the individual enjoy what they do, but they want to use their talents for “the greater good”. This also goes back to another test of a “passionate worker” in the original article:

Does not care about upward mobility in the company. Cares about doing fabulous work and possibly the recognition of his peers in the industry. May stive (sic) for professional recognition.

This is the main reason why I chafe so much under the the non-compete agreements and intellectual property constraints that permeate the software industry. All developers should have the right to “own” the software that they develop, as long as it’s done entirely on their own time with their own resources, and doesn’t represent a conflict of interest with their “day job”. Not only should developers be allowed to release their own personal creations as open source, but they should be permitted to sell them.

Before you tag me as some sort of commie, understand that I do think a company that employs software developers has every right to protect their intellectual property. Unfortunately, too many companies do so simply by saying their developers own nothing. Before I took my current job, I interviewed at a “big-name” consulting firm. Their contract agreement said something along the lines of:

The Employee hereby acknowledges that all Inventions are the property of (company), except those explicitly listed in Appendix A.

Translation:

You’re screwed. If you ever have a unique idea that ends up gaining any decent amount of buzz or generating any decent amount of money, you better damn well better be able to prove that you didn’t think it up before, during, or up to 12 months after your tenure with our company. Otherwise, we’ll sue the shit out of you and take not just your ideas, but your house, your car, and probably your dog.

Needless to say, I wasn’t interested in the job. (Particularly when they offered me a flat salary with no overtime and suggested that the average work week was 70-80 hours. Bear in mind, they would be billing my time to their client on an hourly basis.)

In my opinion, developers should legally own their work, as long as the following conditions are met:

• Absolutely no code would be re-used from company projects.
• Within reason, no concepts that were developed specifically for in-house projects would be re-implemented.
• All of the work on the project occurs on the developer’s own time, outside of the office, and would not be developed using any company hardware or software.
• The software would not be directly related to the company’s industry, and would not compete with any offerings of the company.

Developers who care about software write the best software. If they want to spend hours of their own time improving their skills, why get in their way?

A friend and former co-worker, Jack Altiere, wrote a very good article about the process of interviewing from both sides of the table. He has some very good insight into the issue, so I figured I would add my two cents.

Jack makes an excellent point that interviewers should ask candidates to write a piece of code on the spot during the interview. He suggests asking candidates to write a string reversal, which is simple and straightforward enough to be an excellent test of a candidate’s ability. However, based on some discussion of the questions to ask, a lot of the things people think you should ask are way too complicated or just completely off base. For example, why in the world would you ask a prospective candidate to detail a possible algorithm to solve a Sudoku puzzle? A good answer to that question could be a defensible master’s thesis. Unless you’re hiring them to write artificial intelligence for games, stick to more realistic tests.

Here are some guidelines for questions to ask:

• I’ll copy Jack by saying that you should let them write the code in the language of their choosing. Unless you’re hiring someone specifically for their talents in a particular language, let them write what they’re most comfortable with. You’ll get a better indication of their real abilities if they aren’t burning cycles trying to remember syntax.
• Forgive minor syntax errors. The interpreter/compiler that comes with a piece of notebook paper is limited in its error checking ability. However, if the candidate clearly doesn’t know the difference between char and char*, ask them politely to explain why they wrote it the way they did. If they don’t know, end the interview early.
• Unless the candidate’s title will be Director in Chief of Trivial Knowledge, Don’t ask stupid questions about mundane features of a programming language. Instead, present them with realistic problems that you feel a person of their skill level will be able to solve.
• Likewise, unless they’re going to be doing FEA in Matlab or something else particularly math-heavy, don’t give them bad flashbacks to college math courses by giving them brainteaser-like problems to answer.
• Test their ability to debate (an important trait of good developers) by asking an inflammatory question about a language/technology they display an interest in. For example, if they mention that love Java, ask them why the language lacks support for pointers. If they present a successful defense, give them major points.

Above all, remember that the interview is an extremely stressful and unnatural environment. Although the ability to think and act under that pressure-cooker situation is a good sign that the candidate knows his/her stuff, the inverse is not necessarily true — even if they don’t do well during an interview, they may actually be very capable.

An alternative (or complementary) tactic to asking the candidate to write a piece of code is to ask for a code portfolio. Artists and graphic designers maintain a portfolio of their work, and I believe software engineers should do the same. Seeing examples of a person’s coding style is an instant snapshot of several things:

• Their general skill level with the language the code sample is written in. Do they take advantage of the important features of the language?
• Their understanding of data structures and algorithms and the “best practices” related to them. Watch for common use of things like bubble sorts. If you’re feeling particularly sadistic, ask them about the asymptotic complexity of a particular block of code. Give them points if they at least recognize the term, and major bonus points if they can give you the big-Oh notation.
• Their understanding of good code-writing practices in general. Make sure their program doesn’t contain any 3,000 line for loops, and watch for proper indentation, commenting, etc.
• Their reliance on “shunned” features of programming languages, for example, overuse of globals in C, any use of the goto keyword outside of GW-BASIC…
• Which way they lean on the incessant debate between imperative, functional, and object-oriented languages. (Just because they wrote 1,000 lines of C doesn’t mean they could write 1,000 of LISP.)

In addition, you can review their code and ask questions about how/why they implemented certain things certain ways. If possible, ask for the portfolio ahead of time and have some questions prepared for them. Like I said, the ability to debate is an important skill, and being able to explain and defend a creative idea is a very good indicator as to whether or not the developer will be a good asset to your company.