Interviewing Programmers
I'll be looking for a new job soon, readers!
And this has been cause for some reflection.
In Emeryville, CA, there is an "international food hall" called the Public Market. "International food hall" is not a common phrase, because international food halls are not common buildings. But it is basically a food court leveled up a few times---a food court, if you made it eight times the size and gave it its own building.
The software world is kind of like this: a lot of people with very different worldviews crammed in together.
What, in your opinion, are the core concepts of this whole software thing? The real important stuff?
If you look around, people seem to have very different answers to this, or answers-in-the-form-of-a-culture. For some it's "agility," for others it's "testing," for others it's "optimization." Steve Jobs (at least at first) would probably have said it's "empowering creativity." Paul Graham might say "brevity" or "programmer power." Ken Iverson might have said "notation." Conor White-Sullivan or Fred Engelbart might say "tools for thought." My data scientist brother might say "extracting insights from data at scale." Google has said it's about organizing information; Mark Zuckerberg has said it's about connecting people. Disney sees it as a gigantic but treacherous channel; Patrick McKenzie has said it's about solving business problems; Erik Dietrich would probably say that anyone who wants you to believe too hard in any one of these is a little too motivated to find a way to justify underpaying you and convince you that you shouldn't leave.
It's a big field, and I suspect I haven't mentioned a quarter of it. (missing things off the top of my head: ML research, conversion flow, command line fluency, system design, databases, games, graphics, functional reactive programming in the Conal Elliott sense, VR, belief networks, chord input, genetic algorithms...and you can likely list a dozen or so yourself.)
And they're all "correct"---any one of those is deep and bottomless enough that you could probably make a career of it.
But are they at the center? That's a bit harder of a sell.
I'm convinced that you could pick any two people from the tech industry (and why restrict ourselves to "the tech industry"? What about researchers, educators, developers in banking, finance, etc?), and they could come up with something similar---that is, they could identify a concept that one believed was fundamental, what are you even doing if you don't know/have experience with this, and the other had simply never had the time/interest/need.
Let's actually draw this out a bit: If computing has a bunch of different fields, and if each one is infinitely, and even fractally deep, in that you can't reach the bottom of a thimble any more than you can swim to the bottom of the ocean---
You can see how people's experiences could differ drastically, such that their perceived realities don't touch.
Anything I could write here has already been said by esteemed reddit user "jimmyhoffa523" in a thread on hiring from a few years ago:
As far as I'm concerned, this is The Answer. Accept that there are different perspectives on competence, and evaluate candidates based on their criteria. Ask them "What makes you think you could contribute around here?" and then listen to them. Mentally add "1-2 weeks of focused study on what we're doing, plus access to us, and the Internet" to your evaluation. Realize that most of your actual work isn't that hard. Presto, candidates galore.
The above is simple, efficient, and would work better than what the vast majority of companies are doing. But I think most companies won't do it, and I think many programmers wouldn't like it either.
From a company perspective---"Whoa whoa whoa, we worked hard to get this revenue stream/investment, we're not gonna just throw it away on unqualified candidates. We're trying to run a mean lean machine here." This isn't a rational response---it's not like current vetting practices work either, and having worked hard is immaterial to the market or to your actual needs.
I don't think programmers would like it either. "WTF, I killed myself in college, slept with SICP under my pillow, have stared actual monsters in the face when dealing with Maven, and regularly do the impossible to achieve business goals. You're saying I can be replaced by someone basically smart + good mentorship?"
(Note to programmers: No, you're not replaceable, but it's generally not because you're a hot-shot individual contributor, it's because you can mentor.)
And this is where Data Structure & Algorithms interviews come in handy. They provide a pretense of rigor so that companies can tell themselves they only hire the best and that they are doing hard intellectual work, and so that developers can tell themselves that yes, they do deserve those high salaries, The Company absolutely understands the value they bring (it doesn't).
We have a word for social conventions that exist to protect ego: Etiquette.
There's a great Theodore Dalrymple quote that gets passed around:
Dalrymple's point is that one of the main reasons for forcing others to lie is as status adjustment---to lower the status of the one forced to repeat a lie.
But if we assume everything is relative (and with status, it often is), that suggests another possible perspective---that lies can be used to raise the status of the one "forcing" others to lie.
In other words---if you politely assent to someone else's lie, this can be a very reassuring signal to them. Wow, they must be important! What they say goes!
In other words: you should not put much stock in the interview process. But there is a sense in which it is very impolite to say so. And if people are willing to pay you hundreds of thousands of dollars for a month of focused study---well, why not?
And this has been cause for some reflection.
In Emeryville, CA, there is an "international food hall" called the Public Market. "International food hall" is not a common phrase, because international food halls are not common buildings. But it is basically a food court leveled up a few times---a food court, if you made it eight times the size and gave it its own building.
The software world is kind of like this: a lot of people with very different worldviews crammed in together.
What, in your opinion, are the core concepts of this whole software thing? The real important stuff?
If you look around, people seem to have very different answers to this, or answers-in-the-form-of-a-culture. For some it's "agility," for others it's "testing," for others it's "optimization." Steve Jobs (at least at first) would probably have said it's "empowering creativity." Paul Graham might say "brevity" or "programmer power." Ken Iverson might have said "notation." Conor White-Sullivan or Fred Engelbart might say "tools for thought." My data scientist brother might say "extracting insights from data at scale." Google has said it's about organizing information; Mark Zuckerberg has said it's about connecting people. Disney sees it as a gigantic but treacherous channel; Patrick McKenzie has said it's about solving business problems; Erik Dietrich would probably say that anyone who wants you to believe too hard in any one of these is a little too motivated to find a way to justify underpaying you and convince you that you shouldn't leave.
It's a big field, and I suspect I haven't mentioned a quarter of it. (missing things off the top of my head: ML research, conversion flow, command line fluency, system design, databases, games, graphics, functional reactive programming in the Conal Elliott sense, VR, belief networks, chord input, genetic algorithms...and you can likely list a dozen or so yourself.)
And they're all "correct"---any one of those is deep and bottomless enough that you could probably make a career of it.
But are they at the center? That's a bit harder of a sell.
Locking Horns
When people with different perspectives meet, conflicts arise. In a Hacker News thread on interviews from a few months ago, two consecutive comments:>Everyone with real work experience has a story about sorting.
I am 34 and an experienced coder and I literally have no stories about sorting
I'm convinced that you could pick any two people from the tech industry (and why restrict ourselves to "the tech industry"? What about researchers, educators, developers in banking, finance, etc?), and they could come up with something similar---that is, they could identify a concept that one believed was fundamental, what are you even doing if you don't know/have experience with this, and the other had simply never had the time/interest/need.
Let's actually draw this out a bit: If computing has a bunch of different fields, and if each one is infinitely, and even fractally deep, in that you can't reach the bottom of a thimble any more than you can swim to the bottom of the ocean---
 |
| Each of those barrels is much larger on the inside than it appears on the outside. |
You can see how people's experiences could differ drastically, such that their perceived realities don't touch.
A Beautiful, Humane Proposal...
Anything I could write here has already been said by esteemed reddit user "jimmyhoffa523" in a thread on hiring from a few years ago:
I used to have a lot of exercises and questions that I would ask that seemed like basic things that anyone would know. What is a left join? What is a private IP address? What is the default port for HTTPS? etc. At some point I tried this on the smartest guy I work with, and he missed half the questions. Half of them.
At that point I realised that to do an interview well, you have to let go of everything you think of as "basic" knowledge, and instead turn the interview around and try to find some way that the person can convince you he/she is a good programmer. Find out what their story is, what they're proud of, what they're interested in but never got a chance to work on, etc.
...The other thing I've learned is that there are pretty much no basic skills that everyone on the team needs. It's really valuable to have a few people that can troubleshoot, but if you have someone that's organised, articulate, raises morale on the team, etc., but they can't troubleshoot for shit—well, they're still a valuable asset to the team. Same goes with someone that doesn't communicate really well, plays well enough with others but isn't super collaborative, but can troubleshoot crazy problems and can do certain important work in days that will take other people months.
If you're really looking at the long-term goals of your team, you shouldn't be thinking about whether this person meets a basic litmus test, fits the needs you think you have for the position, or fits your idea of what the role is; it's far more important whether the person you are looking at is likely to bring something valuable to the table without bringing too many faults with them. You can always adjust the role or the team around the hire.
As far as I'm concerned, this is The Answer. Accept that there are different perspectives on competence, and evaluate candidates based on their criteria. Ask them "What makes you think you could contribute around here?" and then listen to them. Mentally add "1-2 weeks of focused study on what we're doing, plus access to us, and the Internet" to your evaluation. Realize that most of your actual work isn't that hard. Presto, candidates galore.
...That Could Never Work
The above is simple, efficient, and would work better than what the vast majority of companies are doing. But I think most companies won't do it, and I think many programmers wouldn't like it either.
From a company perspective---"Whoa whoa whoa, we worked hard to get this revenue stream/investment, we're not gonna just throw it away on unqualified candidates. We're trying to run a mean lean machine here." This isn't a rational response---it's not like current vetting practices work either, and having worked hard is immaterial to the market or to your actual needs.
I don't think programmers would like it either. "WTF, I killed myself in college, slept with SICP under my pillow, have stared actual monsters in the face when dealing with Maven, and regularly do the impossible to achieve business goals. You're saying I can be replaced by someone basically smart + good mentorship?"
(Note to programmers: No, you're not replaceable, but it's generally not because you're a hot-shot individual contributor, it's because you can mentor.)
And this is where Data Structure & Algorithms interviews come in handy. They provide a pretense of rigor so that companies can tell themselves they only hire the best and that they are doing hard intellectual work, and so that developers can tell themselves that yes, they do deserve those high salaries, The Company absolutely understands the value they bring (it doesn't).
Good Manners Consist of Petty Concessions
Grueling interview gauntlets exist to support various egos. Companies can tell themselves they hire the best; accepted candidates can avoid impostor syndrome; rejected candidates can console themselves that at least there's a reason to their rejection beyond bad luck.We have a word for social conventions that exist to protect ego: Etiquette.
There's a great Theodore Dalrymple quote that gets passed around:
In my study of communist societies, I came to the conclusion that the purpose of communist propaganda was not to persuade or convince, not to inform, but to humiliate; and therefore, the less it corresponded to reality the better.
Dalrymple's point is that one of the main reasons for forcing others to lie is as status adjustment---to lower the status of the one forced to repeat a lie.
But if we assume everything is relative (and with status, it often is), that suggests another possible perspective---that lies can be used to raise the status of the one "forcing" others to lie.
In other words---if you politely assent to someone else's lie, this can be a very reassuring signal to them. Wow, they must be important! What they say goes!
Kid: Look Mom, I can fly! (jumps off couch)
Mom: Yes, dear.
In other words: you should not put much stock in the interview process. But there is a sense in which it is very impolite to say so. And if people are willing to pay you hundreds of thousands of dollars for a month of focused study---well, why not?
One hundred times yes.
ReplyDeleteThis was an awesome text!
ReplyDelete