DEV Community: Ambrose Little

Moria Tests

Ambrose Little — Tue, 02 May 2023 16:46:19 +0000

I've recently run across some unit tests that may fail 1) if in the wrong time zone or 2) at the wrong time of day. The latter tests don't immediately appear to have anything to do with time, even.

So I've decided to dub these tests "Moria Tests." This is an allusion to Tolkien's door to Moria that the Fellowship had to arrive at at a precise time in relation to astral phenomena. Any test that is fragile in these ways will henceforth be known thusly by me.

You are hereby granted license to do so as well, without any attribution. And if someone else has already so dubbed them, I apologize and claim ignorance. Must be the universal subconscious at work..

How To Avoid Filename Case Errors in Production

Ambrose Little — Wed, 11 Nov 2020 20:02:56 +0000

If you are working on Mac (or, I imagine, Windows), you will most likely be working on a case insensitive file system. This is great for a lot of reasons, but not great for one, namely if your production system is using case sensitive file system, which is very likely.

More than once at different companies in my career, I have had this issue bite me/my team. I will acknowledge up front that one way (probably even the best way) to solve this is to have a CI build that runs tests on an environment that more closely matches production. I mean, ideally we should do that anyway for a number of reasons, but still, 1) you may want to know you broke something before committing and 2) you may want not have that set up even if it is ideal.

So here is a relatively painless way to solve that.

First, close any apps that may be referencing your code. Then:

Create a new Volume in Disk Utility, choose APFS (Case-sensitive, Encrypted) as the format. You do not have to encrypt, but why not, this is your IP after all. Let's call the volume Dev and give it enough space for all your code and then some.
Let's say your code folder is named Repos. So in iTerm2 (you are using iTerm2, right??), go to where that folder is and type: mv Repos /Volumes/Dev/ to move the folder to your new volume. Now go make some coffee, watch a movie, etc. Mine took about 7-8 min for around 14GB.
In the same folder (where your actual Repos folder used to be), type ln -s /Volumes/Dev/Repos Repos. I assume you know what this does, but just in case you do not, it will make a symbolic link to where you just moved all those files. This means (in theory at least) you should not have to change anything else.

Now you can open your coding apps and continue. I cannot guarantee there will not be side effects from this, but I can say that it will help you to avoid casing issues going forward. If you have tests, run them and see. Of course, this only solves for each dev individually on a team, so the better solution will continue to be a CI and/or test or even staging environment to be sure, but I think it can still be helpful. YMMV!

Being Able to Let Go

Ambrose Little — Mon, 12 Oct 2020 17:17:14 +0000

One of the harder things to learn in software development is the skill of letting go. We spend hours and hours (and days, weeks, or even years) working on a thing, and we naturally grow attached to it, especially when it is something we are passionate about.

This is all good to the extent that we often do our best work when we are emotionally invested in it. But it does have a downside, which is that we can be so close to it that this prevents us from seeing its warts. It can also cause us to be protective like the proverbial mother bear with her cubs--to keep everyone else at a distance.

Both of these ultimately lead to having a worse end solution than is possible when we are open to criticism and open to letting others take our work in new and, sometimes, different directions that we personally would not have taken.

The first aspect--open to criticism--is especially important during the early, formative stages of developing an idea into the artifact. A key way to help be open to such criticism is to, ourselves, try to come up with several significantly different approaches to solving what we are trying to solve, and presenting all of them as impartially as we can to others for their review and criticism. The simple act of creating such multiple alternatives weans us from our babies, so we are more able to accept constructive criticism. We then can synthesize the best of all this into a better solution. This is the essence of the Design process.

The second aspect is important during the main effort to develop the idea into a concrete thing. Especially on larger ideas, it is easy to become a roadblock to needed progress because we think only we have the ability to properly drive to a successful outcome. It is important to remain involved, but it is also important to create space for other persons to carve out some parts of the effort and to really own those parts for themselves. Just as we do our best work when we are invested and have a sense of ownership, so do others. And being overbearing, even with good intent, can sap others' energy and passion.

It is similarly important to really be able to let go, when we find ourselves needing to move on to other things. When we no longer are as involved or as invested but, because it was "our baby," we sometimes feel the need to retain that protective mother bear stance. That, too, can kill the healthy evolution and ongoing success. This is the final step, in a sense, of making space for others to thrive and contribute. And it is key. That point almost inevitably will come, and we have to be able and willing to take that step of "faith" and entrust our baby to others.

An Introvert's Guide to Being Sociable: Being Loud

Ambrose Little — Fri, 22 Mar 2019 18:15:33 +0000

(Image Courtesy of the Language Nerds, on Facebook)

The next installment in the "Introvert's Guide to Being Sociable" series..

On Being "Loud"

On one of the few email lists I pay attention to, a person for whom I have a lot of respect said, "We need to focus on Thoughtful people and Correct people. Just because one is Loud doesn’t make them right. It makes them Loud." I kind of wanted to hug him for that. But not long after, we had another person counter:

'Doesn’t make them wrong either. Loudness is a subjective thing… Without loud people who advocate for a point of view, progress is slowed. '

And so on. Needless to say, this latter person is someone I would classify as "loud," and not in a good way, more in the jerk way. And herein lies what I believe to be a common misconception that has gained popularity in the circles that I monitor as of late: the idea that being "quiet" or "meek" equates to just allowing the status quo to continue.

A False Hero Narrative

And so folks adopt this notion of the "loud" persons being the main ones who stimulate change and make progress, that is, they believe that obnoxious folks are the heroes. They use this idea, so far as I can tell, primarily as an excuse to be total assholes and to treat those with whom they disagree in very bigoted, harsh, and uncompromising ways. I've seen this over small issues (e.g., internal coding style debates) and, more commonly, with regards to big social issues.

I get the attraction of the idea. It's freeing to not hold yourself to rules of civility. It feels good to be thoroughly convinced of one's righteousness. It feels great to feel so right that you think you don't have to be fair, kind, and thoughtful. There's something very satisfying in looking down your nose at those who hold opinions different than your own. And hey, if you get to do all that AND add on top of that a sense of being a hero of progress, oh boy, that's some serious catnip! This turns being a blinkered, contemptible bigot into a virtue. And it's all thoroughly self-reinforcing.

But despite it feeling really, really good, it's false and wrong. And the simple fact remains that your average person naturally despises those who act that way.

Some Real Heroes

Was Ghandi "loud"? Was Mandela "loud"? Was MLK "loud"? Was Lincoln "loud"? These are among the most towering figures in the world's social progress, but I don't think anyone would call them "loud" in the sense described above. On the contrary, most of these folks were comparably meek, but they were certainly persons of strong conviction. It was the strength of their conviction, not their "loudness," that makes them such remarkable figures worthy of admiration and imitation. By and large these folks were known for treating others with kindness and consideration. Being kind and considerate is not at odds with having firm convictions. You can speak plainly and unequivocally without speaking insultingly or demeaningly or dismissively to others. It just takes extra effort.

Plus, as Carnegie covers at some length in How to Win Friends and Influence People, treating others well and kindly tends to have an outsized impact on bringing them to your point of view. That, coupled with conviction and (one hopes) actual truth and right, tends to have far more influence than being a loudmouth jerk about your point of view.

Progress in Science and Thought

And if we looked at the list of influential scientists and philosophers, precious few among them could be construed as "loud," and yet their contributions have shaped so much and driven much progress. Was Marie Curie "loud"? Was Thomas Aquinas "loud"? Indeed, it is exceptional to be "loud" among this group. And yet this group of people has had immeasurable impact on the course of human history, that is to say, they created significant and lasting change and progress without being "loud."

Probably a contributing factor is that introverts tend towards these kinds of disciplines. As a rule, we prefer to express ourselves through our work and creations, than directly being active in social circles. But I think it's easy for us to embrace the message that we don't need to be socially civil. After all, we don't really like socializing and social niceties to begin with, so if someone comes along and tells us that it's fine and that we don't need to and that, in fact, it's better not to, we're all too ready to warm to that message!

But as noted above, it's just not true. Being a jerk alienates people far more than it does anything else. And when you alienate someone, you create even more hurdles than you already had in bringing them to your point of view. Being "loud"--being obnoxious and inconsiderate--is not only not virtuous, it's regressive and counterproductive, if your goal is to create change in other people. You can't simply dismiss others' points of view as invalid. You can't simply berate them for being wrong. You shouldn't expect that such abuse will lead to #winning. If it does, it's in spite of such behavior, not because of it.

What Being Loud Is Not

Being loud is not, simply, standing up for what you believe to be right. Being loud is not, simply, voicing and acting on what you believe to be right. Being loud is not, simply, being unwilling to put up with the status quo. Being loud is not, simply, sticking up for yourself and others whom you think are being mistreated.

All of those things are indubitably good, considered in themselves. And it's unfortunate that sometimes people confuse those activities with being obnoxious. This tends to happen when someone else's point of view, in itself, rubs you the wrong way. It can even be just because you don't like the way someone looks, sounds, or smells. It can be based on the group/ideology that a person associates with. So many incidental (and sometimes unconscious) things can incline you to interpret another's actions as obnoxious even when they are actually not.

Some Ideas On Figuring Out How Not to Be "Loud"

I am by no means going to try to delineate what precisely the objective line of obnoxiousness is; however, I would suggest we have a few things to look at when asking if one is justly acting with conviction without being "loud":

Consider the act or words in question, independent of your larger ends. If you strip away your end goal (of change or progress), is it still a good thing to do or say on its own? If not, I'd suggest it likely ought not be said or done. Contrary to Machiavelli, the ends do not justify the means.
Consider the direct impact on the other. Again, looking at the immediate action/words apart from an imagined end goal, how will that action impact another human being? Does the action harm another? And especially, do you intend harm? If the result would be harmful, you should not do it. Often, you can ask yourself, would I want this said or done to me? (You know, the Golden Rule...) But it's good to also keep in mind that others have different sensibilities, and so it can be better to ask yourself that while putting yourself in their shoes as best you can. "If I were that person, would I want this said or done to me?" We'll never get that answer 100% right, but it certainly helps to ask both versions of this.
Consider if a reasonable, disinterested third party would perceive the act/words to be inconsiderate or disrespectful. If you're in the thick of it, it can be hard if not approaching impossible to do this, but it can help to at least try and ask yourself this. Imagine if you really didn't personally care about the outcome of a disagreement, and examine from that point of view. Try to find analogies to some topic you actualy don't care much about and see if you'd find the behavior objectionable in that case.
Consider your own motivations. Are you saying/doing something just because it feels good at the time? If you're angry, this is usually the case—just wanting to express anger without regards to purpose or consequences. I've often deleted messages and stopped myself from doing or saying things, because I thankfully recognized I wanted to do/say it just because it felt good. Sometimes I even allow myself to admire the cleverness of an argument or retort, but I recognize it won't contribute to a good end. (Sadly, I know I've failed to stop myself even more times!)

I find that considerations like the above help to suss out when something is "loud" or not. You can sorta try to invert and consider the same questions when examining the behavior of others, but you have to be really careful about imputing motivations. So much can and does go wrong when we try to guess at others' motivations! Doing that almost always makes a tough situation worse. But at least you can look at the behaviors and try to examine them according to the first three considerations above.

If you can muster the wherewithal to do so, you can often diffuse situations by considering these things. Just going through the exercise can be enough to pull back from the brink. From your own perspective, biting your tongue might be the better option, at least in the short term. Or spend the effort to look for other options that are better directed towards the good. Asking clarifying (not leading!) questions can help a lot, too.

Being respectful and civil and gentle goes a very long way. And that, of course, is the opposite of being "loud." So if you're at least trying not to be "loud," there's a good chance you won't cross the line, and you can still work towards your larger ends, often with more success. Being "loud" in the sense above is very rarely a good thing, and it's certainly not virtuous in itself. It is not a measure of your devotion to a cause or an indicator of the depth of your conviction.

When you think about it, it's kind of lazy to be "loud." It takes more effort and self-discipline not to be. You might say that it's "only natural" to be "loud," which is why it's so easy and tempting to indulge in that kind of behavior. We are rather selfish and inconsiderate by nature, and it's only with practice and effort that we temper that. This increasingly popular idea of embracing being "loud" as a good thing is just us indulging our lower desires, and it's generally less effective in achieving our ends. It's better to be better than that.

Technical Interviewing is Broken, But We Can Fix It

Ambrose Little — Mon, 31 Dec 2018 18:59:08 +0000

Don't worry. I know I'm not the first person to point this out (ex: here and here and here and here--geesh, 4.3K claps! AND HERE and here and here and here and here and here). This post comes both from my personal experience as an interviewee over the years, as well as my over fifteen years experience hiring other technical people.

First, allow me to attempt to establish at least some credibility. While I am no "famous" developer, I have had my fair share of accomplishments in my over eighteen year career. Not everyone will be impressed, and I'm totally fine with that. There are absolutely many far, far, far more impressive individuals in this industry, but I do think it's helpful to realize where I'm coming from in this critique and why I think I have at least some chops to make the critique.

I've worked as a dev, architect, technical product manager, developer interaction designer, team lead, and director.
I've worked in seven industries (and depending on how you count it, more), at tiny companies to as large as Verizon.
I've worked as a consultant, individual contractor with my own business, and employee, both on site and remote.
I've managed and hired developers/engineers, architects, graphic/visual designers, interaction/UX designers, dev advocate/evangelists, and dev tools product managers. As part of this, I've designed numerous versions of hiring processes from scratch, and iterated on them, and done my best to learn from others in the process.
I've been responsible for multimillion dollar budgets and large globally distributed teams.
I have co-authored four developer books, more dev articles and blogs than I can remember, and spoken at many developer events.
I have been awarded three patents, received the Microsoft MVP award eight times, and was inducted into the INETA speakers bureau.

Believe it or not, I am not a raging egotist, as I hope most of my colleagues would attest. I suffer from imposter syndrome at regular intervals as much as anyone. I only lay these qualifications out for context. With all the many things I do know about making software, I know there are many, many more that I do not. I mainly write the above to remind myself that, yes, maybe I do have something meaningful to offer in this ongoing conversation. More than once I decided to not write or publish this, but I am doing it!

I have a degree in European History with a minor in Humanities. I have taken a few CS courses, but the vast majority of what I know comes from on-the-job learning and extracurricular self-teaching. I don't, in general, devalue CS (or related) degrees, nor would I suggest that not getting one is a better way to go if you want to get into software development. I have tried to make up for the gaps in my formal training, and I dare say that I've been relatively successful in doing so, but it's just plain harder without a CS degree in this industry.

So What is Broken?

I already touched on this and offered some suggestions for a better way here. But I'll just lay this out there. Despite the above, I have been told by interviewers in the last year that I am "not technically strong enough." Say what?

Please keep in mind that I am talking about more or less average full stack and/or front end jobs, within the scope of the tech stacks I am familiar with. I know my limits. I'm not going around applying for embedded development or OS development or development in pretty much any low-level language/domain. I am not applying for highly specialized domains like data visualization, machine learning, etc. I am not applying to jobs with stacks that I have no experience with. No, these are run of the mill jobs for which I have oodles of evidence that I am more than capable to do effectively. After all, why would I seek out a job that I know I'm going to immediately be found out to be an imposter?

And just how have these folks determined this definitive fact that I am not technically strong enough? Care to guess? If you said, "a live coding test with a random brain-teaser type problem you'd find on codewars.com," you'd be right. Now don't get me wrong, I have also passed interviews with these sorts of tests. Hmm.. Isn't that odd?

And you know what else is odd? I have never, not once, not ever, been let go due to technical incompetence. I know for a fact that code I wrote over fifteen years ago is still alive and kicking in production. I've written code that is in daily use by at least hundreds of thousands of people. I have never, not once, not ever been told by a manager that I really need to shape up on my technical strength.

What I have been told by managers and colleagues, however, is that I write clear code. I have been complimented on my thoughtful, usable architecture, my attention to documenting my code where necessary, and my care to leave the campground cleaner than how I found it. I have been told that my code has fewer defects than some of my colleagues, both in testing and in production. I have been told by fellow senior devs, senior architects, CEOs, CTOs, and senior VPs that my architectural and technical contributions and advice are highly valued.

And yet this silly little coding challenge that (I suppose) they think I didn't do well enough or took too long to solve or whatever is definitive evidence against all this that I am not techincally strong enough to do essentially the same job I have successfully done for well over ten years? I say something stinks, and it's not my cat's litter box.

And importantly, keep in mind that I am but just one example of this problem. As noted above in the article with 4.3K claps, I'm definitely not the only one! I just want to add my story to the mix. And if you want examples of folks more noteworthy than I, check out rejected.us.

The Stifling, Strangling Elitism

As I was pondering all this, it occurred to me to ask my mother (just purely coincidentally as we were driving from the airport) how they do interviews in her line of work. She has a BS, MSW, and MPH and serves veterans in the VA but has also worked in other contexts. She started explaining PBI to me, and I was like, "Yeah! We do that, too, but we also have these little arbitrary and largely irrelevant technical challenges..."

You know what she asked me? She asked if this was a recent problem in our industry. She asked if something had changed to cause this dysfunction. I actually don't know how this started, but I have some speculations. And I think it started largely from the same source that our massive problem with the gender gap has come from. To put it bluntly, it comes from a bunch of nerds who get their self worth from a sense of intellectual superiority. To be fair, I count myself in that lot, but I have tried to mindfully get better as I have become more aware of this shortcoming.

Somewhere along the line we started this mythos of the computer geek, and it is basically a story of a not-fully-socially-able male who counterbalances that deficiency with his remarkable genius. I hardly think this stereotype needs me to provide evidence for it. Just go hang out on HN or Reddit, or, well, pretty much anywhere that there is a preponderance of wannabe alpha male geek types. And somewhere along the line, this (almost-completely) boys club decided that it wanted to stay exclusive. It started early. If you read the book Hackers by Steven Levy, you'll find its germinating seeds.

Thankfully, our industry has been waking up more and more to this problem, but our practices are still catching up, and I suggest that this interviewing tactic is a manifestation of this problem. It in no meaningful way is a predictor of job performance, but it is a great way to 1) make the interviewer feel smart about himself and 2) weed out the "riff raff" to keep the club exclusive. After all, the only way to be a technically strong, productive member of the team is if you can "whiz through the easy stuff at 100 m.p.h."

You might be wondering where that last quote is from. It's from what I'd say has likely given this form of interviewing its greatest gust of hot air: none other than the founder of StackOverflow Joel Spolsky and his "Guerrilla Guide to Interviewing." That guide has been promoted in the dev community through his (otherwise largely good) "Joel Test" that companies rate themselves on for StackOverflow job postings. Most of the twelve questions are good indicators, but #11 is the one I'm calling out here: "Do new candidates write code during their interview?"

And of course if you follow the breadcrumb, you will arrive at his Guide. As with the Test, his guide has good points, but in the section on "writing code," he not only illustrates massive elitism but also even advocates for the much maligned whiteboard coding technique. Perhaps the outmoded notion of whiteboard coding could be forgiven based on when the guide was authored, although there's no good reason he couldn't have walked a candidate to a local desktop even in those earlier days.

But I digress. I made the assertion of elitism, so I should support that. Note his story about how rare "good" programmers are, how so few make it through pointers and recursion in classes, how just learning Java is so terrible. Let's look.

"If the basic concepts aren’t so easy that you don’t even have to think about them, you’re not going to get the big concepts."

The problem with this is the ambiguous notion of what "basic concepts" are. I mean, if they really are basic concepts, then the statement is a truism. The problem tends to be that every dev, every interviewer seems to have their own notion for what "basic" means. It was recently asserted to me that using a bitwise XOR to find the number in an array repeated odd times is "simple" (i.e., basic).

Joel continues, mocking those he says can't cut it in CS degrees: "...They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers." Do you hear the condescension dripping? Only the special anointed few have this brain part. That there is a neurological mechanism that only some people have is quite an extraordinary claim, when you think about it, with essentially no evidence offered to support it than his personal anecdote.

He then derisively uses the term “script jocks” and says, "all good programmers should be able to handle recursion and pointers, and that this is an excellent way to tell if someone is a good programmer." He even says, "I want programmers to know programming down to the CPU level." I seriously wonder how that is relevant in these days of serverless, containers, and immense virtualization. But even in 2006, it was hardly relevant to 90% of software application development (the kind of thing his company did). I'd even suggest it was in some ways less relevant then, but that's a topic for another post.

It's not entirely clear if he means to say that recursion, pointers, and CPU-level knowledge are basics or just what makes a "good programmer." It is clear that even if he does not think these are "basic" that he considers them important and shibboleths for determining good vs. bad programmers.

Now I know there is gonna be a subset of folks in this industry who will eagerly nod their heads at what Joel writes here. They are gonna look askance at me, agreeing that knowing that const circleArea = r => Math.PI*Math.pow(r, 2) is something you just can't get by without knowing in this industry. They believe that const startsWithCap = s => /^[A-Z]/.test(s) is just critical to know by heart, as is const sumArray = arr => arr.reduce((acc, curr) => acc + curr, 0).

(For the record, I had to remind myself that Math.PI exists in JS rather than hard-coding 3.14159 as an approximate, and I had to look up the pow function--I was thinking maybe there was an exponential operator like ^, but I remember now that's for bitwise XOR. I guess that tells you how often I've had to use those things despite being a productive full-time JS developer for years.)

I honestly don't disagree to some extent that these problems seem basic to me, but the problems themselves tell me almost nothing meaningful about a candidate's general software development ability. And I heartily disagree that recursion and pointers are the litmus test of a good developer. I think they are useful things to understand, but at best they are relatively mundane details. Many devs are productive and get by with a passing understanding. Learning how to traverse a tree is something easily learned, and again, you really don't need to know it by rote for most app dev. I'm not really sure where grokking pointers has much practical import, but I'm all for having deeper-than-strictly-necessary understanding. I'm not saying that knowing these is not helpful but rather that they are hardly indicators of what makes a "good" programmer (whatever that means).

Frankly, if all a company did was ask me Joel's example problems or even quiz me on recursion and pointers, I'd find that to be a relief! But in my experience, the current state of tech interviewing in 2018 tends to be more on the clever brain teaser side of things. For example, in one case I was given the problem of rehydrating a binary tree from two arrays. In another, I was asked to find the coordinates and bounds of N rectangles in a two-dimensional array (where 0 is background and 1 is part of a rectangle). One company's interview protocol even suggested that one ought to prepare by going to codewars.com and practicing. I did that, and that's where I ran into the aforementioned solution const findOdd = (xs) => xs.reduce((a, b) => a ^ b) was highly voted as a "best practice" if you can believe it.

The point is, these kinds of problems are about as irrelevant to what makes a good developer as is how they might choose to make their coffee or tie their shoes, i.e., not at all. Being able to quickly solve these kinds of problems is a discrete skill that can be learned, as Laszlo Bock notes in his great book, Work Rules! (which I highly recommend!). These brain teasers don't predict future performance; they just tell you the person is good at brain teasers (i.e., they've practiced them).

I also once had a colleague (who had interviewed and passed me) tell me that he just wants to see evidence that a person can code. His particular tool of choice was the relatively simple challenge of reversing a string. Okay, fine, you want to see someone can actually code, but really? Is that really a real concern? I would like to know if anyone has ever hired someone who claims actual experience making software (or formal training) who literally cannot code. Seriously! If so, that's an easy termination of employment conversation.

Give me 10 minutes with a candidate, and I can ask a handful of structured interview questions that give me more insight into their abilities as a developer than 100 of these ridiculous tests give you. AND I will be able to confidently tell you if the person can write code, without ever having seen them do it. I once had a manager give me a hard time, because he asked me to "tech" a candidate, and I spent the time asking PBI questions. I told him that it would have been supremely clear to me based on their responses whether or not they actually could do the job. And I was right. This particular dev was highly competent, if a bit too clever in some of his solutions (in my opinion).

I have digressed a bit here, but only by way of illustration. The typical "watch someone code" interview problems are no more than a way to screen out folks who don't perform well on the fly, artificial, stressful situations, on isolated problems that have little to no relevance to the business of making software.

So if these tests have (and have been shown to have) such little predictive power, why are they still, after all these years, the go to screening tool? I doubt there is one answer. I think laziness is part of it, or more generously, priorities. In smaller shops, devs (and barely trained managers) are expected to run technical interviews, which makes it quite the ad hoc affair. They likely remember how they were drilled, do a quick internet search for tech interview questions, grab a few, and go to town. I've seen this happen more than once!

But even in software companies that have fully staffed recruiting organizations, they use these. There is even a cottage industry of folks who claim to "solve" this problem for companies, by offering this vetting service for them! The one I mentioned above that was encouraging people to practice codewars was such a firm--one of many. People who have the budget and staff to do better are just not.

Naturally, we nerdy engineering types like to try to solve things with "data." We think most human problems can be better handled through some kind of software intervention. So we frame the problem in terms of questions like, "how can we remove bias?" (which is definitely valuable), but we never seem to zoom out that extra level and question whether these kinds of evaluations are actually meaningful and predictive. It's the equivalent of trying to figure out how to make a drill a better hammer.

I think anyone would be hard pressed to show a real correlation between performance on these kinds of questions and actual competence on the job. And that's in large part because measurement of competence is hardly an objective activity in itself. Much like processes, every dev shop has its own ideas on what metrics are important to measure, each company has different things it values, and increasing these values is what constitutes success and competence. As with most complex human endeavors, once you isolate things down enough to be able to somewhat objectively measure them, they are too focused and distanced from the whole to really be meaningful.

And yet we cling to these seemingly more objective tools to evaluate candidates. We pat ourselves on the back for using "data" and leveraging our special engineering skills to solve the very difficult human-centric problem of predicting success in a role on a team delivering a product or service for other humans. And when data doesn't align, we will of course do the human thing and ignore it or reinterpret it or question its validity for this that or the other--because our nature is ever to justify what we already believe rather than face up to evidence that contradicts it and demands alteration of our beliefs.

A Persistent, Dangerous Mythology

So it's a persistent mythology, at best. But it is a dangerous mythology. Because unless you are one of the big, top tech companies with oodles and oodles of highly qualified applicants beating down your doors, the chances of passing over great candidates who happen to just not do well with these kinds of tests is very high. While the top tech companies can afford, due to sheer volume of applicants, many false negatives, most others in the industry really cannot. The demand for talent far outstrips supply, as is well known, and companies that create even more hurdles--particularly those that don't really tell you anything meaningful, suffer as a result.

There is also the likelihood of perpetuating the diversity gap, because implicit in these kinds of tests is a "let's see if you are like me" mentality. In this case, the "me" is the special snowflake genius developer who can solve such problems on the fly easily. Women already suffer in our industry because the false generalization is still popular enough that they are less capable in this kind of work. We saw this on ever-so-public display thanks to James Damore's "manifesto," and folks defending it. Whatever socio-cultural and biological influences may contribute to averaged differences in interest, the more problematic beliefs lie in the perception that such gendered interests indicate capability in individuals. In other words, these stereotypes result in women who are actually capable and interested in STEM being institutionally and pervasively dissuaded from pursuing it.

As this article notes, "It is, for example, a hallowed tradition that in job interviews, engineers are expected to stand up and code on whiteboards, a high-pressure situation that works to the disadvantage of those who feel out of place." In other words, these kinds of interview techniques disproportionately disadvantage those who already have a sense that they do not belong (i.e., are in the tiny, looked-down-upon minority of ~18%). Add that to the relatively high likelihood that the (most likely) male alpha geek interviewing suffers from bias (unconscious or not), and it further skews the results of such evaluations towards the negative.

On top of that, as this article by Triplebyte notes, there are other admitted and stated biases against perceived "types" of developers. So-named "enterprise" and "academic" developers suffer from a strong negative bias at these companies, and I've personally seen that to be true in the elitism against C# (which I happen to have a strong background in) and .NET in general. For many, that I was awarded MVP by Microsoft is bizarrely an anti-indicator of my competence. Thankfully, I get some creds for my deep JS experience (which is fairly ironic to me considering how long JS has been poopooed by "real" developers). In any case, it's clear if you're not hip to the "cool" tech and backgrounds, such bias will lead to skew interviews towards the negative.

So-called enterprise devs are also more likely to not have formal CS backgrounds. They are more likely to focus on solving actual business problems with useful and capable abstractions (like .NET or Java or whatevs) than tinkering with lower level algorithmic problems or, e.g., writing their own compilers. Thus they are less likely to perform well on these kinds of tests. AND YET, they are absolutely productive, capable members of teams creating profitable software for businesses.

To restate, the danger for companies is missing out on otherwise well-qualified individuals due to largely arbitrary, biased, and non-predictive technical evaluations. They also tend to reinforce tribal, alpha geek monoculture that excludes perspectives and experiences from those with more diverse backgrounds, talents, and aptitudes.

We're All Special Snowflake Unicorns

I think the popularity of these kinds of evaluations is also driven by an over-inflated sense of the difficulty of what we do. Every company likes to imagine that it's special and has unique needs that can only be filled by "the best." I've never seen a company that doesn't claim in some way that it "only hires the best." Of course, we all know that can't even remotely be feasible, but we like to say it and like to believe it.

This belief in our own tribal superiority leads us to over-estimate the importance of our interview evaluations. And our industry exacerbates this problem by focusing more on things that ultimately matter less to our team success. These tech interviews illustrate that. When we "screen" people, we screen based on things like lists of technologies and/or how well candidates tech out.

Contrariwise, we often neglect or only pay lip service to the more important aspects like "plays well with others" and "is hard working" and "readily helps others" and "isn't a primadonna." We like to throw around "passionate," but why isn't this part of initial screening? Team collaboration and people/soft skills are just as every bit important to a company's success as particular technical competence. I would argue they are much more so, on average. As I said here, "working together is about relationships as much as it is about skillsets."

Further, tech is always changing and evolving. The way we build apps today is significantly different from the way we did it 10 years ago. The tech stacks we use have evolved greatly in the last five years, both on the front and back end. This churn shows no signs of decreasing. Unless you're just hiring a short-term contractor, it's as, if not more, important that someone has evidence of effectively learning new tech and new patterns. Why aren't we screening for that up front? (And why aren't companies more serious about ongoing learning? Why aren't more companies investing in training up people who even don't have experience?)

The reality is that with few exceptions in specialized domains, most of what we do is not that special and not that different from the next employer (or your candidate's prior/current employer). Do we really think that what we do requires so much more vetting than the last place (or 10 places) the candidate has worked for? Do we really think that our vetting processes are so damn special that we're gonna magically get better results than the rest of the industry? (Hint: The right answer should be a resounding "No." If you doubt me, go browse this site for a bit.)

So How Can We Fix It?

First off, if you have done these kinds of interviews, you shouldn't feel stupid or bad. They are still basically the "state of the art," and despite the enormous evidence that they are not predictive, most folks just don't know that because they're too busy to know that. A big part of why I wrote this is to help raise awareness. But now you know. Now you can do better.

Unless you're hiring a person with little to no experience, chances are high that they've already successfully created software at other places. Your goal then is not to determine basic programming competence. I'd say your goal is primarily to get to know them, and let them get to know your company and/or team. Talk openly and honestly about your environment, your practices, your current initiatives and future aspirations. Hopefully they'll have questions for you. Use Performance-Based Interviewing (look it up) to drill into how they've done things in the past. Read up on techniques to eliminate bias in doing these structured interviews. It will be a handful of hours well spent, I assure you.

One option is to ditch technical interviewing altogether. The author makes some good points. Ultimately, it is about when the rubber meets the road. This company even offers a "$7,500 quitting bonus" within your first 90 days, which I think is a little brilliant because it makes it safer in the off chance it isn't working out--neither you nor they need to "feel bad" about the separation. Something like this can also mitigate against recruiter fees and bonuses, which typically get paid out after 60-90 days. These approaches do require not being lackadaisical about those first days; you probably want to be ready with a way to determine if everyone is happy with the fit.

But I think we can still do some degree of interviewing--as long as its to give the applicant a chance to show their strengths. And that is where the PBI approach helps, by focusing on what they've actually done rather than quizzing on hypotheticals or arbitrary evaluations. I've found these as great tools to get to know folks better and get a very good sense of their strengths and weaknesses. Drilling into what people have actually done, why they did it, and asking deeply technical questions around this gives a ton more insight--the single biggest predictor of future performance is past performance.

But if you really, really must see someone code, at least make it have some semblance of what they'd be expected to do on a daily basis. And if you're open to giving them room to pick up "your way" of doing things, as I hope you are, then maybe instead of asking for a task based on what you do, ask for one based on what they say they've done. You are in a better position to map what they've done to your needs than for them to try to guess/learn your expectations on the fly.

I previously advocated (and used) the take-home coding task approach. That is still much better than typical in-person coding challenges, but it is onerous and raises the bar a lot for applicants in terms of personal investment, which isn't good in a competitive market like we have. It also disadvantages those in life situations that don't allow them to invest much time outside of their primary jobs (e.g., single parents or parents of larger families, people with second jobs, etc.). Even if you offer compensation, it still is a big ask. What I found in using that approach was that I got much more value from bringing someone on site to review their solution. We learned a lot more from them during the design and code review than the task implementation itself. Which leads me to..

A better option, I think, is how my current employer does it. They ask folks to bring in a project that shows their work, walk the team through the solution and review it. One of the better indicators of future performance is a relevant work sample, and nothing is more relevant than real work they've actually done. We like to encourage folks to bring something they're proud of, but personally, I would be just as happy going over something someone wasn't proud of and having them explain why and how they'd do it differently next time. In addition to being a much, much, much better indicator than random coding challenges, it is also 1) far less artificially stressful and 2) often mimics what you might do in real life during a peer code review.

If someone doesn't have a project they can readily review with you, you can still offer a task as an option--even collaboratively create it.

Obviously, there's a lot more to it, but I hope, at the very least, this critique makes those who use the stereotypical coding challenge approach to reconsider. I hope that enough of us continuing to share why they are so problematic will eventually turn the tide in our industry towards more effective approaches being the norm than the exception.

Here's to a wonderful new year!

P.S. There is another option for those of us on the interviewee side--to boycott these kinds of interviews. I admit I am very close to thinking that is a good thing to do. To be honest, one reason I personally choose not to is as a personal challenge--I am egotistical enough to want to see if I can pass despite knowing how meaningless the tests are. Still, unless you're just really hard up for a job or really want a particular opportunity, it might be a good option to gracefully bow out. You can point them here or to one of the many other things online by way of explanation. :)

UPDATE (1 Jan 2019): Someone pointed me to this post about how (at least parts of) Microsoft has also recognized the deficiencies of the old interviewing approach and has worked to change it. Now that's a pretty in depth process, but the benefits are many. Well done!

An Introvert's Guide to Being Sociable: Sending Argumentative Emails

Ambrose Little — Mon, 12 Nov 2018 18:03:43 +0000

The next installment in the "Introvert's Guide to Being Sociable" series..

Sending Angry or Argumentative Emails

This is definitely a weakness of my own. As a writer and a naturally argumentative person who very nearly always has to be right (or at least feel like I'm right), I am very susceptible to sending (usually long) emails to debate things with someone at work. As folks who work on computers all day and usually do actually do a lot of important communication through writing (emails, Slack, whatevs), it's natural to fall into this one.

And it's not always wrong or a bad thing. Sometimes you do need to address things. Sometimes it helps (or is necessary) to do it in writing.

But I've learned a few techniques over the years to help me determine when I really need to send these versus when I just want to, in the heat of the moment.

Go Ahead and Write

Yep. That's right. Type that puppy up. If you don't, you most likely will just stew about it in your head, thinking of all these wonderful things to say. Write it. Let it rip. Say everything you want to say, and don't worry too much about editing yourself at this point.

Remove the TO!

BEFORE you start writing, remove ALL addresses from the TO, CC, and BCC. One of the worst things that can happen is for you to prematurely hit send, especially if it's emotional. A lot of email programs have shortcuts like ALT+Enter. You can accidentally type that. So just save yourself the potential embarrassment and remove the addresses. Another option is to compose in a different editor just to avoid the accident altogether.

Don't Send (Not Yet)

Once you've written it. Don't send. You can do an editing pass at this point, if you feel you really want to. But the best thing is to just save it in your drafts. Close the email. Now get back to work. You're going to let it sit for at least 24 hours.

I can't stress enough how important this is. You got it all out. Now just sleep on it. Wait at least a day.

Review It. Edit.

Now you've slept on it and given yourself some time to chill. Before you review it, ask yourself if you really think it's important to send it. I say ask before, because if you reread or think too much about what you wrote, you're likely to get yourself worked up again. It's better to ask yourself this with a cooler head that isn't thinking about all those great flaming points you made. The point shouldn't be "I must prove myself right" but something more productive.

With the end goal of forward progress in mind, if you do think it's still important, go ahead and review and edit it. If you find yourself still feeling upset, it might be good to save and wait another day.

Sometimes, at this point, I'll just email it to myself rather than keeping it in draft. That way I have the text where I can go back to it, but it's not sitting there demanding I do something with it. Many times, I've found this itself exorcises the need to actually send it. Sometimes others involved in the convo will make the salient points I was thinking, so I can pass the torch, as it were.

Better in Person?

Very much advice out there will tell you to talk to folks in person, rather than write. I agree this is something to seriously consider, particularly if you feel that there needs to be a lot of back and forth, and if you feel you're not being understood (or maybe not understanding them). A face-to-face talk is usually best, even video face-to-face. Phone calls are okay, but you still lose a lot of the non-verbal communication. Generally speaking, 1-1 conversations are better than group, when resolving differences. See if you can go to lunch or grab a coffee or a beer or something with the other.

This is hard for the introvert, but the reality is that 1-1, face-to-face usually will end up better with real resolution, than continuing through some other medium. It helps both of you remain aware that you are both real human beings and not just an idea that you don't like. It's easy to fall into dehumanization when arguing in writing. And talking through things in person also helps to build or rebuild a real relationship with the other person.

But sometimes, you just need to get your thoughts all out there without interruption. Sometimes, if you're like me, you might do better expressing yourself in writing. And if you take the advice of waiting and editing and reminding yourself of the goal of forward progress/resolution, then you can avoid getting sucked into emotions that may trigger by being in person again. So it might still be better to write.

By waiting, though, you're giving yourself at least a chance to sift through these considerations. As I said, many times I have decided that it's just not worth it. I delete it. Or I send it to myself. Sometimes I send myself the long version with all the "stuff" there, but I send a much briefer, action-oriented response to move things forward with the other person.

And sometimes I still give in and regret sending, but I have found that to be less often the case than when I don't follow the steps above.

Send It

If you've decided it's best to send, and you've waited and edited. Double, triple, quadruple check that the TO line is to the right person. Accidentally emailing the wrong person--something I've done--is also super embarrassing when it's a touchy subject.

Rinse and repeat if the discussion continues. But if it does, the chances of talking in person being a better path increase with each reply.

Bonus Tip: Social Media

The above are also good things to consider when posting on social media. Sometimes I'll write something up in Gmail and sit on it there before posting. This has saved me a lot of trouble and wasted time. And also, unfollowing threads can be very helpful, if you decide not to continue to engage. Just remove the temptation. These days I rarely argue on social media, and then only with actual, real friends whom I care about. It may sound counter-intuitive, but I find having a real-life friendship helps such discussions to have a better chance at remaining productive.

An Introvert's Guide to Being Sociable: Faux Openness to Feedback

Ambrose Little — Thu, 25 Oct 2018 00:45:38 +0000

Introduction

Some time ago I wrote a post about how to be awesome without being a jerk. It has some concrete suggestions, which is helpful, but it's also helpful to learn by example. So this is my first entry in the series I'm calling "An Introvert's Guide to Being Sociable." The goal of this series will be to help introverts like myself become more aware of the things we do and say that, let's say, don't come across the way we think they do--or more like, when we don't even realize we're doing something wrong.

I've heard other introverts say, and I can relate a lot, that being in social situations is exhausting. And by that I mean situations extending beyond a very close friend that we feel more or less completely comfortable being ourselves around. The kinds of social situations that are exhausting generally involve folks we're not super close to, and as the number and degree of our familiarity with those persons decreases, our anxiety and feeling of having to "work" just to "be" around them increases.

So we are those types--the ones who really need "alone time" to recharge at the end of the day when we have to be in such social situations (and this often means just a regular day at the office). Sadly, for us, being sociable doesn't really come naturally. We have to put a lot of what feels like unnatural effort into it, and it's even more exhausting knowing that we're probably not doing a great job.

Unfortunately, I'm not aware of any magic mantras to make us feel more at home and comfy, but what I hope to do with this series is to offer examples where I have observed where a person (many times myself, upon later reflection or discussion with others) kind of "steps in it," in one way or another. These will be all real examples, and maybe also some general tips that I've learned. The idea is to pepper our brains with examples, so that our minds will start to innately form patterns from them and help us to avoid making the same mistakes.

I am by no means, believe me, an expert, but it is an area I have actively worked on throughout my adult life, and I hope I've learned a few things. And while I'm on the general topic, I can't recommend How to Win Friends and Influence People enough. It has stood the test of time, and is a fantastic primer in this area. I was fortunate enough to have it recommended to me in my early twenties, and I've reread it at least a few times since.

As for organization of this series, these are more or less disorganized--as I remember them or observe new ones, I'll add. Remember, these are things that we do almost always unconsciously--so the goal is not to feel bad for having done them but rather to become more aware so that we can do better in the future. Without further ado, the first example...

Faux Openness to Feedback

Let's say you have created something--a product, a tool, a service, etc. This happens a lot in software development, IT, systems engineering, etc. We put a lot of thought, blood, sweat, and tears into making a thing. And we put it out there for people to use. We want our creation to be appreciated.

Inevitably, it will not be appreciated by everyone all the time. So people will have opinions and feedback. We want to think of ourselves as people who are open to feedback--to improve the thing we made--so we say, "if you have any suggestions or feedback, just let me know!" or some variation on that.

And then the feedback comes in. Sometimes the feedback is.. not nice, but even when it is friendly and constructive, it still feels like our baby is being called ugly, so we fall into defensiveness. We start looking for ways to justify and explain why it is the way it is. We sometimes (especially when the feedback is mean) want to strike back. "Boy is this person an eye-dee-ten-tee." "Man, that has to be the dumbest idea ever." "If they only understood it..."

Trust me, I've been there. It's normal. Feeling this way isn't particularly limited to being an introvert, but I think we tend to be less apt at communicating back in productive, healthy ways when this happens.

Things Not to Do

Explain why it is the way it is.

Yes, this seems innocuous, but it is more often than not just a manifestation of a defense mechanism. The person providing the feedback, unless they say otherwise, almost certainly doesn't care why it is the way it is. You asked for feedback, and they gave it. Don't try to dismiss or minimize their feedback by way of explanation.

And this is so very hard for an introvert, particularly for technical introverts--because we actually do care why things are the way they are. We are fascinated by the intricacies of details. How could someone NOT want to know the beautiful thought and rationale that went into it!?!

But just don't. Hold that in. Kindly take the feedback and try to see it for what it is--it is someone else's perspective who doesn't have (and probably doesn't want to have) your knowledge about why it is the way it is. What is valuable here is that it is a great learning experience to put yourself in someone else's shoes, often the very people that you want to use and be happy with what you made. And if they don't appreciate it, sadly, it is a failure of Design somewhere.

Feedback is a great jumping off point into learning the mental models of the people who are using your thing. The more you can get into that mental model and reflect it in your design, the better your thing will be (for them) and the more your baby will be appreciated for the beautiful thing it is.

Tell Them to RTFM

Or some form of that. Actually, if someone has to read a manual to use your thing, it better be darned complicated. Think of needing to use a manual as a failure of Design. It's not always, but many times it is.

Tell Them Some Other Way to Do It

Okay, so this one is a little tricky. Often, depending on the context, giving someone some way to do what they want to do is important and helpful. But there are good and bad ways to do this, and times when we shouldn't do it.

"ALL you need to do is... 1, 2, 3, 4, 5... SEE? It's easy!"

If your inclination or response is something like the above--where you are thinking in your head like "I don't get what's so hard about doing this!"--then you need to STOP. Technical people tend to be far more patient with adapting ourselves to technology than the general populace is. People (and let's be honest, if we had our druthers, we'd prefer it to) just want it to work, and be easy. I mean, barring things like games where the challenge is the point of the thing.

I've worked in quite a few contexts in my life, including making commercial tools for other devs, and where I've seen this the most is devs dealing with other devs. Dev A loves the CLI. Dev A thinks it is easy as pie to type 30 commands in a row--much easier and better than some dumb UI. While Dev B prefers to point and click, or have some tool or other abstraction that lets them get to the same endpoint without knowing and using all those commands. OR, Dev C loves X editor or OS or shell and is super proficient in it, but Dev D has more experience and prefers another. And so on..

So, the right way to handle this kind of situation is to thank someone for the feedback, say you will make a note and look into how you might be able to make it work the way they expect, and then say, "in the meantime, I can show you a way to get that done today..." AND then you gotta listen more. If they say something like "no thanks," don't force it. If they tell you they're not familiar with some tool involved, don't say "don't worry, it's easy" or anything like that.

The overriding thing here is to make yourself more aware that other people lack a lot of what you take for granted, and that doesn't make them stupid or lazy. Listen to where they are coming from and try to adapt yourself to their mental model and context as much as possible, but don't get so focused on completing the task that you bowl over them in the process of "helping" them.

Search teh interwebs for 'Nick Burns SNL' and watch it. It parodies this kind of thing--and it's obvious that we do it, or it wouldn't have become a thing enough to be parodied! "Move!"

Tell Them What They Want to Do Is Not Worthwhile

This sounds kind of obvious when put this way, but I have seen so many manifestations of this it's kind of crazy. The worst offender I've seen is throwing this chart into the discussion. I outline in that post why, but for our purposes here, it's just a way that you can (accidentally) be a jerk.

Don't ask "why would you want to do that?" Umm.. think about how to rephrase that, if you really want to know. If you don't really want to know, if you're asking rhetorically because in the back of your head you're thinking it's stupid and a waste, DO NOT ask this. Just keep your lips zipped.

"That doesn't really save much time." Okay, maybe not. But most people in these situations are less focused on the time involved than the subjective experience involved. Obviously, if someone is taking the time to provide feedback, it passed a reasonably high bar of subjective disatisfaction. Your job is not to pass judgment on the objective worth of their disatisfaction. If you asked for feedback, your job is to listen and try to understand.

"That doesn't make any sense." Believe it or not, I have heard variations on this. Ironically, thinking that is essentially how the person giving feedback probably felt when trying to use your thing. So rather than judging the sense of what they're saying, try to better understand why they expected it. Again, your goal is not to get them to go away or to defend your thing. Your goal is to understand their perspective, their motivations and expectations. Accept and affirm their perspective, rather than judge and defend your own.

Insist on Having the Last Word

Don't do it. This is good general advice, and in this context, it tends to apply to when you've already started down a bad path by doing one of the above. For example, if you start explaining it, the other person will feel inclined to explain their perspective, and you both grow increasingly defensive. And I say this 100% from personal experience--it can be one of the most difficult things to just shut up and let them have the last word.

As someone who is very good at arguing and can often argue successfully and still ultimately be wrong, this is a hard thing to learn and even harder to practice. Because it's like a good chess match--move, counter move, formulate strategy, plan moves in advance, and watch the "enemy" fall into your clutches. Exhilarating, but completely counterproductive when you are asking for feedback.

Remember the goal. To understand and adapt your thing so that more people love it. You won't get there by arguing with people, no matter how satisfying that feels in the short term. (As an aside, this applies in most life situations.)

What Do You Think?

Do you think this sort of thing is helpful? Do you have your own examples? I'd love to get more folks sharing their own examples so we can all learn from each other. Feel free to contact me personally, in a comment here, or even publish your own in the series. Something like, "An Introvert's Guide to Being Sociable: <your example>" would be fine, and link back here/post a comment. Maybe we just make a unique-enough tag, like #socialskills, to categorize these together, or if I find enough, I can manage a list post..

DocToc - Too Cool

Ambrose Little — Tue, 28 Aug 2018 13:30:07 +0000

Just wanted to give a quick shout out. I am working on some more somewhat heavy-duty docs in Markdown (on GitHub Enterprise in this case). I was beginning to despair about having to manually manage a TOC for a relatively long topic, when I decided to search.

I found this nifty tool DocToc on GitHub. It's exactly what I needed, is easy to use, and has appropriate configurability.

You can control where the TOC is injected with comments. You can control the max levels (I think 3 is a good default), and you can then just npm i -g doctoc and run it for folders and individual or sets of files.

Too cool! So glad it's there. And hey, it should work for dev.to articles, as well.

The Top 3 Ways to Fail at Interviewing Software Developers

Ambrose Little — Mon, 23 Jul 2018 22:30:28 +0000

Okay, now that I have your attention… :) But seriously.

Let’s start by defining terms. When I use the word “software,” I mean real-world, productional business software. You know, the kind that makes the world go round. I admit there are many other kinds of software, but I’ll limit myself here to speaking to the kinds of software I have built in various capacities for over eighteen years now.

And when I say “developers,” I mean software (see above) developers, most typically what we now call “full stack,” but I think the fails below apply to more specialized roles within software development — to a point. My criticism of algorithm evaluation, for instance, may not be appropriate if the software being developed is heavily related to the algorithms being evaluated.

Nota Bene: I have been interviewing software developers (and other software professionals like designs and product owners/managers) for at least fourteen of my eighteen years. I by no means will claim that there is only one way to successfully screen developers, but it seems to me there are definitely some common ways of doing this that tend to feel a lot like fail to me — from both sides of the equation, as well as better ways, such as those suggested below.

WITH FURTHER ADO, in ascending order of failfulness…

3) Ask “clever” brain teaser questions. I don’t care if they are “clever” coding problems or non-coding (of the manhole cover variety).

As the SVP of People Ops at Google, Laszlo Bock, writes in Work Rules!: *Insights from Inside Google That Will Transform How You Live and Lead *(Ch. 5 — Don’t Trust Your Gut ):

Performance on these kinds of questions is at best a discrete skill that can be improved through practice, eliminating their utility for assessing candidates. At worst, they rely on some trivial bit of information or insight that is withheld from the candidate, and serve primarily to make the interviewer feel clever and self-satisfied. They have little if any ability to predict how candidates will perform in a job. This is in part because of the irrelevance of the task (how many times in your day job do you have to estimate how many gas stations there are?), in part because there’s no correlation between fluid intelligence (which is predictive of job performance) and insight problems like brainteasers, and in part because there is no way to distinguish between someone who is innately bright and someone who has just practiced this skill.

And he adds:

Some of these interview questions have been and I’m sure continue to be used at Google. Sorry about that. We do everything we can to discourage this, as it’s really just a waste of everyone’s time. And when our senior leaders — myself included — review applicants each week, we ignore the answers to these questions.

I remember when these were all the rage. I’m glad that time is mostly over. (I personally was asked once about how I’d design the ideal alarm clock…)

2) Ask obscure computer science questions.

You know what I mean. The “find the nearest node in a tree” or “capitalize the second letter in an array of words” or “what is the big O notation for X sorting algorithm.” In almost every case, a quick internet search can reveal what a developer needs to know about known algorithms for solving particular kinds of problems, or just reviewing for half a day the literature (e.g., on Wikipedia) on particular problem areas. And in many cases, such optimized algorithms are baked into popular frameworks, because they are general purpose and not domain-specific — so an average dev will rarely need to know them. But again, if they do, it’s not hard to refresh and not at all a big indicator of any important factor of success in a developer role.

As with #1 above, more often than not what these kinds of questions do is serve to make the interviewer feel smarter. (We get excited because we can stump people with a problem we already know the solution to.) And because these are very common interview questions, candidates will often prep for them. So again, not very helpful in determining anything useful.

I’ve interviewed fresh CS degree grads who could easily solve one of these algorithm problems but who barely know what a relational database is, have barely touched source control repositories, and wouldn’t know TDD from HIV. Which of these are more important for a professional software developer’s success?

1) Ask a candidate to live code in front of you.

I mean it. This is the most egregious thing you can do as an interviewer, and yet it is absolutely the most common thing devs get asked to do. It’s one thing if it naturally comes out of an interview discussion, like you’re discussing code, and it would just be easier for the candidate to write up some code or pseudo code to show what they mean. Usually, I wait for a candidate to volunteer to do this, but I never give them a problem and say “code the solution for me right now” on a whiteboard, in a shared screen program, or whatever.

“But everyone does this!” I can hear almost everyone exclaim. Indeed. I think maybe it’s a hazing ritual at this point. Like, “we all had to go through this, so you do, too.” LOL. No, I get it. We want to see how well they can code, or at least that they can code. But there are other, better ways.

This problem is exacerbated when the problem definition changes on the fly. Interviewers think they are adding layers of complexity to mimic real life changing requirements when in reality they are mostly adding layers of very artificial stress that will induce stupid mistakes that obscure a candidate’s true abilities.

This is an important point. Interviewees are already stressed and nervous. It’s easy as an interviewer to forget this. As an interviewee, you are putting yourself out there for someone else to judge you and your work, and deem you worthy or unworthy of a job that, in many cases, you see as key to your (and your family’s) livelihood. That’s kind of a big deal.

So as an interviewer, you’re usually dealing with someone who is in the midst of a significant life stress event. Add to this that developers tend to be introverts — they are not performing artists — and that few things stress introverts out more than being in unfamiliar social situations with unfamiliar people.

And then we ask them to essentially become a performing artist in code? To solve a surprise challenge on the fly while their every pen/keystroke is being scrutinized? What about this screams “this is how this dev will perform under normal circumstances” to you?

Nothing. That’s what. The closest thing in real dev life might be pair programming, but that is in a far, far less stressful context, typically with people you know relatively well (and hopefully get along with), dealing with a problem domain you have had time to get to know, and the goal is not to test your skills. The goal as is to help each other — you are partners, with a shared goal of making the best software together. So not even pair programming is like live coding in an interview; it is so only very superficially.

And all of this assumes that you have come up with a reasonably good problem that is scoped small enough and has a domain common enough to be readily familiar to any interviewee. For example, asking someone to code a tic-tac-toe game, when no software they are going to build every day is even remotely a game and rarely requires any sophisticated graphical layout skills, would be a bad idea. So, if you’re gonna do this, keep it stupid simple, like here’s some sample data (a list of movies); now display those in a table or a card list or some such.

“Ah, but giving a novel unfamiliar problem and watching them gives me insight into how they think!” goes the response. No. To reasonably interpret how a developer thinks (in general) from such an ad hoc, on-the-fly coding challenge far exceeds the psychological skills and knowledge of pretty much any other software developer (and we’re the ones who usually do the interviewing). We’re fooling ourselves to think we are so clever as to analyze in any generally meaningful way how someone else thinks. It’s too unusual and small of a sample in any case.

And really, judging how someone thinks/approaches and solves problems is rather presumptuous. As if there is a “right” way to think to solve problems. Talk about bias! What matters is that they can solve problems, more importantly, that they can turn problems into maintainable, reliable solutions. And no ad hoc, on-the-fly test is gonna tell you that.

Just for fun, I want to mention you can double- or even triple-fail here, by asking someone to live code solving a “clever” computer science problem. And yet this happens. And to make it worse, it happens on whiteboards — not even a friggin keyboard and screen. “Writing code.. on a whiteboard...” (I imagine Roy from IT Crowd saying that like he said, “A fire.. at a seaparks…”)

The Common Thread

The common thread in all these fails is that what is being tested is only very tangentially connected to what really makes a software developer successful or not. This simple principle should guide what we strive for in shaping our technical evaluations: mirror real-world development as closely as possible.

Again, as our friend Laszlo Bock writes in *Work Rules!* (based on real data and science):

The best predictor of how someone will perform in a job is a work sample test (29 percent). This entails giving candidates a sample piece of work, similar to that which they would do in the job, and assessing their performance at it. Even this can’t predict performance perfectly, since actual performance also depends on other skills, such as how well you collaborate with others, adapt to uncertainty, and learn.

So concretely this suggests, for a developer technical evaluation:

Let devs work in an environment in which they feel comfortable (e.g., at home) or in the worst case at a computer relatively isolated so that they can quietly focus.
Let devs work without the artificial distraction and stress of being observed while they are working.
Let devs have access to the resources they normally use. When I first started interviewing in 2003, I told interviewees to bring books they like and gave them full internet access for an on-site test. These days, I prefer to let devs work from home/remotely.
Craft a problem that is realistic. That means a problem similar to what they will face on a day-to-day basis. If you are hiring front end, it’d be writing a small front end. If a mobile app, a small mobile app. If a full stack, a small slice of full stack. You get the idea.

Software development is a design exercise. This has a few implications for evaluating it. One is of course creating an environment that best facilitates and stimulates the mind. Contrary to this, high stress situations tend to work to the detriment of higher mental functions. It also implies that the best solution is rarely the first one that jumps to mind. We arrive at the best solution through freely exploring alternatives, going down dead ends, learning new things, and ultimately combining and iterating (and usually iterating further over time).

None of that happens in a high stress, ad-hoc, live coding situation. But by giving an applicant time on their own to come to terms with a problem and explore solutions, we get a lot closer to what real-world development is like.

Structured Interviewing

Another well-established method for more reliable interviewing is what they call structured interviewing. As Bock writes:

Tied with tests of general cognitive ability are structured interviews (26 percent), where candidates are asked a consistent set of questions with clear criteria to assess the quality of responses. Structured interviews are used all the time in survey research. The idea is that any variation in candidate assessment is a result of the candidate’s performance, not because an interviewer has higher or lower standards, or asks easier or harder questions.

Compare that to unstructured interviewing (the typical ask-more-or-less-whatever-comes-to-mind-in-any-given-interview-and-follow-it-where-it-randomly-goes). The research says that this is 14% (of predicting actual employee future performance). And you can imagine how that could be terribly variable, immensely subject to bias, as well as influenced by how you, the interviewer, might feel on any given day. In short, it’s not really fair, in addition to being far less reliable in predicting performance. (BTW, years of experience is only a 3% indicator!)

My Recommendations

What I have landed on is an at-home project for the primary technical evaluation, and then doing a code review of it with the interviewee (again, mirroring good, real-world development practices). The code review gives immense insight into 1) whether or not the applicant actually understands what they are doing and 2) how they interact with other team members (I think including at least two future peers is ideal).

I’ve actually been amazed by how some folks can’t really explain what they are doing with their solution. Like they just copied and pasted a framework/example from the Web — it’s very obvious, so I think it addresses the concern of it not being their own work. If you really want to know how a dev approaches development solutions, this is a much better approach. (I always ask for automated tests, as a bonus, and it’s amazing how few devs actually include them!)

Coupling this with structured interviewing leads to a whopping 55% indicator, and if you include what Bock refers to as “assessment of conscientiousness,” that adds another 10% of predictor power. You can get an amazing amount of detail if you use “behavioral structured interviewing” (a.k.a., performance-based interviewing — PBI), where you ask candidates for specific examples of when they did something or used a particular technology. Drilling into these gives a much deeper sense of what a candidate knows (rather than what they don’t know, which you get from asking questions with specific right answers).

As an example: “Tell me about a project where you used REST services.” Make sure they stay specific and don’t get into hypotheticals. Ask questions to clarify and dig deeper. You will get a good sense if they understand the ins and outs, what they do or don’t know, and how deep their experience actually is.

For the conscientiousness evaluation, I actually write up a handful of important attributes with descriptions, and then work on PBI questions that ask for examples in their experience, e.g., “tell me about a time you helped a co-worker with a particularly tough problem.”

Also, as noted/quoted above, “actual performance also depends on other skills, such as how well you collaborate with others, adapt to uncertainty, and learn.” This is easy for hardcore devs to overlook. We like the concreteness of the technical eval, but even a great eval as I propose here only tests the technical competence, which is arguably not as important as attitude, passion, curiosity, helpfulness, and the like, which dramatically impact their ability to adapt to new situations as well as work well with others.

Asking performance-based and/or “situational” (i.e., hypothetical) questions to drill into these areas is hugely important. “Can you give some examples of something cool you learned recently.” If they can’t quickly, that probably indicates they’re not the type always trying to learn. That might be a flag for you. (I think it’s a BIG RED FLAG.) As with the others, these should be the same questions you ask to everyone — it’s fair and it gives you the same criteria to evaluate people by.

To do this efficiently, either buy/use some specialized software (like Breezy.hr or Greenhouse.io) to let you create interview kits that have the same questions you will ask all candidates, or just write one up in, e.g., Google Docs. Have the interviewers take detailed notes, and then have interviewers individually fill out a scorecard for the various things you are looking to evaluate (which should map to the questions being asked).

Finally, you discuss with your hiring team. Google actually hires by committee (or so Bock says), and interviewers are not necessarily on the actual team being hired for. While I can see the value this introduces in reducing bias (especially that of the hiring manager), I haven’t tried that, and it may only work at scale. A drawback of that approach is you don’t get a feel from the actual team members and their interactions/chemistry, so YMMV on that one.

I’m not gonna claim this will guarantee success, but if you add it up, it gives you something like a 65% chance, much better than the 14% for stereotypical unstructured. Also, you can add years of experience (3%) and reference checks (7%) to add a bit more and get to 75% — pretty good odds. As far as I’m concerned, the more we can do to increase our odds of selecting the right/best candidates, the better.

This approach works both in tiny companies as well as huge ones like Google. I definitely don’t think I have it perfect — I learn more every time I go through a hiring process, but these are some great guidelines, based in scientific research and experience. It seems good and fair to candidates, as well. All around a win-win.

Post Script — Cognitive Evaluations

Bock cites the research that says general intelligence evaluations give you a 26% indicator, which is tied for 2nd place with structured interviewing. I have evaluated a couple of these tools. A colleague/friend of mine and I both took a few and reviewed each others’ results and talked about how well we thought they reflected our impressions of ourselves and each other. (We have a good relationship to be honest about things like that.) One test tool seemed better than the other — pretty accurate in fact. The problem is, they add another longish part of the evaluation (e.g., 30–45min or more). Bock also notes that such general intelligence tests discriminate against non-white, non-male test takers.

So far, I haven’t felt the need, but I have actually taken one as part of an application process as well. If you find you can’t get people to take a sample test project, it might be a good way to increase confidence in the hiring process.

Post Script — Online Testing Tools

My colleagues and I evaluated a few of these. My experience was that they tend to ask the kinds of questions above that I feel are not great indicators because they are too disconnected from day-to-day dev. That said, some people do swear by them. I’d say they are better than live-coding in front of someone.

I have taken (and passed) a number of these in my time. I don’t think they’re good in that they tend to add significant time pressure, which creates that highly artificial situation. You are testing someone’s immediate memory or ability to code a specific solution to a surprise problem in a short amount of time — not terribly realistic and also very limited in scope in that you find out more specific things they may not know by heart versus seeing what they do know and can throw together in a reasonable amount of time (as you get with a sample project).

As such, I don’t recommend or use them.

Post Script — Open Source

There are plenty — especially hipster types — who put a LOT of value on OSS contributions. If you are hiring specifically for someone who will need to do a lot of OSS contribution, that’s absolutely a real-world level thing to evaluate. Or if it is a core cultural value in your team/company. But I think a lot of folks conflate OSS contribution with general competence. Many very highly competent devs have only worked on closed source (and have families and other things they prefer to do with their free time).

I do think it can be a great help to evaluate ability, if someone does have substantiated contributions that you can look at. I’d even say that could be a reasonably good substitute for the sample project. The drawback can be that, without time-consuming digging, it may not be entirely obvious what exactly was their contribution. And with the sample project, you get the same evaluation for all candidates, which is more fair and gives a better comparative sense between applicants.

But hey, if someone is an OSS rockstar, then it’s hard to argue with that. :)

** Cover image courtesy of http://m1psychology.com/performance-anxiety/

How to Be Really Awesome at Your Job and Not Be A Complete Jerk

Ambrose Little — Sat, 14 Jul 2018 22:41:14 +0000

Some people seem to think that being smart and being really good at their jobs means that it’s okay to be a Grade-A Asshole. Like most of us, I’ve had the pleasure of working with a lot of smart people who are not assholes (and some who are genuinely nice), as well as the unfortunate burden of putting up with the opposite. This is not an attempt to skewer any individual now or in the past, although I definitely am drawing on real examples in my career. :)

How to Know If You’re A Jerk

Here are some common signs that indicate you may suffer from assholery:

You regularly think that other people are idiots, and probably say as much. You’ll probably comment on this post and say so.
You probably think that in any given room, you are the smartest person in the room. No. You’re pretty damn sure you are. You’re thinking you’re smarter than me right now, and probably just about everyone else who might read this — especially if they agree with me.
You don’t bother trying to understand and verify where someone is coming from, and quickly dismiss what they say as stupid if you disagree. You think I’m just writing this post because I’m not as smart as you and not as good at what I do. You’re so smart that you’re sure you can deduce others’ motivations (and their relative intelligence and knowledge about things) by reading one post by them, or looking at their code.
You don’t give people space to do it “wrong.” You work with them on a team. They have a job to do just like you, but if you disagree with the way they do something, it’s clearly “wrong” and “stupid” and requires you to drop what you should be doing to come in and “fix it.” Clearly, if you want it done right, you gotta do it yourself.
You don’t “have time” for people who don’t already grok everything that you do. I mean, it’s “so obvious!” What is wrong with these nimrods! You don’t have time to even read the next bullet point here.
Your first response (perhaps publicly, tweeted) to someone saying something you know to be factually incorrect is “Check out this f — king idiot who has no idea what he’s talking about.” And you think that’s a perfectly appropriate response. You must combat idiocy, after all. It’s a public service you are doing.
You can’t remember the last time you lost an argument. Obviously, this means you are smarter and better than everyone. It couldn’t be because people have just learned that you can’t be wrong. Ever.
You think that “being honest” means having no filter between your brain and your mouth. And you think that’s a good thing. You proudly and unapologetically can’t wait to honestly tell me this.
You think there’s nothing wrong with what I describe above.

The list could be vastly expanded, but that’s not the point. I’m not here to rant and vent. (Well not just to rant and vent.)

There is hope. You can get better.

How to Not Be A Complete Jerk

I know the signs of assholery because I have my own tendencies towards them. If you suffer from similar symptoms, I have good news. There is hope. You can get better. Here are some things I try to do to combat them.

Remind yourself daily (or more often — whenever you feel inclined to smirk at someone), that there are plenty of really smart, capable people in this world and, I mean, unless you are literally Einstein or Tesla or Musk or insert-renowned-smart-person-here, chances are, there are plenty of people as smart as you — and plenty who are even smarter, possibly even the person you are thinking is an idiot right now.
The same goes for being good at what you do. Unless you have, say, the most industry awards evar. (Most folks I’ve run into with this problem do not fall into this category, myself included.) I mean, you gotta actually believe this, but just telling yourself it at first may be enough of a start.
Remind yourself that being smart and great at your job is not the end all of life, the universe, and everything. Maybe, just maybe, simply being good to others is more important.
Instead of making a bunch of assumptions about someone, especially based on, say, one or even a handful of internet posts, actually personally engage. It’s best to do this 1–1, in private (i.e., not in a public forum) so that you can minimize the ego factor.
If you’re amazed at some terrible code, think about all the crap code that you’ve written. If you don’t have ready examples of this, you’re not improving. Think about that. Probably, they are just at another point in their career/experience/understanding than you are now. Maybe they are just you from a few months or years ago? (BONUS TIP: being self-deprecating does not give you carte blanche to bluntly criticize others. Saying “I used to write crap code like this, too” just doesn’t work.)
Breathe. Step back. Especially in situations where emotions are heated or you know you are in the right. Write up what you want to say right then. Save it. Sleep on it. Maybe even for a few days. Then come back. Most of the time, you’ll want to delete it, or at the very least, edit it. If you don’t feel that way, keep waiting. ;)
Re-read, slowly, what they wrote. See if they literally say what you took away from it. If not, there’s a good chance they did not mean what you inferred. This leads to…
Ask clarifying questions. Do so in a tactful way, though. The goal is to really understand more and more thoroughly, not to make a point or make yourself feel smarter. Avoid asserting what you think they mean in the question.
Put yourself in their shoes. Imagine if you were the one dealing with you. How would you react to what you are doing/saying? How would you want you to be?
Force yourself to help others, especially those less knowledgeable than you, regardless of your opinion of their relative intelligence. Go out of your way to volunteer your time to do this — keeping the above in mind as you do. Just going off and flaming people while “helping” them is not what you’re going for. :D
The next time you see someone doing something wrong, ask yourself if it’s really, really important for you to correct them. Hint: It’s almost certainly not. No. Really. Life will go on. The world will keep turning. There are very few things in this world where that is not the case. Is it really worth pissing that person off? Because unless they ask you, offering “free advice” or worse, stomping on/redoing their work for them, will surely do that.
Even if someone asks for help, if they don’t take your advice, don’t get mad. It’s okay. I promise. See above. Let it go. You did your part. Let them learn from their mistakes. (Heck, there’s a chance you might be wrong anyways.)
When engaging with someone, no matter who they are, ask yourself, “what can I learn from this person?” And try to find it. There will be something, I guarantee. And doing so helps to combat a sense of superiority.
If you believe in a higher power that wants you to be a better person, ask that higher power for help. Pray for humility, patience, and generosity. If you’re Catholic, go to confession, pray, and go to mass more often.
Cultivate self-awareness. Spend time at the end of each day reflecting on how you acted in relation to others. Especially if there were disagreements, analyze those in light of the suggestions here. Sometimes all it takes to improve is to make yourself more aware of how you’re doing — it’s a good goad to make you want to improve.
Read/learn about people who have unselfishly given their time or even their lives in service of others. Or maybe just someone you know who seems to be admirable in this way. Seek inspiration in the example of others. Just making yourself more mindful of others’ examples can help.

Years ago, very near the start of my career, a colleague recommended How to Win Friends and Influence People to me. I thought it was corny, but I read it. For the introverted, somewhat autistic types that seem to thrive in the software industry, I can’t recommend it enough. It has simple, time-tested advice that does more than help you not to be an ass; it can help in general in interpersonal situations.

Do you have recommendations that have helped you?

How to Be Really Awesome At What You Do

Step 1: Work on your people skills. See above. Most of the time, we need to work with others to achieve something greater, so learning to work well with others — and help others excel — is a key skill to cultivate. And for most of us, I suspect it really is something we have to work on. Others are just talented in this area, lucky them.

Step 2: Always be learning. This is doubtless important in most professions, but it is absolutely critical in software development. You should learn at least one new thing every day — and be able to talk about it and share it with others.

Step 3: Help others learn. As noted above, this is good to help develop one’s self interpersonally, but it also helps your own technical skills. Forcing yourself to explain something to others is a great way to learn, both about the subject but also about how others think — if you also get feedback from them on how you’re doing. Getting feedback also helps check yourself, that you are actually helping.

Step 4: Apply yourself, daily. Good programmers are lazy by nature — we are always trying to find ways to optimize performance and reduce effort for everyone. But no matter how smart you are, you ultimately still have to put in the time and effort to get and to stay better. You can’t rest on your laurels or you will fall behind.

Step 5: Take time to play and explore other things. If all you do every day is software software software, you will not be as awesome as you could be if you diversify your interests and enjoy other things. Your brain benefits from the off time, and you will learn things from other fields of interest that you can apply in your work that you never would have otherwise. You will see interesting and useful patterns to leverage. And anyways, it’s fun. Having more fun will make you a funner person, too.

Needless to say, this is not an exhaustive list. What would you add?

Do You Work with an Asshole?

Send them a link to this. NO! I’m kidding. That would be a total jerk move. :) Sadly, I don’ think there’s much to be done at a peer level. Maybe they do need to be confronted. If you feel up to it, do it. Be ready for the blowback. And be ready for it not to help. Be ready for it possibly to make it worse.

Often I think the best you can do is hope they come across something that makes them wake up and realize they need to improve. Some people know they need to work on it, and just need gentle reminders. Others really don’t care. My opinion is that workplaces — managers — need to be better about recognizing and not putting up with it, particularly those that don’t seem to care.

The problem tends to be that these folks are often good at what they do, and it takes a very principled business person to sacrifice what they perceive as a good performer “just because” that person doesn’t play well with others. Of course, most business folks I’ve worked with would readily agree on a “no-asshole” rule and understand its value to the business. But I have found it rarer for that to actually translate into action and reality. “They are really good at what they do, after all.” And it is a tough market to find good people.

I think that, at least, a good manager/leader needs to be actively working to help difficult, high performers to work better with others. Sometimes radical candor is what you need. Sometimes people just need the experience of real consequences to wake them up. Taking action with such folks is not only good for your company holistically; it’s probably gonna be a good thing for that person, a wake-up call.

And dare I say that in terms of cultivating diversity in the workplace, this issue is even more important to work on? The “alpha male” mentality is actively hostile to creating an atmosphere in which people of all stripes can thrive.

What advice do you have for dealing with people like this, as a peer or a manager?

—

So there is always risk in writing something like this, risk of coming across as precisely what you are criticizing. But I think it’s worth the risk. The more we talk about this stuff, the more we let it permeate the industry, the more we will improve. Making ourselves collectively more aware can only help lead to action.

We, in software especially, have a real problem. We attract people who are not known for their interpersonal skills to begin with. We reward, more than anything, excellence in technical skillset. We sacrifice holistic good of teams and companies for the sake of top performers. I think we can be better.

As individuals, we can and should work more on cultivating our interpersonal skills. I promise doing so will only make you more successful. As company leaders, we need to help individuals cultivate these skills; we need to lead by example and demonstrate these skills; we need to reward these skills; we need to hire for these skills, and sometimes, yep, we need to fire because some individuals won’t or can’t develop them. It’s good for business, and it is the right thing to do.