Interviews vs. auditions
ryanholiday.net
ryanholiday.net
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.
— 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
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.
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."
Amazon has the preface and first chapter in the "look inside" link above the picture of it https://www.amazon.com/Leadership-Step-Become-Person-Others/..., which develops what I wrote here 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.
Here's a post of mine with a video of Ted and the movie director: http://joshuaspodek.com/another-problem-with-traditional-edu... and links to relevant posts of mine.
wut
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.
the typically interview gotten through a college job fair, and a coding interview, prices human labor as a commodity
sometimes commodities sell for high prices, but in general, you'll do better if you don't compete as a commodity
this is a method for competing along a different axis
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 :)
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.
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.
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".
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.
I worked for a big UK company in the past and you had to pass a 2 or 3 day residential course before you where allowed to interview anyone.
That's one of the main reasons I'm self employed.
Getting a job is mostly doing dumb interviews, tests and crap.
Getting a project is mostly telling the client that I can do it for an amount of money they find okay.
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.
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.
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.
Agreed, do you know why?
They're looking for yes men. (Ok, maybe not the A later in the alphabet - not sure today)
Now if you meet someone "higher up the chain" outside of a formal setting, this might work.
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 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.
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.
Unless you have recruiters (or even engineers) ignoring your answer because it doesn't match exactly to what you were expecting.
And it's not impervious to yes men, you can have a technical savant and a yes man at the same time.
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?
1. https://www.thestreet.com/story/13230576/1/what-are-fang-sto...
I guess as an outside developer, I'm looking at things from the perspective of platforms. Netflix isn't a platform that you build on.
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.
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.
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.
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.
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.
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.
() 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".
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.
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)
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".
http://www.econtalk.org/archives/2018/04/ryan_holiday_on_1.h...
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".
edit: separate HN thread for this https://news.ycombinator.com/item?id=17048391
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 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.
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” ...
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.
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.
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.
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.
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.
If companies would frame it as such, I could choose to avoid these companies. So for the candidate, it would have a tangible benefit.
You need to also sell me on why I would want to work at your company. "Audition" is just insanely redicolous
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.
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.
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).
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?
> 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).
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.
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.
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.
Thanks, you too.
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.
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.
---------
couple book suggestions: 1. http://www.svastralwind.com/uploads/2/7/2/6/2726225/the_2-ho...
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?"
[1] Sharon Drew Morgen's Buying Facilitation
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."
[1] https://buyingfacilitation.com/blog/buying-facilitation-new-...
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.
Please don't do this.