Hiring is Broken… And It Isn’t Worth Fixing
Usually I fly home from client sites late in the day, but the whims of fate had me driving home instead, early (for me, anyway) this morning. The end result was a pocket of uncommon free time this evening, before resuming long days and seemingly non-stop travel on the morrow. Naturally, I wasted this free time poking around the internet.
My travels led me, via Twitter, to this blog post entitled, “F*** You, I Quit — Hiring Is Broken.” Apparently, this led to some heated, sometimes-angsty debate on Hacker News, where the original piece earned a good number of points. And, why wouldn’t it? “Hiring is broken” would serve as a rallying cry for those who don’t play the interview game well, while seeming a shot across the bow of those who do and are now on the other side of it.
Read the article, please. You need to for context, because when I reference it further, it’ll just be a reductionist tl;dr. I’ll come back to that. First, I’d like to address one of the few points that almost everyone seems to agree on, before they get down to armchair dissection of Sahat’s character and market worth.
The hiring process is imperfect deeply flawed (if not broken), but no one knows how to fix it.
Except, that’s not actually true, because I know how to fix the interview/hiring process. It’s actually pretty easy. Just stop doing it. If the value proposition you’re offering to prospective laborers is so weak that you have to solicit and subsequently torture strangers, you should prioritize fixing your organizational mess above making the mess larger (or, in the case of attrition, before doing the same thing again).
I’m honestly not kidding, but let me come back to the mindless growth point later.
A Sort of Impedance Mismatch
Let’s return now to the post and the tl;dr. Here’s my summary of Sahat’s essential complaint.
I’ve built some open source tools, shared some tutorials, and built a following in the programmer community, all of which constitute a form of social proof and demonstrated value to the industry. But when I go to apply for jobs at a lot of organizations, particularly large ones (only Google is mentioned by name), none of this seems to matter. They could learn about me if they looked at any of this, but they don’t. My experience interviewing across the board has been so depressing — so assembly-line and bureaucratic — that I’m ready to give up. I don’t think that I’m all that great a programmer, necessarily, but clearly people out there value what I do, and there’s clearly a programming shortage, so something doesn’t add up.
The conclusion here is that the hiring process is broken. Companies need talent, he has talent (which he feels is at least somewhat demonstrable by his community presence), and there’s a recruiter-driven, bureaucratic mass in the middle preventing a happy match.
I’m going to post part of the first comment that shows up in response to Sahat’s post, from Erick, a software engineer at Google.
I don’t have time to read your github projects, or your blog, or your existing code, or your meticulous attention detail in your commit messages. I get a resume in, I look at it for 10 minutes, if it’s sane I set up a phone screen. ONLY to prove that you can pass the most basic coding test. You need[sic]
Once we meet in person, you need to show me that you can code and articulate a design to a problem. The format sucks, sure. But you need to be prepared. I’m not going to spend 2 hours reading your blog for every candidate that I interview. I don’t have time for that.
(As an aside, this is an example of a defender of the hiring process conceding that it’s not actually all that great — in this case, “the format sucks.”)
This comment got 64 hearts on Medium, whatever that means. I’ll assume it’s upvotes, and so I’ll assume that this is a popular counter-point to Sahat’s popular post. And it sort of encapsulates a basic valuation of the process. Sahat (having been spurned) says, “your hiring process is broken because it didn’t select me.” Erick of Google says, “now wait just a minute — it’s obviously not broken because it did select me.” I get that they’re not actually saying this consciously, but there’s clearly skin in the game on either side.
But let’s look a little beyond that at the personas and see that they’re both right. Sahat has poured a lot of work into open source and community contributions, and people around him have expressed that they derive benefit from this. At the very least this means that Sahat can ship software and mentor newbies. That’s what companies are looking for, but instead of spending half an hour looking at his body of work, they spend half an hour peppering him with trivia. It wastes his time.
Erick is busy and he’s being saddled with dozens of resumes to sift through on top of his job writing software. And, you can bet that happens in his nominal free time — Google doesn’t hire chefs and masseuses and jugglers and whatnot out of the goodness of its heart, but because it wants employees to spend lots and lots of hours at the office. Google is a megacorp that probably needs to feed 1,000 newbies a day to the internal machinery, so his job isn’t to look for unique snowflakes but to thumbs up a handful of these things and go home. Google jobs are in high enough demand that, even if some recruiter does initially reach out to you, the onus is on you to prove yourself, since there are 200 people just like you, competing for this role. Read your github profile? You’re wasting his time.
And herein lies the impedance mismatch. Interviewees want to be evaluated and match-made as individual humans while interviewing organizations (large ones, anyway) want to evaluate people as livestock commodities. Who’s right? Well, I dunno — it depends whether you’re looking for a meaningful connection or for a serviceable burger.
Handling Interview Bureaucracy
This is shaping up to be a long post, as mine often are, but I do promise to come back to my opening concept of not hiring. But first, I want to talk about the trouble I have with Sahat’s perspective. It has nothing to do with him thinking these interviews are stupid — he’s absolutely right about that. It has more to do with his choices, such as knowing about Google’s process and doing it anyway. Why do that at all? And why do it again and again at other large orgs and at startups imitating large orgs with their hiring processes.
So if you’re in Sahat’s position, here’s my advice for you, and I’ve blogged about this before. Don’t take interviews with Google and other megcorps with this style of interview. Seriously, just don’t do it. At one time, these companies were scrappy, little startups with game-changing innovations. Now they’re more like government agencies than world-beating innovators.
I mean, seriously, listen to Erick’s description of Google’s hiring process. When I’m hiring programmers, I don’t have time to look at your background and see if you’re good at programming — I just get resumes, scan them for keywords, set up a phone screen and administer the trivia. Is it just me, or are you half expecting him to tack on, “look, buddy, I don’t care about your ‘civil liberties’ — there’s a lot of people behind you, so just take off your shoes and belt and go through the metal detector.” But instead of asking you to put all of your liquids in 3 ounce containers, he just concedes that the process sucks.
And that’s where you want to work? At an organization so innovative that the best they can do when it comes to hiring developers is to act and talk like a government-sponsored bureaucracy? Yup, everyone knows it’s stupid, but the process is the process and that’s that. Good grief. If you want to work at Google, forget the DMV out front — keep working on the open source stuff until they buy you out, and then negotiate from a position of strength.
But, even if you know enough to avoid silly interview processes by preceding reputation, that doesn’t insulate you against all of it. Start by telling recruiters, up front, that you don’t do trivia interviews and the like. Be firm and explicit about this, as in, “if they start asking me to describe merge sort, I’m going to thank them for their time and tell them I need to go.” You need to make it clear to the recruiters that it will be embarrassing for them if they don’t facilitate this requirement of yours. If you want to see this in action, here’s a page to which I refer recruiters, which contains a list of requirements for me to consider agreeing to an interview or a gig with a company. On of the requirements is as follows.
For interviews, no brain-teaser-oriented interviews or algorithm-centric interviews (see “The Riddler” and the “Knuth Fanatic” from this excellent video about interviewing anti-patterns). I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago.
Finally, if you’re already in the interview and this stuff starts flying at you, then excuse yourself. A lot of people say this, and I think they’re mustering some bravado and creating the impression that they would stand up, harrumph, and declare, “this is beneath me, and I say good day to you, sir!” That’s silly — it’s just bridge burning. Don’t do that. But don’t keep going. Instead, be apologetic, diplomatic, and earnest, and do it all while subtly shifting the power balance.
“Alright, why don’t you head on up to the board and show me how you’d balance a binary search tree.”
“Hmm… you know what? I’m really sorry, but I think maybe we got our wires crossed somewhere here. I’ve had experience on the hiring side of this sort of interview style in the past, and I’ve seen it result in some really sub-optimal matches, so I’ve adopted a policy of having certain deal breaker cues in the interviewing process. So at this point I can safely say I’d be unlikely to accept an offer, and I really wouldn’t want to waste any more of your time. To make up for the time I have wasted, I’d be happy to put you in touch with people in my network that I think would be a better fit for this style of organization.”
Let’s review. What you’re really saying (very nicely) is “you need to work on your hiring process, so I’m not interested in working here, but I can probably scrounge up a few of the kind of C players that would be a better fit for you.” You’d be amazed at how quickly people reassess you and alter the narrative of what’s happening to save face. It’s unlikely that they’ll reverse course and make you an offer, but you’re turning an impression of “meh, that loser didn’t make the cut” into “crap, I’m going to run to do some research on hiring best practices… just to prove that guy wrong, of course, but, seriously, ohmygod, are we doing it all wrong?” (If you’re a regular reader, what’s actually just happened is that you’ve refused to play the sucker’s/idealist’s game of “trivia contest” and offered an assessment of the organization that’s above the interviewer’s paygrade, which is some opportunist-fu that will blow the idealist’s mind).
Stop Hiring
Hopefully, if enough people stop lining up for the airport security screening process that is hiring at big tech companies, the emerging labor shortage will cause them to grow up and innovate when it comes to staffing developer talent. But, I wouldn’t count on it. The interview in its current incarnation has as much momentum as it does ineffectiveness, and I don’t expect it to die the death it should anytime soon.
So let me instead, put on my organizational hat and be philosophical. As I said in the beginning, I think the solution to broken hiring isn’t to fix it, but to stop it. And, by “it” I don’t mean to stop bringing on new people, but rather to stop asking strangers to submit pieces of paper full of exaggerations for your review so that you can bring them in cold, grill them for a few hours, and then welcome them to the family. Wow, it sounds almost… stupid.. when you describe it as exactly what it is.
Rather, what if you simply placed a creative constraint on the organization that it could not grow by hiring strangers or unknown commodities? I’ll grant you that this is an incredibly tall order, and the easiest thing in the world would be to list all the ways it could never work or all the concessions that would be needed. You’d have to grow a lot slower! Yes, probably, but I don’t know that growing like an out of control virus is the only way to succeed. You’d lose out on entry level talent! Maybe, or maybe part of your operations would be getting to know college kids. You’d be hiring based on nothing more than someone’s word! Well, you’re already doing that, but with someone that no one knows. And the list goes on.
I think of this in the same way that I think you’d have seen the Tesla a lot sooner if someone had waved a wand and said, “starting in the year 2000, cars can no longer be powered by gasoline.” When the status quo isn’t causing an international panic or creating an obvious and massive market opportunity, people are pretty comfortable with it. But if you imposed a constraint on yourself (ala Tesla), you might be amazed at what you could accomplish.
As I’ve started to explain in detail in my book, I’m more and more convinced that the next decade will show us a massive drop in the numbers of software developers working for megacorps and for non-software companies. The fact that the hiring process for developers, at scale, is garbage is just one reason, but it’s an important one. It’s so important, in fact, that let’s stop trying to fix the hiring process and start trying to figure out how to replace it.
By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.
You’re so picky. In the future I’m tempted to require >70% test coverage and an SSD in my workstation, or at least permission to supply my own. Given these elements, I’ll take it! 🙂
Yes you are hired if you’ll buy the SSD yourself.
I’ll just grab one from my stack of spares at home and will see you first thing Monday morning.
I know what you did there, you wanted orange juice without the bulp! You are fired
In my travels, > 70% test coverage makes you pretty picky as well. 😉
I’ve worked a good number of shorter term contract engagements in recent years and can say the same for my area. 70% is sadly, pretty much unheard of. Interviewed at once place that said they had something in the 90%s range, but no job offer. In hindsight maybe I should have gotten on my knees and begged. That might make a good LinkedIn profile heading: “Your Test Coverage % is the Same Chance That I’m a Good Fit for Your Team.”
IMHO, under 80% means poor coverage, and over 80% means POSSIBLE good coverage. It’s still possible to have 100% and skip a lot of scenarios that break..
Sounds similar to the sentiments presented in ‘Peopleware’.
Never read it, but added to my Amazon list since I’m doing a good bit of research in this arena. Thanks.
I’m a regular reader, and I just have to say, this post is especially well-written. A serviceable burger indeed. How soon until your book is finished?
Thanks! I’ve stalled a bit on the book of late, but I have actual, concrete plans to remedy that. I’m wrapping a consulting engagement right now and have specifically stopped taking new ones until I ship the book and one other thing. So my hope is in the next month or two. (Famous last words, but I do have a commitment device now)
My company has been hiring to the core product team exclusively through multi-year internships for over fifteen years, with amazing results. Of course, this practice fits mature companies better than startups.
It’s encouraging to hear that, and I take your point about mature companies… but I’d like to see a startup model go this way as well. I could easily rant on this subject and the idea of bootstrapping versus funding in general, but I’m going to control myself for the moment.
The thing is, for many real-world problems at Google, knowing how to solve so called “trivia” problems actually matters. For example, understanding how to calculate the total number of unique paths, or finding Nth ranked element in an unsorted list as fast as possible is actually relevant in problems that Google has to solve. Source: I interviewed at Google and was rejected, and have several friends who work there.
One more thing – they do treat you as a corporate cog, with isolated responsibility and very modular projects.
I think that, for a company of Google’s size, that’s pretty much inevitable. A lot of perks to be had there, but being a big fish/unique snowflake can’t possibly be one of them.
I’m hoping, based on your/their experience, you can clarify something for me. Is it common for people to have to produce a standard solution to these problems (e.g. “figure out how to sort in n*log(n) time)” or to produce, with a great amount of R&D effort, unprecedented optimizations (e.g. “come up with a sort that beats Quicksort in 80% of starting scenarios”)? I ask because one of those would seem… strange. Forcing people to re-solve problems. The other one would seem to go way deeper than the kind of, “let’s see if you remember this from college” superficial examination than… Read more »
Indeed, even your project contains such task/problem (what is unlikely to happen), it will be solved just once (yes, 1 time).
The rest of the code/work would be about the rest of the tasks/problems. I’d say 99.998% of time would be spent somewhere else. So you’re interviewing people to work on 0.002% and ignoring the rest?
Em… I think we need to interview your manager’s manager replacement.
Great post. However, I don’t think Erick of Google is saying, “now wait just a minute — it’s obviously not broken because it did select me.”
I think he is saying. “You were invited to play this game. You knew the rules and accepted the challenge and now you want to complain about the rules not being fair? Too bad!”
I think it is a valid reaction (even if it isn’t a good process). Complaining about the rules or the score of a fair game after you lose is just being a whiner.
Thanks!
And, I actually find Erick’s position relatable. (Sad, but relatable, particularly since I’ve spent no small amount of time hiring developers) Even if he had time and wanted to, and sought to make it his crusade, I doubt he’s in any position to change Google’s hiring process a whit.
When I recently went through this process, I agree that I felt a lot of “I shouldn’t have to do all of this tangential learning just to get a job! It should be based solely on my skills, experience, and personality!” However, I forced myself to do it and was successful having done it. I made it more palatable to myself by focusing on three things (which may or may not be true). 1. Most of the algorithm type interviews rely on the same, fairly limited question pool. Thus, learning algorithms for interviews is generally applicable across companies, and should… Read more »
> It is, however, an indicator of your willingness to sit down and force yourself to learn something difficult which can be a critical on-the-job skill. That sounds a little bit like “we did it because we had to, so you’ll damn well do it too”. After all we used to force kids to learn Latin to pass their university entrance exams, even they’d forget all their Caesar and Catullus five minutes thereafter. If you’re going to ask trivia, though, why not at least something tangentally relevant to the day to day job? If Sahat is a JS developer, ask… Read more »
First off, thanks for taking the time to comment in detail — this is almost a mini-blog post 🙂 It’ll be hard to address all points in a single comment, but I’m interested in the conversation. Regarding the SAT for screening college applicants, I’m not in love with that process either (and I say this as someone for whom standardized testing proved an enormous advantage when I was younger. In other words, like the job interview, it’s rarely questioned and, like the job interview, I think it needs to be. Second, regarding the notion of creating a barrier to entry… Read more »
A boycott is all well and good if we’re talking about not buying tater tots. But most developers don’t have the luxury of not applying for any company where there is an outside chance of them being hired. I have a feeling that there is a huge disconnect between the US – in particular the tech hubs such as SV and NYC – and the rest of the world when it comes to the hiring. In Europe for example – with a couple exceptions such as London or Berlin – the hiring market for developers is truly dire. Furthermore, not… Read more »
I think your basic point here is that things are not going to change for the better unless the generation of developers that currently has issue with the way that development hiring is done acts as the the agent of change. I think that’s absolutely true – if you’re not willing to stick up for what you believe, people are not going to change their systems to accommodate you no matter how much visibility there is (twitter, blog posts) into the issues with the system. At an individual level, I think there are some issues with that approach, at least… Read more »
Hold on. If I understand correctly, if you just end up hiring “people you know” then not only college kids then a whole lot of people who don’t happen to have great networks are going to be excluded. This all sounds great if you live in one or two tech hubs around the world, but if you happen to live out in the boondocks then it’s another matter altogether. Personally as a remote worker and immigrant I know I’d never be employed in tech again, as the nearest meetup is in the other side of the country and there are… Read more »
No worries, I’m not advocating something that would impoverish all of the world’s developers outside of San Francisco and New York. For what it’s worth, I work entirely remotely (when I’m not traveling) and I’m doing my best not to spend my time in any major hubs, either. When I talk about companies growing without doing the “interview a stranger” thing, I’m including more growth models than most people would probably think of off the top. For instance, “employee refers his neighbor/buddy” comes to mind, but not “employee refers his high performing college lab-mate that lives halfway around the world.”… Read more »
An interesting take on the problem. But if you hire only by word of mouth you just get the most able social navigators. That ain’t automatically a bad thing but it doesn’t always correlate with technical skill either. What if there are way too many great developers that are way too anxious to make this a generally good hiring strategy?
Social ability (“pleasantness to work with factor” if you will) would certainly play a role, but I’d say not an outsized one. Imagine that you’re working for an organization and they say, “your team needs to grow — can you find us someone?” Are you going to hire a smooth talking deadbeat or are you going to hire someone you’ve worked with in the past and can count on to deliver?
I was thinking something more along the lines of “Found some friends at a local tech event, and now I’m referring them. But turns out, not all of them can deliver. Though they sure are nice people.”
If you make “only people you worked with” a rule then it’s different sure, but in the same vein, people would be incentivized to recruit for friendship not for delivery skill. Unless you make a it a point to punish people that vouch for hires that turn out to be bad.
How Google wants to hire is of course google’s business. But there’s a lot of wannabe Googles out there that aren’t quite Google that are imitating what Google does not because it is particularly effective but because they can pretend to be more like Google that way. One of the problems is that in IT companies are trying to recruit people that are essentially extremely high in demand. From that point of view the question if the candidate is suitable for the company is less relevant than the question whether the company is a good match for the candidate. In… Read more »
I completely agree with all of your points here. I’ve spent a lot of time in the last few years trying to hire developers, participating in hiring processes, and even designing them, and it amazes me how developers on the whole don’t appear to realize that they’re holding all of the cards. To your points about first contact not being with the HR machine and about selling the company, I’ve been playing with ideas around automated utilities to find people who write the kind of code that I value, and then offering introductions like “hey, the way you implemented that… Read more »
This post is significantly better written than the one that inspired it, but my sentiment remains the same (copypaste of my response to original post). Life is a video game. Well really a series of minigames. Some of the minigames aren’t as fun as others, but you have to pass them to move on. Right now you’re on the ‘get hired as a developer’ minigame. You beat that minigame by memorizing things like Algorithms and Data Structures. Yes it’s stupid. Yes it’s not something you’ll ever actually do on the job. No it’s not a real indicator of your actual… Read more »
I’m glad if you thought it was well-written. As for offering the same comment to me as to Sahat, I understand your points, but, apart from sharing an opinion that megacorp hiring leaves a lot to be desired, he and I don’t have a ton in common. It’s been years since I was a line-level developer, and, back when I was, I didn’t struggle to get job offers following interviews. I’m not criticizing the hiring process from a place that’s personal to me at all — I’m criticizing it because I think it’s extremely ineffective. Interestingly, the thing that exposed… Read more »
I think any developer that studied computer science, should know how to write bfs even without studying for an interview. I think it’s very simple.
maybe it’s just me.
Seems like a simple construct, but then, after all the CS course work I took, most of them do, once I shake off the rust. Truth be told, I wasn’t actually contemplating the particular algorithm review being asked for. (I don’t consider is overly relevant)
I think it is a simple coding question. I like to ask coding questions in addition to knowledge questions. I noticed that people already memorize the “what is the difference between interface and abstract” questions. that’s why I like to give 1-2 simple coding questions. I had somebody saying that asking about linked list is hard. linked list…go figure. DFS or BFS are not hard. recursions is something I rarely use in my real work, but it’s a simple concept that I think any developer should understand. bottom line – you will be asked coding questions in some places. if… Read more »
Just out of curiosity, are you talking about a phone screen here, or an introductory part of the interview?
As an aside, with managed and interpreted languages dominating the landscape these days, is linked list something that gets a lot of play anymore? (Meaning, if you spent a lot of years in the C/C++ world worrying about memory allocation, the heap, and the stack, it’d be a no-brainer, but I wonder if, for some, it’s now a historical curiosity)
this is on site interview. I start with warming up question. interface vs abstract. value type vs ref type. questions that you might say “who needs to know that?” but I think that in today’s world, in the copy & paste from stackoverflow, I got to start with the basic .net questions. next I move to coding. it could be simple traversing on a binary tree, list or even fizzbuzz. again, nothing crazy. finding out if there’s a cycle in a linked list should be very easy for a senior developer (I would say every developer with more than one… Read more »
Oh, FWIW, I wasn’t intending the question about Linked Lists to be Socratic or suggestive. I was more just musing, as in, “that reminds me of programming 10 years ago” which made me wonder if people just starting in the industry now even know what that is.
With regard to the unit test candidate… I have encountered a lot of people who use the term to mean “after I make changes, I run the application to see if the result is what I expect.” I’m wondering if that was the case…? Dunno, though. Pretty bad however you slice it.
the unit test example is an example of something to talk about with the candidate if I see it on the resume. I won’t ask about it if it’s not on the resume. but if it’s 5 times on the resume, for every job the candidate had, I think it’s a good subject to talk about and see if the candidate understand.
overall I try to get a mix of few things (and this is for a senior):
1)general (easy) .net questions.
2)coding.
3)design.
4)questions about his current or past projects.
Eric, Thank you for your post. I find the problem very interesting and I like the way you think. I would like to expand some of your ideas, but first a few observations. 1) What we are discussing here is a first world problem. We have it really good. Our hourly rate is very high, there are tons of jobs available to us, we can work remotely, work flexible hours, climb the corporate ladder or stay at our current level. We get learning on the job at a click of a mouse, and we have time to read and comment… Read more »
Hey, Alex. Glad you liked the post and the topic. It’s actually pretty easy for me, personally, not to let my positions be colored with a horse in the race, since it’s only my industry (I don’t have a salaried job nor do I want one, so I don’t sit on the candidate side of interviews). The topic of hiring and whether or not it’s a zero sum game is an interesting one. I think it’s almost a tragedy of the commons situation. Getting hired at a given company as a backfill is a clear cut case of a zero… Read more »
Erik, thank you for the reply. Your perspective as an IT management consultant is very interesting. In a way, hiring scene is very similar to a dating scene. On one hand, everyone is waiting for Mr/Mrs Right, but on the other hand no one wants to be Mrs/Mr Right. However, overtime some people do mature eventually. And what they eventually learn is that marriage is not like dating. A successful marriage requires a growth mindset but most people approach dating with fixed mindset. The main limiting factor of companies who can’t fill their developer openings is fixed mindset and the… Read more »
“Rather, what if you simply placed a creative constraint on the organization that it could not grow by hiring strangers or unknown commodities?” would be even more discriminatory than our current process. It prioritizes fitting in over any particular skills, and having free time to network and write external code over professional work.
Regarding the networking/external factor, I’m not talking necessarily about hiring people on the conference circuit. I would envision “known commodities” including, and, in fact, relying mainly on people with whom members of the team had worked in the past and would vouch for. As for discriminatory, I could see that happening, particularly if those being relied upon for leads had come from monocultures and enjoyed them. So, if we accept as axiomatic that the existing process of stranger hires and trivia interviews is also discriminatory (for which claim there is ample evidence, that includes things like natural bias to hire… Read more »
Thanks for this article. Fantastic writing!
Thanks! I’m glad you liked it.
It occurs to me that much of the process may not be about one’s qualifications, but about whether a superior power relationship can be established with you. These corporations look for docile, exploitable employees. This may not be fully conscious and is probably just an evolution of sorts. Just a thought. Great article, BTW.
[…] When you work as a salaried employee, you only have a pipeline for a week or two every few years. Your boss says the wrong kind of magic words at perf review time, you get furious, you call a recruiter and BAM, pipeline. You wind up with 100 prospects and then you go and beg them to give you work. Er, excuse me — you “interview” with them. […]
[…] of people for every gig that you get. And, worse, you’re competing with all of them via the interview process. And job interviews basically just amount to picking people randomly and retroactively convincing […]
[…] You find clients by looking on Monster.com or whatever, and you win them via the dog and pony show of a job interview. […]