I teach and coach people to get jobs through performance and it works.
Schools teach people to react, take tests, and show how great they are. For a posted opening, you're presenting yourself as a commodity -- a slightly shinier one, you hope. It's based on compliance.
Most analytical, geeky types got a lot of schooling. After decades of it, most people have learned that model without awareness of alternatives.
If you want to avoid challenges in life and just get a job so you can retire 50 years later with nothing remarkable in between, that strategy works.
What Ryan described -- to audition -- is standard in other fields, such as sports, acting, singing, and other active, social, emotional, expressive, performance-based (ASEEP) fields. No actor won an oscar for his or her GPA. No athlete won a championship for being president of a student club.
In ASEEP fields, your performance matters. Sadly, many in business continue to think and act on a compliance-based model. Those who start from a performance-based model find and create opportunities to excel.
I'll always remember how a client told me he met a guy running a business in a field he wanted to move into. He told me he first got to know the guy to make sure he'd like working with him. He then told him his passions and hobbies in that field, then that he had zero professional experience, and then, as he told me, "I led him to hire me."
That's leadership. The guy hired him, saying "I can teach you this field, but I can't teach getting it and you get it." (Incidentally, what he called "getting it" is what I taught him -- you can teach it, just not through a compliance-based model.) So he got paid to learn the new field. Not long after he started new initiatives in that business.
An important thing to remember about ASEEP jobs is that the pay distribution is extremely unequal, with a long tail who may even be paying to participate.
"If you want to avoid challenges in life and just get a job so you can retire 50 years later with nothing remarkable in between, that strategy works."
I find this to be hyperbolic. Compliance and presenting yourself as having more value than the person next you have are not deterministic in "avoiding challenges in life" and not accomplishing anything remarkable. I don't want to run a startup. I want to put my head down and get shit done. Does that mean I don't want challenges in life? No. Does that mean I won't accomplish anything remarkable. No. One should be aware that compliance and process has its place.
One could argue that the special ops schools (like BUDS) drills into you that you are but one of many and to be compliant (even thought BUDS itself is an audition) and that you are a commodity. Please tell me that Navy Seals avoid challenges and accomplish nothing remarkable.
"If you want X, Y works" doesn't imply that "doing Y means you want X," which, unless I misunderstand you, is what you were reacting to.
Speaking of SEALs, I just wrote about them in the draft of my next book, on becoming entrepreneurial, in relation to ASEEP fields, which may be relevant to this thread, since military training trains performance:
"Entrepreneurship is as active, social, emotional, expressive, performance-based as any field. Most books and courses on entrepreneurship teach entrepreneurship appreciation, not practice. They may not hurt, but they don't necessarily develop you to genuine, authentic, free self-expression. Business literature isn't written to help you become more entrepreneurial. If all the business articles about Navy SEALs -- to pick one genre of entrepreneurship literature -- helped people perform as SEALs do, SEALs would read business literature instead of train. They train because it works."
I feel like this is something I've known about but never could quite describe it. Do you have any books or other resources you could link or DM me? I'm interested in learning more.
The movie Most Likely To Succeed http://www.mltsfilm.org is about project-based learning. The books and articles by the guys behind it, Tony Wagner and Ted Dintersmith, are on active education and I found valuable.
"If you want to avoid challenges in life and just get a job so you can retire 50 years later with nothing remarkable in between, that strategy works.
Despite all of the hyperbole in tech, that's what most of us are doing. We work to provide for our family and if we get hit by a bus tomorrow, the company we work for will put out a req for an open job position and life goes on. It doesn't matter whether you are the janitor or the CEO.
Out of the billions of people in the world, a minuscule number make a long term difference.
I'd love to be a commodity tbh. I work just to pay off stuff, and I work hard because I want shinier stuff, but if I had a decent pay at a modest job I'd take it in a heartbeat.
> I can teach you this field, but I can't teach getting it and you get it.
— Man, like the animals, is meant to live together with others like himself. But the meaning of belonging to such a group is found in the comfort of silence and the companionship of solitude.
— Is that why you let me enter and taught me?
— We taught you, young man, because you already knew.
Master Kan and Kwai Chang Caine, Kung Fu, season 1, episode 11, The Praying Mantis Kills
I'm interested in further defining "performance" here. The dictionary gives two distinct definitions. It could mean "capability to carry out or accomplish", which is great, and I'd argue what companies should be hiring for and what candidates should be demonstrating. You want the person who knows their stuff, is competent, and can carry out the job you're hiring for. "Performance" could also mean "presentation to an audience", which is, sadly, what more and more companies seem to expect/reward during the engineering interview process. We're all told you need to be in sales pitch mode to get through interviews for jobs that often have nothing to do with sales or persuasion. Companies on one hand, complain that there are so many incompetent candidates to filter out in the hiring funnel, yet their interview process gives talkers more of an edge over do-ers!
It's like wanting to hire people to sit down and compose music, but everything in your hiring process is selecting for showmanship and stage performing instead.
That's the one big problem with this piece of advice.
This style of interview (ahem audition) will NOT work when applying for your 1st, 2nd or even 3rd jobs. McDonalds and even Facebook need a lot of worker bees.
They need very few Performers (CEO, CFO, Chief Strategist, Head of Content and Marketing, etc. etc.)
It works only when you are no longer a commodity and have a specialization.
Its great advice that I hope to be able to use someday. Until then I will keep my head down in the trenches..and take some notes :)
This is also a really good insight. To be Andy Reid you have to do both things: take copious notes AND audition.
It definitely seems important to understand the positive psychology aspects of this and set yourself up for success, but perhaps it's also true that the reason many people don't come into interviews with a 'pitch' is that... there is no such pitch. A lot of people _can't_ take the business somewhere new and interesting, or provide indispensable value. And they subconsciously know this. It's not that they can't _ever_ do these things, it's just that they need to acquire more expertise and build a vision.
Taking control audition style may work if you're a consultant trying to convince a client to hire them, but you had better know their business backwards and forwards, and unless you're in a very well defined space (like their football coaching example), you probably don't.
However, if you attempt this at a standard FAANG job interview, it is emphatically not going to work. There's a set of questions you need to work through and attempting to go off script is not going to be appreciated. Pretty much the only exception is leadership roles, particularly when the brief is "we need somebody who can turn around/10x our floundering business".
It also depends heavily on what kind of role you're applying for. If you're applying as a product manager, then sure, present your big audacious vision on how you're going to transform XYZ widget. Even if they don't actually do it, it's a good way to showcase your capabilities.
But if you're applying as a software engineer? What exactly are you going to present then? Nobody wants to work with a guy who's never seen the code base, but wants to rewrite the whole thing in Rust.
You don't necessarily need to present a vision for the specific things you can do for the company, but you can take the initiative and present why your specific set of skills will be well suited for the company in question.
I do agree that you need to be careful with this - many companies will want to put you through "their process", and attempting to take control of the conversation when it's not welcome will tank your chances at a position, but I do think it's worthwhile to try.
> However, if you attempt this at a standard FAANG job interview, it is emphatically not going to work.
It's kind of "offense is the best defense" method.
I haven't done many interviews, but I found a good strategy is to have some questions about the technology the company is using. Then you can both show interest and turn the interview on the head, instead of them asking you technical questions (for which you might not know the answer), you ask technical questions that show you have done some basic research and have basic understanding.
I have used a similar strategy on some oral exams at the university.
Many people (especially specialists) are not natural examiners, and are delighted to talk about their field with someone who has some understanding of it, regardless of the fact that they should conduct an interview or exam.
But then again, it takes a certain type of character to do it (since I am a curious person, it comes somewhat naturally). You can't really fake it, you have to put in some effort of learning about the technology in question in advance.
I've had this happen to me as an interviewer. It seems good at first, but when I eventually bring the interview back into my 'can you design a simple data format, and then use the format you just designed' problem, I usually find the answer is no. I try not to let this bias me when I realize the candidate had led me astray, but it's hard when every candidate that leads me astray can't do my problem.
Yeah, the one thing I kept thinking about when I was reading Ryan's essay was, "yeah this won't work in a real meat grinder, audacity isn't the right choice for every situation." Of course, knowing Ryan, the answer to that situation is going to be, "don't put yourself through a meat grinder."
Totally agree, as a veteran Software Dev, been consulting for 2 years now.
Most customers want some degree of assurance that you can solve their problem and that you also have a track record of proven success (no FizzBuzz BS).
The downside is that most customers are also non-technical, so it becomes challenging (for me at least) to explain some concepts which impact the ongoing project. This is where I think building trust within a business relationship is important, and why you should avoid any customers who distrust you and your credentials. Because the bottom line is : if you can't explain all the finer details to someone, but they trust your judgement and ability, everything else becomes much easier.
As a consultant you are much more in control of your working relationships than as an employee. A consultant has many clients; an employee only has one employer. That alone provides sufficient leverage to dictate the terms of the role, which is a major advantage of self-employment.
I think it's basically the same deal PG is always talking about: Nobody is willing to pay triple for an employee which is actually three times as productive, but a consultant can honestly charge three to five times as much in order to provide equivalent return on investment.
I also find that in general, people who won't listen to an employee are excited about collaborating with a consultant - even when you're the same person making the same contributions.
I find it pretty frustrating - I have long-term views and I want to make a significant, long term impact on the companies I work for, and being a consultant means it's all about quarterly results. That being said, I'll take sober consideration from day one over "time over grade equals seriousness" any day.
True early on in your career or you’re interviewing for large company, you have to go through the crap. I avoid large companies like the plague. At some point in your career, your resume can start speaking for you and your salary requirements are going to automatically start filtering out positions where they are going to ask “what’s the difference between a class and an object?” and start asking questions about previous projects, how you architected them, etc.
One company I worked for, I came in expecting the standard questions but the first question I was asked was what was my 90 day plan to create a modern development department - I didn’t know he was looking for a team lead. Another, they were using AWS but none of the developers knew how to take advantage of AWS services fully.
It's worthwhile to distinguish between decision-makers and information-gatherers. FAANG interviewers have notoriously little decision-making power, though if you're given a time slot with your potential hiring manager, this approach might be worth a shot.
A good interviewer wants to stay on their script not because they're a disempowered automaton, but so that they can contextualize your performance relative to others they've given the same questions.
Your job on an interview loop is to collect the best signal you can about the candidate's strengths in the assigned topic. You have broad latitude to use your professional judgement in going about that, but what makes your assessment persuasive in a debrief is calibration. An "original" interview may be a useful and necessary cost paid by the employer to train and calibrate a new interviewer, but opinions based on that interview have to be discounted appropriately in actually assessing the candidate.
On the other hand, if you're a seasoned interviewer with a long-term favorite question, and report that the candidate's performance is an outlier in either direction, your voice alone could completely change the debrief room's opinion.
Yes. Not all engineers take interviewing seriously, and even fewer actually want to be doing it in the moment. It can be seen as a too-frequent interruption that drags down productivity. This creates pressure to put interviewers in rotation who are not ready (so that more senior people can do their actual jobs) and can lead to a bad time when an otherwise-good interviewer betrays his annoyance at having you appear on his calendar. A disturbing proportion of your success as a candidate depends on luck of the draw.
There are millions of companies out there that are not part of the big big 5. I don’t need to know their business backwards and forward and I probably won’t know enough about their internal pain points until I get there. But I’ve noticed over the years, that most companies that are interested in hiring me, have the same sort of issues when it comes to trying to deliver their product.
Big 5 was in reference to the technology companies FAANG - Facebook, Apple, Amazon, Netflix, Google. I have no idea why people include Netflix and not Microsoft.
> I have no idea why people include Netflix and not Microsoft.
Netflix pays outlandishly well - which is why engineers include it on their list of big companies.
Leaving that aside Netflix is a giant: $150B market cap as of this writing. The term "FANG" was created by TV stock pundit Jim Cramer to describe tech stocks that have done particularly well over the last 7-8 years[1]. Maybe he felt MSFT's stock performance wasn't that strong or that he couldn't make a catchy acronym if he included it?
However, if you attempt this at a standard FAANG job interview, it is emphatically not going to work.
Indeed, but someone willing and able to do this well probably isn't applying to work at Facebook today, they're applying to be co-founder or employee #1 of a business that might be the next Facebook.
No, they're looking for concrete evidence of having and being able to apply a well-defined set of skills.
One of the things you learn pretty fast as an interviewer is that charisma and attempts to pitch yourself tend to correlate poorly with aptitude, and an interview that focuses solely on predefined technical questions is by design impervious to yes men.
I usually just blaze through the technical questions, FizzBuzz takes 1-2 minutes, 2-SUM maybe 5 minutes. Rarely do they have more than 15 minutes of technical questions unless you have problems with how fast you can write on a board. I've also asked to skip an easy question so that I would have more time for the audition phase.
Or maybe they hire thousands each year and want to ensure some consistency in the candidate selection criteria. This could result in hiring more yes-men, but the _intention_ may be different.
I would die a thousand deaths working in a company like that. How can you possibly build your resume if everything on starts off with, "I worked on a team that did X?" at a small company you can say "I did X, Y, Z".
Believe it or not, engineering is highly collaborative. If your dream is to work by yourself so that nobody else can take any credit, you might be better off in a different field.
There is a wide spectrum between “working by yourself” and working for a large beuracratic company where you’re just a number. I can take credit for leading a lot of initiatives at the companies I’ve worked for without being in management. It’s the difference betweeen working for small companies - or larger companies with a small development shop - and massive companies.
I would never know as much as I know about networking, infrastructure, devops, architecture, security, etc. in addition to development if I spent all of my life in a large company.
I only skimmed the article, but whenever I read such material I feel these techniques are suited for jobs banking on charisma instead of knowledge and skill based ones.
I am a software engineer. I haven't held too many jobs, and have attended very few interviews. As an interviewee, I always gauged the enthusiasm of the interviewer before 'unleashing my talent'. I have had my share of insipid interviews where the focus was on API specifics instead of ideas and larger pictures. I politely excused myself out of the building mid interview when I realized they needed just a code monkey, albeit with experience. Seizing control would have been a total waste.
I have also conducted my share of interviews. The biggest turn off for me is when candidates try too hard to impress, either by listing out insignificant contributions to FOSS they have made, especially when not asked, or wearing their supposed geekiness on their sleeves. The worst are the self declared nerds and geeks, who speak, look and act in a way that covers all the stereotypes floating on the web. Its worse when, out of turn, they bring up a cool thing they 'hacked'.
Generally, going beyond job interviews, I think the need for being alpha is ridiculously amusing. I am no psychologist, but it smacks of overcompensation and utter lack of self confidence. I avoid such people in life.
I think if you give the article a second chance, you'll see that it does not advocate for the self-promotional behavior you dislike.
The article doesn't tell us to "listing out insignificant contributions to FOSS they have made, especially when not asked." Rather the article tells us to research about how we can add value to our prospective employers beforehand.
Stated in that way, the article's message is quite "boring", but also true.
The challenge here is that it's incredibly hard to know how to add value, from the outside. Especially for not-very-senior positions, adopting this tactic can backfire big time. I interviewed a guy who attempted to tell us how he'd design our systems, and only showed a severe lack of understanding of the domain () (which is really not surprising, it takes most people at least a few months to start to grasp it).
() It also smacked of arrogance - it's as if he thought he knew better than people working on it "how it should really be done".
I don't think so. If it's not customer facing and not team focused (e.g, a data entry clerk), then I don't think it would affect ones performance, and thus, not be "valuable" to the job.
This is basically what a good sales pitch is. Call it audition if you want. A lot of developer jobs are not looking for this kind of drive and skill set though. In fact, I have been told by a former startup employer to not spend so many brain cycles on how to improve the business and just focus on getting the code to work.
Many managers feel threatened by such people it seems. So not a good idea if looking for a job. Good template if pitching to investors.
I doubt this would work in any more structured interview process for a regular job at a larger company (with the likely expection of VP+ level jobs), but it could be very effective for interviewing at startups, especially when they're small enough for you to be interviewed by one of their founders.
A good way to do this is probably not to take charge immediately upon concluding the small talk, but to simply ask whether the interviewer would be interested to set aside some time to see some ideas you had prepared for their business (shows binder)
As an engineer I think this is best interpreted as a recommendation to ask a lot of questions when you are given the chance. Take it as an opportunity to demonstrate a greater understanding and care for the opportunity than just the scope of your role. Ask about culture, about challenges, competitive positioning in the marketplace etc.. I try to ask questions that demonstrate a lot of compassion for team dynamics and business objectives. It’s never led me astray.
As someone who has interviewed a lot of candidates, I would agree the Q&A is the best place to show this.
Most of the stock questions are filters for people who can't do the job - was this person's answer reasonable?
Where I've seen candidates shine is when they ask really good questions. Question that indicate they've put some thought into the role. When all I get is "How do you like working here?" or "What's the company culture?" it shows the person is either uninterested in the role or incapable of delivering something beyond "here's what you asked for boss".
The part about interviews vs. auditions is around the 49 minute mark. The entire podcast was fascinating. The topic of the podcast is his recent book about Gawker and Peter Thiel and a broader discussion about "conspiracies".
It was a really good podcast. One of my takeaways is that Holiday does a good job of not "taking sides" even though it is a seductive, socially compelling thing to do. I think that EconTalk and the book deserve their own HN thread.
I’ve noticed an increasing number of candidates using this kind of “take control of the interview” approach. It’s reached the point of having candidates talking over top of me during phone screens trying to wrest control of the conversation away.
I’ve never hired someone who does this. I’m not interested in how you’re going to rework my team or rewrite our software.
Interestingly, when interviewing potential peers or CEOs, I’m kind of expecting them to do this.
I think that's because it's very hard to get this strategy right. In some interviews, it may not be possible due to the way the interview process is set up, and in particular the magnitude of information asymmetry.
I think getting it right hinges on two things:
1) Does the interviewer actually have a concrete objective that you are qualified to help them achieve -- even if they themselves aren't necessarily aware of it or have it top of mind.
2) Can you identify that objective either ahead of time or in the interview process, and in a polite yet direct manner convince them that you can help them achieve it.
If neither of these are true, it is bound to come off poorly. Whiteboard/puzzle based 'general intelligence assessment' style interviews don't lend themselves to this. Wishy washy job descriptions don't lend themselves to this. Hiring processes influenced by politics rather than need (i.e. where a manager is disincentivised to hire someone better than they are) don't lend themselves to this.
If a majority of candidates who try this strategy with you aren't able to pull it off well, perhaps step back and take a look at your recruitment/interview processes and see if you could actually help the good ones impress you.
I'm not saying I've done this right in the past, quite the contrary. For me the ideal interview is me simply describing a problem my team has, and the interviewee educating me on how to solve it and why they are the right person to do so (though usually the fact they are able to do the former implies the latter). I've tried to format interviews more like this over time and I have personally found better results as a consequence.
Exactly, if we’re in the “how would you solve this problem” or “tell me a time when” phase, knock yourself out and be assertive.
When I’m giving my 10 second description of my phone screen process works and I get interrupted to be told “this phone screen will be done differently” ...
If you're applying for jobs where you'll be sitting a cubicle and doing the work assigned to you (no matter how much experience, creativity, or leadership that may take) trying to lead the interview by going over all the things you'll do is idiotic. Like another commenter said, if you do this in a SWE II-level interview at a Big 4/5, it's probably not going to end the way you want it to.
The article uses football coaches as an example for a reason. This sort of interview tactic works when a major component of your job is leadership and inspiration. If you're judged in whole or part on the success of other people, this probably works. If you're judged based on how many JIRA tickets you close you should probably not be trying to run your interview.
You bringing up a very important distinction here. When hiring someone to lead it is extremely important for that person to naturally fall into that role. When hiring someone to do the work that needs to be done, you want them to be able to understand what they are supposed to do, offer alternatives if they think there's something wrong, but ultimately do what needs to be done. Taking control in that second situation isn't necessarily a good thing.
I've been out of college for ten years this month and I can still remember those few students who could not get it through their head that class was not a one-on-one conversation between them and the instructor.
My favourite professor: “I’m glad you found my paper on Chaos Theory interesting but my Numerical Methods class is not the place to discuss it. Please stop interrupting me.”
Well... this article is merely saying (with many many words) that it’s way better to show up to interviews and important meetings with utmost preparation than unprepared.
Generally people prepare well on the technical details (algorithms, programming etc..) and solve the problems that are put forward by the interviewer.
Here, you prepare well on the real problems faced by the company (say scaling beyond a million user) and then outline the solutions that you have for that.
While I am not sure this would work in every situation, I appreciate the main thrust of the article: treat the interview as audition, come in prepared to talk about how hiring you will improve the business, differentiate yourself from the other interviewees.
I don't know if the need to have the entire program written out is most important.
The best candidates I've hired show aptitude to ask the right questions and, in return, ask probing questions about what led to our decisions, have we thought of [x], this is how [x] might work, what about [y] competitor or space within our industry, etc...
The most memorable interviews I've come out of / been a part of are the ones in which the candidate leaves me thinking or scratching my head about why we're doing what we're doing and whether they'd be a great fit to help us achieve our goals.
This is all from a product management perspective so might not be the same across the board.
as an engine mechanic, is this sort of game play normal in office jobs?
When I've been taken on as an apprentice, its an interview to see my competency...where i stand i guess and what i need to learn. Questions like 'whats the hardest thing' and 'how do you handle grumpy people' are pretty normal.
Being hired on full-time, and having to hire another mechanic myself, The questions are pretty cut and dry. Can you stick to a schedule, describe a 4 cycle engine, what a cam profile, give me a reference.
Once weve hired someone new, we generally know if shes going to make it or not. we all chip in to help if theyre struggling, but we dont play weird games.
For some reason people are deathly afraid of hiring the wrong person. So afraid that they'd rather pass on 100 good candidates to avoid hiring one person who doesn't fit.
It's particularly bad for programming jobs where they expect candidates to go through up to a half dozen separate interviews. The whole process is just completely broken.
IMO, the reason this is rare and stands out is because these types of people tend to already be running their own show, and don’t need to interview or audition.
That's the analogy I use when people complain that whiteboarding doesn't mimic/approximate they day-to-day job. If you're the casting director for a play you're going to have auditions, you're not going to cast people based (solely) on their resume and having a conversation about their acting background. But auditions are very different than an actual performance: there's no audience or costumes or props, the lighting is completely different than what it will be, you're reading from a script, you may be the only person on stage while the other roles are read offstage, you're being accompanied by a piano instead of a full pit orchestra, you're mostly standing in one place instead of moving to established blocking, and so forth. The point of an audition isn't to mirror performance night, it's to get an idea if you're capable of acting/singing/dancing/whatever. Likewise the purpose of whiteboarding isn't to mirror the day-to-day work, it's to get an idea of your problem solving capabilities (some might argue it's also to see if you actually know how to code, but personally I feel that's what the technical phonescreen is for).
I agree with the sentiment but almost no other profession does this. Could you imagine a Surgeon being forced to "Audition" for his job? "Here perform heart surgery on this guy for us, if he lives you get the job."
> I agree with the sentiment but almost no other profession does this
Almost no other creative profession doesn't do this. Our profession is much more similar to actors and musicians than it is to doctors or lawyers. You also have to factor in practicality and gatekeeping (for lack of a better word) - it's not very practical for a doctor to perform mock surgery for an interview, whereas it's very feasible asking someone to write some code on a whiteboard; and if you're a surgeon you have things that indicate you know how to perform surgery at a much higher level of confidence than knowing someone can problem solve (well) just because they list "developer" on their resume, surgeons have to go to many years or medical school, they have to spend time in residency, they have to pass their boards, if software development had the equivalent of all this (and I'm not necessarily saying it should) then yes there'd be much less need for "auditions" in our field.
>Almost no other creative profession doesn't do this.
This is only true for a very small subset of creative professions.
Actors and musicians perform in front of an audience. That's their job--they are performance artists. Asking them to perform in front of you is very similar to what they'll actually be doing day to day. A much better analogue is a creative profession that doesn't involve performance art.
Interviewing an illustrator, a graphic designer, a writer, or an architect generally involves looking through a past portfolio of work with the interviewee. In general they aren't expected to perform on the spot in front of an audience because that's not part of their job.
> Actors and musicians perform in front of an audience
Some actors/musicians. Movie actors never perform in front of an audience, TV actors usually don't perform in front of an audience, studio musicians rarely perform in front of an audience - these professions have auditions (unless you're an A-list actor, but I'm sure most software companies would hire John Carmack without an "audition" so we likewise do the equivalent). But more importantly I think you missed my point, in that the audition for these professions are under very different conditions than what you'll actually be doing "on the job" (one of the bigger complaints with whiteboarding seems to be that it doesn't closely mirror the actual work).
> Interviewing an illustrator, a graphic designer, a writer, or an architect generally involves looking through a past portfolio of work with the interviewee
That'd be fine if the point of the technical interview was to determine they know how to write code, but it's not IMO. As I mentioned above it's to determine they're capable of problem solving, because that is the important part of what we do (you should also obviously make sure a candidate knows how to code before you hire them, but that's the point of the phone screen).
>Movie actors never perform in front of an audience, TV actors usually don't perform in front of an audience, studio musicians rarely perform in front of an audience - these professions have auditions
This is only true for an extremely limited definition of audience.
Movie actors most certainly perform in front of an audience. There are hundreds of people on the set. Even a small indie film has a few dozen people on set. It's the same for TV actors.
Studio musicians also have plenty of people watching over their shoulders while they perform, and they're expected to be able to do so on the spot without preparation.
>As I mentioned above it's to determine they're capable of problem solving, because that is the important part of what we do
That's the important part of nearly everyone's job. Architects, graphic designers, engineers, sales people, mechanics, plumbers.
There's nothing special about programming in this regard. We've just convinced ourselves that our industry is so special that of course we need weird hazing rituals. Everyone else seems to get along fine without treating people from new college grads to programmers with 20 years of experience like this is their first job.
Can you solve this artificial problem that I already know the answer to right now in this time boxed, needlessly adversarial situation situation while I watch over your shoulder and critique you?
It's a bit odd you responded to various parts of my comment but not the "But more importantly I think you missed my point..." portion (i.e. kind of silly for us to debate this audience straw man)
> That's the important part of nearly everyone's job. Architects, graphic designers, engineers, sales people, mechanics, plumbers.
Communication, like problem solving, is likewise an important part of nearly everyone's job, but the importance of good communication skills (as valuable as they are) are much less important to being a good software engineer or good plumber than they are to being a good reporter or trial lawyer or public relations professional.
I'm guessing, like most developers, this is your first/only profession - but it's not mine (I switched careers in my early 30s), and I can assure you not every job requires the level of problem solving we deal with on a regular basis (and no, that doesn't make us "so special", not all jobs are identical, some have more or less value in different areas, but one is not more special than another because of the importance of problem solving or communication or empathy or creativity or anything else).
>It's a bit odd you responded to various parts of my comment but not the "But more importantly I think you missed my point..." portion (i.e. kind of silly for us to debate this audience straw man)
Your argument was that almost all creative professions have auditions similar to whiteboard interviews. I pointed out that that's not true because it's only true for performance artists. You then took the discussion off topic by arguing that movie stars aren't performing in front of audiences.
Actors are expected to perform in front of an audience, programmers aren't. The ability to perform in front of an audience is difficult and rare, and is completely orthogonal to the skills required to work day to day as a programmer. Whiteboard interviews are just too far removed from anything resembling actual programming to be a work sample test. At best you're administering an ad hoc IQ test, but then you're adding an adversarial public performance aspect for no good reason. That adversarial public performance aspect is the biggest single difference between whiteboard interviews and real programming work--it's a much bigger difference than the difference between acting auditions and acting day to day.
>I'm guessing, like most developers, this is your first/only profession
I also switched careers after years in another field.
> not every job requires the level of problem solving we deal with on a regular basis
This is true. But having worked on the embedded systems side of hardware, there are many professions that do require at least the level of problem solving that programming does.
EEs (the majority of whom don't have any kind of certification unless they're working in power systems), computer engineers, and even embedded developers don't routinely go through the kinds of whiteboard problem solving tests that you're talking about. Engineers working on real time, safety critical systems are hired every day without a Google style 6 person interview interview.
The key differences are that these companies aren't trying to cargo cult the Google interview process, they don't have engineers a year or two out of college conducting the interviews, and they aren't paralyzed by the fear of unqualified candidates slipping through.
I spend a lot of time on (capital E) Engineering forums. You don't see people on those forums complaining about the industry standard interview. You don't see flame wars started every time someone even mentions interviews. I've never heard of an EE with 20 years experience being asked to solve pet problems by a 22 year old new grad. And I've never heard of an EE spending months practicing for an interview.
Clearly our interview process is broken. Perhaps it's time to look at similar industries and spend some time trying to figure out if we are really so different instead of insisting that programming is so uniquely challenging that it requires such a controversial interview process.
> Your argument was that almost all creative professions have auditions similar to whiteboard interviews
No it wasn't. Feel free to re-read my original comment[1]. My point was not that they have auditions, it's that the auditions don't closely mirror what they'll actually be doing if they get the gig (which is one of, if not the, most common complaint about whiteboarding).
However, it seems your primary concern is that the whiteboarding is done in front of an "audience" - I can sympathize with that but there's going to be an audience (by your definition of the word) regardless of the structure of the interview, i.e. your "looking through a past portfolio of work" example[2] is still discussing your work to an audience (as opposed to creating new work on the spot) and is still very dissimilar to the actual day-to-day work (N.B. I've never actually been an "illustrator, a graphic designer, a writer, or an architect" but I'm pretty sure their days aren't spent just sitting around discussing their portfolios).
> Perhaps it's time to look at similar industries and spend some time trying to figure out if we are really so different instead of insisting that programming is so uniquely challenging that it requires such a controversial interview process
Perhaps I'm mistaken (I'm by no means an expert on the history of our profession) but my understanding is whiteboarding interviews are a relatively new phenomenon (i.e. last decade or two) and presumably programming interviews prior to that were more similar to many other disciplines. It seems unlikely (though certainly possible) that our entire industry would move away from that if it didn't have major shortcomings.
If you feel you have found a better way to hire developers than what most of the industry does I would encourage you not just to use it for the interviews you conduct but also to share your thoughts and findings with others via a blog or maybe even a book. Either would certainly have more potential impact than debating the issue with me in a buried thread of a day old HN discussion. It's been an interesting discussion and you've motivated me to research the history of software dev interviews, best of luck to you in your career and interviews.
>No it wasn't. Feel free to re-read my original comment[1]
Sorry I wasn't very clear. When I said "similar to whiteboard interviews" I meant similar in the sense they are both different from the day to day job.
>is still discussing your work to an audience
This is true. But discussing is very different from performing. In my experience, standing at a white board while someone who already knows the answers to the questions they are asking tends to have a large impact on most people's ability to perform.
I've seen this in numerous interviews. The number of false negatives in this type of interview process are extremely high.
>and is still very dissimilar to the actual day-to-day work (N.B. I've never actually been an "illustrator, a graphic designer, a writer, or an architect" but I'm pretty sure their days aren't spent just sitting around discussing their portfolios).
But the key difference is that the work they are discussing is a product of their normal work environment.
Despite what we like to tell ourselves about wanting to see how people think, the vast majority of these types of interviews are going to push forward the people who can solve the problems they are presented with. So what Google style interviews really select for are people who happened to have recently studied the solutions to the types of problems presented during the interview and who excel at public performance. The end result is that we encourage job hunters to game the system by studying a subset of problems that don't represent the real day to day challenges of working as a programmer.
> It seems unlikely (though certainly possible) that our entire industry would move away from that if it didn't have major shortcomings.
The majority of programming jobs are at non-tech companies, non-tech companies don't tend to have Google style whiteboard interviews.
A large subset of the industry has moved to these types of interviews, but that's not an uncommon occurrence. It's happened several times in the past. Tech hiring is very fadish. Back when MS was the big company everyone wanted to work for, they used to ask insanely difficult brain teaser questions. By the early 2000s every tech company was asking these stupid riddles: You are a chef. If you had an infinite supply of water and a 5 quart and 3 quart pail, how would you measure exactly 4 quarts?; How many cars/gas stations/piano tuners/etc. are there in the USA? etc...
The fad was strengthened by Google because they used the same kinds of questions. This went on for a decade or so until Google decided brain teasers didn't correlate well with job performance. Word spread and companies stopped doing it (a few are behind the times and are still stuck on the last fad cycle).
Now the fad is repeating itself, but the companies are trying to emulate Google's newer brainteaser free 6 part whiteboard interview process.
The thing is, Google can afford an insane amount of false positives. Most companies can't, yet they still insist on cargo culting the Google interview without really understanding why.
>If you feel you have found a better way to hire developers than what most of the industry does
I do have what I consider a better way, but I certainly didn't invent it. I interview developers the way people interview architects, illustrators, and engineers. I look at past experience and portfolios, and I judge whether they can competently walk me through the projects in their portfolio.
If the applicant doesn't have much experience, or if their portfolio is too small (all of their work is covered by NDAs or something like that) I include a take home work sample test.
I've also had good experience pairing the applicant with a developer to work on a sample problem that neither one has seen (and isn't something we'll benefit from).
>you've motivated me to research the history of software dev interviews,
Our industry would be much better off if more people were willing to look at why we do things the way we do them.
>best of luck to you in your career and interviews.
I've done interviews where I was asked to come prepared to present some code I'd written (either a homework problem or some open-source work). I found it a nice approach: they got to see how I'd explain code to a colleague and what aspects I focused on. I could take time to tailor my presentation to the company if there were things I thought they'd find more important.
The downsides are that it's harder on people who don't like to put on a performance and it's harder to come up with objective-seeming measures between candidates.
Yes I would absolutely avoid a company that called it an audition. I am not an actor and should not have to perform for a company... It's basically saying "we want you to jump through even more hoops than you already did"
You need to also sell me on why I would want to work at your company. "Audition" is just insanely redicolous
After a thick paragraph about sports history I gave up, which is 100% my fault. The moment an abstracted "sports metaphor" becomes an actual detailed account of sports figures (players, coaches, teams, etc) my interest in the topic enters a death spiral.
Seems like the key to making this work is having done the legwork beforehand to know you're making suggestions that won't wind up being tone deaf.
That legwork probably looks like having several conversations beforehand with people on the inside beforehand, so you actually have a basis for thinking you know what sort of problems are relevant for the decision makers.
On average, that's probably something college students looking for their first jobs aren't well positioned to do (especially if they're looking for their first job through formal recruiting channels at huge corporations).
And on average, for people with a few years of professional experience, its a matter of realizing that hanging out at conferences, happy hours, and other informal situations where you're around other similar professionals is low hanging fruit for these sorts of conversations, and recognizing that these situations present these sorts of legwork opportunities is a big advantage.
----------
I said students don't typically do that well, but I don't think that has to be a rule, lots of advice talks about trying to do 'informational interviews'. I think this is sort of what they're getting at, what you want to get out of an informational interview, is to sort of be able to frame the problems a future interviewer might have, and be able to do an interview like this.
There's probably a lot of trial and error that goes into getting this right. And also, probably a lot of investment in having conversations where the payoff doesn't seem very obvious.
gives a method for setting up informational interviews, good read overall
2. I've suggested this books a couple times, I think its actually really deep when contemplated on
Spin Selling by Neil Rackham
-------------
Let me do a quick breakdown on why I think Spin Selling is really deep.
Its basically a method for asking questions that elicit deeper responses
its breaks down all sales questions into 4 categories:
SPIN Selling proposes there are four types of questions, thus SPIN stands for :
1) Situation Questions deal with the facts about the buyers existing situation.
2) Problem Questions ask about the buyer's pain and focus the buyer on this pain while clarifying the problem, before asking implication questions. . These give Implied Needs.
3) Implication Questions discuss the effects of the problem, before talking about solutions, and develop the seriousness of the problem to increase the buyer's motivation to change.
4) Need-Payoff Questions get the buyer to tell you about their Explicit Needs and the benefits your solutions offers, rather than forcing you to explain the benefits to the buyer. Getting the buyer to state the benefits has greater impact while sounding a lot less pushy. What these questions do is probe for explicit needs.
The quick takeaway, is that sometimes situation and problem questions are sometimes needed to make sure you know what everyone is talking about, but those questions are boring for the person being asked them. The basically amount to giving information to someone who clearing doesn't know as much as they do.
What you really want to do, are minimize those question (probably by googling extensively before hand), and ask implications questions and need payoff questions, those are the questions that will lead the listener to consider things they hadn't previously considered.
When you start asking those questions, you'll start having conversations where you learn things other people don't know.
This is presented in the context of making sales calls, but its actually good advice for a huge range of conversations where what you're trying to determine "what does the other person want?" "why do they want it?"
Its message, "buyers don't know how to buy", helps make sense of some of the controversy in this thread. If you're hiring 100 software engineers, god help you if you don't know how to hire. But if you're hiring your first CFO, say, it's more likely that you "don't know how to hire", and that a commanding (yet polite) interviewee will be helpful.
Sharon Drew Morgen emphasizes the process of questioning and the "systemic" nature of the uptake. Again, more relevant for a "big hire" than a dozens per year hire. If you're the first CFO ever hired, especially, it makes sense to help the hiring team think through how the company will adjust to having that new role and whether they've done the necessary groundwork for those adjustments.
[2] The Challenger Sale
Similar, but with an emphasis on the content. Do your research in advance to figure out how your type of widgets solves specific problems that most of your customers have.
The hiring analogue again fits best for "big hires". E.g. "since this is your first CFO, a big part of the job will be to straighten out the ad hoc financial routines that have grown up so far. I have the necessary great financial/accounting skills, but I'm also a great listener/researcher with the people skills to bring people into more constraining routines."
I just went through a phone interview with a candidate today who did this. He had pre-shared a 36-page presentation of his career/goals/etc.
I spent some time studying this presentation ahead of the interview and thought he was thoughtful and that this indicated an attention to clear communication.
Then we started the interview. I told him I had read his presentation in detail and commended him on the homework. He then super-politely asked if he could spend ten minutes to quickly go through it to add some more details, via a shared screen service. "Sure, why not?"
40 minutes later I finally cut him off, two thirds into the presentation. I came away from this thinking he was trying to control the communication, perhaps stearing me away from probing at his weaknesses rather than thinking he was a proactive comminicator.
Schools teach people to react, take tests, and show how great they are. For a posted opening, you're presenting yourself as a commodity -- a slightly shinier one, you hope. It's based on compliance.
Most analytical, geeky types got a lot of schooling. After decades of it, most people have learned that model without awareness of alternatives.
If you want to avoid challenges in life and just get a job so you can retire 50 years later with nothing remarkable in between, that strategy works.
What Ryan described -- to audition -- is standard in other fields, such as sports, acting, singing, and other active, social, emotional, expressive, performance-based (ASEEP) fields. No actor won an oscar for his or her GPA. No athlete won a championship for being president of a student club.
In ASEEP fields, your performance matters. Sadly, many in business continue to think and act on a compliance-based model. Those who start from a performance-based model find and create opportunities to excel.
I'll always remember how a client told me he met a guy running a business in a field he wanted to move into. He told me he first got to know the guy to make sure he'd like working with him. He then told him his passions and hobbies in that field, then that he had zero professional experience, and then, as he told me, "I led him to hire me."
That's leadership. The guy hired him, saying "I can teach you this field, but I can't teach getting it and you get it." (Incidentally, what he called "getting it" is what I taught him -- you can teach it, just not through a compliance-based model.) So he got paid to learn the new field. Not long after he started new initiatives in that business.