A Hiring Proposal

t0ss — Tue, 18 Jul 2017 13:38:56 +0000

Within our profession, we have developed an apt process for interviewing potential hires. Our current process typically involves a whiteboard, a candidate, stoic stares, and a palpable, mounting, tension that threatens to suffocate all who occupy the room. This, when coupled with tedious, extraneous, or overtly abstract questions, will always bring out the best of those who are subjected to it. While few admit it, it also grants a wonderful feeling of power, holding the answer to the question the candidate may struggle to find. Especially when the poor soul can’t seem to grasp an exquisitely nebulous, or entrapping, question.
While all the above mentioned have served us well, I believe I have produced several ideas to elevate our process from apt, to extraordinary. I will go on to give a brief outline of them below. I suggest all tests be done on the same day, in rapid succession. This will allow one to gauge the new hire’s ability to work the long, grueling, and mental devastating hours we should expect of our developers.

First, a Multitasking Aptitude Test, or MAT henceforth. Prior to the whiteboard interview, we must simulate, and judge performance in the optimal development environment. Give your candidate a moderately difficult problem to solve. Place near him or her: a phone set to ring once a minute, a second monitor with an open email and team chat application, an empty chair. The candidate must answer any incoming communications. If at any point your candidate seems to enter a “flow” state, send in an associate to sit in the empty share and ask an unrelated question, or six. If your candidate does not finish the task ahead of your expectations, deduct points.

Second, a physical fitness test. We all know that excellent exercise habits lead to long term health. Therefore, a candidate who is not fit will almost certainly not be able to handle the physical stress of repeated crunch times and midnight fire drills. Quite simple this one.

Third, the Pivot Quickly Within Allocated Timeframe Test, or P-QWATT henceforth. The P-QWATT is designed to judge the candidate’s ability to never, ever, work on one issue or feature at a time. On a second monitor, open a support ticket app. Allow the candidate to begin a moderately difficult challenge. Just as the candidate reaches his or her “Eureka!” moment, send a support ticket. The candidate must answer the ticket and solve the new problem. Just as candidate begins his original problem anew, re-enter the room and propose a new problem. Tell him or her it may be completed after the original problem. After a momentary wait, inform the candidate that, after further thought, the new problem is more important. As with the MAT, if your candidate does not finish the task earlier than you expected, deduct points.

Fourth, and finally, be sure to quiz your candidate on easily searchable, trivial questions. One should expect a dictionary-like knowledge of all aspects of whatever language is being used in your stack. A sign of a truly great developer is one that knows the ins and outs of your favorite language.

I hope my fellow hiring managers agree with my modest, yet wonderful, proposal. I firmly believe that these will be of great benefit. After all, if we truly believe in the whiteboard tradition, we must also hold firm, true to, and interview for, all the traditions of our past.

The Programmer and the Pulpit

t0ss — Sun, 07 May 2017 21:23:11 +0000

Soft organ music filled the room, nearly overtaken by the buzz of the murmuring crowd. If one strained the ear, it might catch whispers of the new paradigm, or best practice, that might be the day’s sermon. Soon, though, the murmurs faded to silence. The room filled with only the steady tap of footsteps approaching the pulpit. An impassioned sermon began.

I was captivated. Of course! Why should I ever have to use object oriented programming? How could I have been so naïve? The one, very… very, particular example he gave just worked so well. And his unit test! Oh my, his unit test… So, clean and easy. The mocking was so easy as well, nothing like the mess I had to deal with in my recent OOP nonsense! This new paradigm was a game changer!

As the sermon came to a close, the congregation stood. Discussion filled the room. As I exited, I caught wind of my fellow attendees singing the praise of this exciting new answer to everything. We all shuffled through the doors, an energy among us. Great things would be done with this new knowledge!

I sat in my car, swung the door closed, and headed home. It wasn’t a mile before I hit traffic. How could this happen? I was on a mission! I began to daydream: home, in my office, destroying the OOP my silly professors swore by in my current project.

Then, I realized... I’d no OOP to destroy once I reached my destination. I had already torn that to shreds after last week’s sermon about functional programming… Or was it the sermon on Procedural programming? It didn’t matter, because I’d just realized how difficult the unit test mocking would be from today’s sermon for many aspects of my current features. Now, rather than mocking the functions I’ve rewritten from methods, I’d have to mock three different interfaces… Oh, and I have to re-abstract out everything I currently have, and not to mention having to redo the front end to the new Absolute Best framework from last month’s Guest Programmer...

I regained presence as I neared the driveway. I collected my things and rushed to my office. I set to work. Hours in I remembered I was months behind my self-set deadlines. This filled me with envy of a certain co-worker's astonishing ability to ship code. How did he manage to stay so productive?

Ted... Ted wasn’t at the sermon. Actually, I rarely ever see Ted attending… did Ted even know about the Latest, Greatest Paradigm that The Programmer had covered? Curious, I checked some of his recent work; the newest update during the sermon.
When I combed through his code, I couldn’t believe my eyes. He was using the Third Greatest Front End Framework! Why didn’t he change to the First from last month… wasn’t he aware that TGFEF wasn’t utilizing Immutability, or a virtual DOM? Not only this, but I found functional programming practices mixed with OOP. What was this madness?

At this point, something clicked. A sense of peace seemed to wash over me. I think, at this moment, I finally realized why Ted was so… 10x. When I first saw his stitchings of paradigms and practices I thought him a Dr. Frankenstein. But now, I know this was wrong. His ability to fluidly utilize these different things, when appropriate, was breathtaking. Upon closer inspection, it become clear he knew these paradigms much better than The Programmer. Not because he could preach about them, rather that he could use them seamlessly... pragmatically.

I took note of the great parts of my functional rewrite, and ideas from The Programmers sermon. And started work anew.

git revert OOP-commit

DEV Community: t0ss

A Hiring Proposal

The Programmer and the Pulpit