My previous post pointed out a flaw in the current interview process for programmers. When interviewing for a Software Developer position, we are asking questions that are designed for Software Architects.
The Comments were spectacular
One commenter noted an interview he enjoyed and how they avoided the problem of asking the wrong questions by simply having him write code.
Another discussed how these bad interview techniques negatively impacted his career.
And a third (We'll call him Nate)...well the things he said inspired this post. So let's go over them. shall we?
The professional programmer
Being a professional means that you are conversant in the terminology of your industry.
I am a firm believer in Einstein's statement "If you can't explain it simply, you don't understand it well enough." Since Nate's using some big words here, and I'd like to talk about this in a way non-native speakers can understand, let's restate this without the big words.
"If you don't know the words that people in your line of work use, you're not being professional."
The word professional is hard to translate here, so we have to understand that professionalism is partly about showing respect for your co-workers and partly about getting work done. These go hand in hand in that you show respect for co-workers by getting your work done by the deadline. But it also means not flirting with every opposite-gender employee in the company.
So let's start by saying that most programmers are not professionals. For Many Reasons. Note that the last link is an interview with a software architect.
With regard to professionalism, because of the respect piece of this task, and of course the general way that organizations are structured, as employees, we are beholden to the requests of a manager. This extends to mean that we should also communicate at the same level of the manager--turning off all of that technical terminology so that he can understand. In fact, I would go so far as to say that the ONLY time that technical jargon is relevant is in discussions with our peers, other developers.
But what about that terminology. This isn't like biology or physics where you memorize a base set of terminology and build on that. The world of programming is constantly in flux. Just this year, for example, the term IoT began to pop up on all my blogs and I had to learn its meaning. Know what it means? "Internet of Things" That's right, it's not even a term for something new but it's yet another arbitrary term for something we work with every day. I truly believe that we shouldn't be forced to memorize every meme on the internet.
So no, I don't think that a programmer is bad at his job if he doesn't "know the language". Let's look at more of his comments.
I'm not even speaking the language
Nothing that you have mentioned concretely to this point is relevant to architecture. Indeed, to even say "architected code" is a complete misnomer and implies that you don't understand the term as it is actually used in the industry. Code can be "designed," but it is not architected.
Of course I did say "Architected Code" and precisely for ass the reasons I've mentioned previously (Einstein and all that). But I was talking about architecture. Just as a lean-to shack may be the appropriate solution to keeping your firewood out of the rain and a skyscraper for your corporate headquarters, it's important to understand that software also comes in many shapes and sizes.
Let's take a real world example of an architect in action. At NASA, I was put on a team of Coldfusion developers in order to help ease their transition to .NET. We were tasked with building a small administrative application from scratch. I suggested we build it as an MVC 3 application. Why? An academic architect might say that was crazy. I was taking a team of people and thrusting them into a new platform head first (MVC 3 was brand new at the time). It was my real world experience that won here, because they already thew how to code. They didn't need months to memorize every nuance of the new language. They would learn by doing and be better for it.
A guy like Nate might find fault with my decision. Most academic architects would find fault with my choice simply because the technology was new. NASA loved it.
What am I really talking about?
Maybe your choice of examples have just been too limited, but they don't remotely resemble the sorts of things I would ask when interviewing an architect.
Well this post should provide Nate with plenty of detail. Just in case anyone is still confused, this is what I've been talking about this whole time. NSFW (a few words)
I do not share her views, but she is absolutely correct in stating that those questions do not tell anything about the quality of a developer.
With regard to the questions we're asking architects--what Nate is really saying is that the knowledge of these low level architecture principles is assumed by the time an architect makes it to an interview. This may also be a mistake, but that will have to wait for another blog post another time.
Nate continues to repeat that it's important to know this and that arbitrary fact. There's a bit of sadness that washes over me as I read and realize what he is really advocating.
Programming is not like academia
Nate's examples of things that developers should know for interviews aren't related to current technologies. In fact, to a casual observer it might look like Nate is way behind in technology. That's not how I saw it. He was mentioning old, low-level technologies like "state machines" because he truly believes that Computer Science should be like the other sciences, filled with academic discussions and debates. But in the real world productivity matters more than quality--in some cases to the extreme.
A bug fixing maintenance developer is on a time limit. He rarely benefits from discussing his problem with his co-workers (unless it's a very big problem) and every day he spends working on it, there's usually a manager complaining that it's taking too long. Nate's line of thinking is that this guy spent ten years in college memorizing a bunch of programming theory. This neglects the constant growth of technology and the confusing shifts in the language, not to mention that theory is just that.
In reality, after spending 12 hours at the office, our poor maintenance developer then has to go home and read up on the latest technologies rather than spend time with his family--if Nate's way is the right way. And sadly many companies agree and it has resulted in an unfortunate situation. Programmers are being treated like scientists and factory workers at the same time. The inexplicable amount of stress this creates is literally driving them crazy.
Why Nate's post is so great
Nate isn't just saying the wrong things. He's saying EXACTLY the wrong things. If you want to see what you're up against--exactly what's wrong with the current line of thinking in our industry-- then read his comments. They're intelligent, well articulated, and phenomenally wrong. At the end of his comments, he goes so far as to say that he won't hire developers who don't know the answers to these arbitrary questions.
I have a secret for those of you reading this post: you don't want that job. Nate is looking for programmers based on skills they don't use on a day-to-day basis. That means that his team is going to be comprised of politicians, not programmers. These are people who are masters of being unproductive, and that sort of corporate environment is an ugly "every man for himself" "rat race".
The truth is that Work-Life balance demands that something give. In Nate's case. he has chosen to give up productivity. Since the demand for our skills is only increasing, it's a pipe dream to think that the factory worker mentality should go away. Instead, I choose to hone the skills down to those that actually benefit them on the job. They can choose to work toward a higher rank (read architect) on their own time if and when they choose.
A final word about Nate
Nate said he wouldn't hire me, but he should know that I wouldn't hire him either. His blog is empty. I encourage all of my programmers to write a blog, even if it's just occasionally. It shows that you have the passion to have an opinion on something.
I absolutely tend to choose the best for my teams, but I base that choice on their passion for the work. When I pick my teams, I don't waste time with qualifiers, I ask them what code means to them. That tends to get the right answers.
In fact, my complete list of questions can be found in a previous post.