Skip to content

Category: TechTalk

Smacking the Code Interview

I don’t spend much time on social media.  To be honest, I’m not sure yet of its value.  Democratizing news is a noble goal.  Making and keeping connections is a noble goal.  Communication is a noble goal.  All three of these things are messy though and a continuous flow of low value content and constant reposts and shares with no value add is just noise.

But I watch, and wonder.  Sometimes, certain things continue to bubble to the top.  One of these things is the current hiring methods for technology professionals, particularly programmers.  

I spent the first fifteen or more years of my career as a programmer, then the next fifteen or twenty in a variety of IT roles, literally spanning the entire spectrum of IT.  So when I decided to return to my roots, to start programming again, I was blindsided by the change in hiring methods.  I was completely unprepared for the modern interview.

Until now, I’ve purposefully avoided adding my own angst and commentary to the noise.  I wasn’t sure of the noise to signal ratio of my own thoughts.  For one thing, hiring technical people is hard.  It always has been.  Just because we did it differently in the “old days” does not mean we did it any better.  So I understand the intent.  Additionally, like it or not, if I want a job as a programmer today, this is the hurdle I face.  I can complain or I can adapt.  Finally, I cannot really say I have a better idea.  Making my commentary likely high on noise, and low on value.

But I am a programmer.  Solving problems is what I do.  In particular, my specialty, if that word is correct in this case, is troubleshooting.  I am not the one who draws up your initial design.  I am not the one who keeps your project on track.  I am not even the one who reels it all in and plans the after-party.  I’m the guy you call when, despite the best laid plans and designs, it just does not work out.  If I succeed, the project gets back on track and I move on.

And that’s what this is.  A plan that doesn’t work as intended.  I mean it sounds sensible right?  If you want to hire a programmer, watch him program.  But the obvious answer is not necessarily the right answer.  And, at the risk of grossly over-generalizing, the easiest answer is usually not the right one either.

Before we go too much further, we should state the obvious.  The claim the current interviewing process is a failure is one sided. It comes from the many experienced programmers who find themselves stymied by such interviews.  I cannot say I have seen companies complaining about low quality results of their interviews.

That being said, it seems more than passing strange when experienced programmers cannot get past the current gatekeepers.

To keep this short, we will not break down and examine the failures, perceived or otherwise, of the current hiring methods.  Perhaps in another article.  For this one, let us just assume it is broken and re-examine our goals.

We want to hire good programmers, so I guess the first thing we need to define is what makes a good programmer.  We will not list everything, but need something to start from. First and foremost, we have always said IT professionals must be in a constant state of learning and re-learning.  We have also said programmers must be multi-faceted.  No one-trick ponies.  Less commonly admitted, a programmer needs to be a team player (my personal example notwithstanding).

While I do not want to delve deeply into it, I do want to state what should be obvious to everyone.  That being, the current mode of over-the-shoulder code interview involving a Leet Code like algorithm challenge hardly demonstrates any of the above.  In fact, the only thing it demonstrates is that the candidate managed to pass a Computer Science class on Algorithms and the challenge you gave him was one of his homework problems.

Let us revisit our goals.  Find someone with a proven ability to learn, who is multifaceted, and a team player.  Starting from there (rather than what we can easily implement), I finally get to the part I did not have to offer up, even a few days ago.  I will not go so far as to say I’ve solved it, but perhaps I have a new starting point for our conversation.  Again, without offering a complete analysis, compare the above goals with the following scenario.

Choose an algorithm or challenge, but describe it completely.  Do not actually assume the candidate knows what a Bubble Sort is.  Write it up in detail.  Hand them the textbook description.  Like, requirements one might say.  Then, make a random choice.  Roll some dice, pick a name out of a hat, spin a wheel and choose a programming language.  But here is the switch up.  The language cannot be one listed in the job description.  In fact, it should not even be a mainstream language.  Think Smalltalk, Eiffel, Forth or any of the many experimental languages.  This does a certain amount of level setting across the candidates.  

Here are the expected deliverables.

  • Document the development environment.  Tools, downloads, configurations, integrations, etc.
  • Working code
  • Automated tests
  • Documented code, written as if it were a code review
  • Deployment documentation
  • User documentation
  • Blog post

Then, send them away.  Give them a time frame to return, but consider being flexible on the deadline.  Ask for updates.  

When complete, the interviewing team attempts to recreate the work from the documentation supplied.  Before even talking to the candidate a second time, they evaluate the delivered package.  Obviously, the code will not be “expert” level.  Ideally, the candidate just learned the language being used.  But the package as a whole can be evaluated on a variety of levels.

Should the delivery evaluation be favorable, the next interview can occur.  This one is old school.  Technical skills are not even discussed, having been established by the code challenge.  This discussion is the team fit assessment.  Feel free to discuss favorite cartoon characters, the validity of pineapple as a pizza topping and even VI vs EMACS.

To sum up, “Ask not what your candidate can do for you during the interview.  Ask what they can do for you once hired…”

TeX-Talk

That’s “Tex” as in “blecch,” not “Tex” as in “Mex” or so the TeX User Group site says.

I have long been interested in Dr. Knuth’s TeX typesetting system. The idea of being able to do my Math homework electronically has intrigued me ever since I got a home work problem wrong because I added 2 and -2 and got 4. You see, I had erased that part of the problem several times and on the final work through, I did not see the negative sign.

Lifelong Learning

I mentioned in a previous post that a career in Software Development or any part of Information Technology is a career of lifelong learning. This would be true even if technology did not change so rapidly for the simple reason the more we solve with computers, the more problems we are able to solve. Computers allow us to do things not only faster, but smarter. This leaves us humans able to turn our attention to more and more opportunities.

After 35 years in software and IT I have become pretty confident in my ability to learn and take on new tasks. This is not because I know more than when I was younger, but because for 35 years I have refused to sit still. Instead, I continue to branch out and try new things. I have never been the “go to guy” for a specific technology. I am not the expert on all things SpiffySoft. Nor am I the local expert of the FrogSnot programming language. For 35 years I have worked in the cracks, seams and edges of the project life cycle. Where algorithms fail and best practices fall short; where others have abandoned all hope; any problems that makes others say “huh?”; these are the tasks I excel at.

As impressed as I am with myself, I was none the less reminded of the danger of over confidence. Fortunately, this was not for work. No client or schedule suffered due to this learning moment. All the same, there is nothing like a good intellectual ass-kicking to restore some humility to my life.

Math Homework

I’ve always planned to go back to school and finish my degree. I still plan to, but I do have a bit of a conundrum… I’ve already taken my first couple of years of Math classes two or three times. Unfortunately, Calculus is not the sort of thing that sticks with you unless you are using it. So like it or not, I’m pretty much looking at taking everything once again.

This time however, I am thinking to do it differently. This time I’m just going to pull the books from my own shelves and start working through them myself. The plan is, once I am able to actually get back to school, I will already have reviewed everything and still have it rattling around in my brain.