Stop eliminating good candidates by asking them the wrong questions
hbr.org
hbr.org
Find something, copy some strings, munge, paste some strings.
ADTs, IDLs, validation goo, logging, tests, etc can help. But also can get in the way.
Sometimes, if we're really lucky, we get to mix in some indexes, caching, parsing, undo/redo, and release notes.
I don't mind being asked a leetcode style question or two in an interview. Even if somebody struggles with solving an unfamiliar problem off the cuff, you can see if they they take some logical problem solving approaches.
But it's frustrating that no practical web-development questions are ever asked for those kinds of jobs.
For instance, security is really important to the survival of any company. An insecure system that has a data leak could literally destroy a company overnight. Having a secure system is far more important than knowing a more efficient algorithm for sorting some data or whatever.
But I've never been asked 1 practical question about security in a technical job interview.
It's so painfully stupid it hurts.
Source?
I'm sure we "wish" that were true, but data leaks haven't even destroyed companies whose entire existence is predicated on storing data such as Equifax.
1. https://techmonitor.ai/technology/cybersecurity/capital-one-...
https://securityboulevard.com/2022/07/a-retrospective-on-the...
Other companies can be much more screwed. Suppose your customer list gets leaked, including their contact info and how much they're paying you for which services. First of all they're pissed at you. The next thing that happens is a competitor downloads the data and sends each of your customers a custom email offering their services for 10% less than they're paying you. While they're pissed at you.
But also, suppose you're Equifax and the people who breach your systems, instead of leaking the data, just delete it. Including the backups. Now you're out of business, because you have nothing to sell.
I hear this a lot, from the likes of Google on down, but does any interviewer ever take away anything positive from "almost" solving an interview question? In my experience, most interviews are pass/fail and getting close isn't a pass.
Myself and another team member worked on the questions, and we gave them to the team. Everyone was able to complete the exercises in a reasonable period of time, so we knew they weren't going to be too challenging.
Pre-screen question: For the numbers 1 to 99, print the number if its digits do not add up to ten. Otherwise, print the number and its digits 91 (9,1) if it adds up to ten. Download the file quiz.txt and use it a starting point for your program, keep it simple and make sure your output matches sampleoutput.txt exactly. When you've completed it, rename it to yourname.txt and email it to quiz@company.com with the subject of "Your Name: Completed Exercise".
A lot of people would just use convert the strings to numbers and then do the test to see if it adds up to ten, in this case I would kick it back to them and ask it to be solved mathematically. Usually, we'd get a response back right away with the "best" solution. Candidates that completed the exercise correctly and followed the directions got 15 minute phone screen to see if they had the technical background required.
For the in-person (or Zoom) interview question, we had a problem that required modifying HTML, CSS and JavaScript to come up with a solution. We stated this up front, and tell the candidates to use web resources to look up anything they need to. It also requires using modulus which they should already know (or figured out how to use!) in the screener exercise. If someone got stuck on something we felt they probably knew we'd give them some hints and they'd relax a bit. Most people solved it within 5-15 minutes, but there have been people that couldn't do it at all event with lots of hints.
In that case, we'd usually just end the interview and thank the candidate for their time.
From here we'd do some database exercises if their role called for database, and move onto an deeper assessment of technical background. That process worked well, and they're still following it today.
ones = number % 10
tens = number // 10
do_print = (ones + tens) == 10OP mentioned reading from a file, which you would only be able to use after string conversion to ints.
if toInt(number) % 10 != 0
print number
print number + "(" + number[0] + "," + number[1] + ")"However for any multiple of 9, the digits will add up to a multiple of 9. So you're looking for numbers in [ (n+2)*9 + 1 for n in range(9) ]
The common string based solution was to use a for loop, convert the counter to a string, parse the digits converting each one to a an integer and performing the calculation.
The exercise was given in C# so candidates just use string interpolation to output the result
About 6 seconds into a phone call, I’d failed for not matching whatever expectation he had for how a phone call should go. As far as I can tell, he expected me to do everything his way without being asked.
That was truly bizarre. I think I dodged a bullet there.
Combine the scrutiny with a 3-6 month hiring process, I decided to dodge whatever that was.
I have a disability and no network to speak of. Getting job offers is difficult. I generally can’t afford to avoid every job with a red flag.
Bingo! Remember that the interview process is bidirectional, you are also interviewing them to see if you want to work there or not :))
But the majority of people it’s one sided. They don’t have the option to challenge the interviewer. They need the job, the income, and cannot risk getting rejected by appearing picky.
I did so many interviews without any intention of ever accepting the offer, it would be almost comical. But, it's great practice for when I actually want a new job, and refusing offers always massage my ego.
Maybe different in your roles or part of the world but in SV - it’s brutal.
When the actual hiring manager, or someone above that person, shows you a concerning aspect of themselves during in the interview, that’s them trying to impress you, demonstrating their best behavior. It won’t be better after you get hired.
"He used his left foot to enter the room. A good candidate will use his right as they will put their best foot forward."
Although, it seems pretty silly to me.
I suppose he could have been acting, but I don’t think so. Looking back, I think he was expecting me to act like a vendor salesman promising the world in hopes of getting a commission.
Everyone has become Seinfeld trying to find a perfect match and inventing all kinds of idiotic tests.
It's not like getting a job is getting married. Average tenure is like 2 to 3 years now. Most of these companies won't be around in 5 years.
Things to watch for as a candidate:
* Is the process oddly impersonal with lots of gates to make it through before even talking to the team who is hiring? Red flags - MBTI personality tests. Extremely hard tech tests that even half correct gets your through. Video recorded timed take home tests. Etc.
* Do the people hiring you know how to do the job, are they asking you anything relevant? Are all the interviews kind of high level 10k foot view, and/or in the weeds in weird ways? Red flag - All there interviewees are peers to the hiring manager and above. Red flag - Digging into arcane proof of concept code from 10+ year old white papers that the entire industry has moved past. Not the flex the interviewer thinks it is. Red flag - Interviewers who seem confused why they are interviewing you, don't know what role it is for.
* If hiring into an existing team, are any of these peers part of the interview process? Red flag if no - sign of huge turnover / mad max type org where you are being brought in to fight for survival.
* Is the process unclear, do new rounds keep popping up, do interviews keep getting rescheduled, are interviewees constantly late to the interview? Red flag - Disorganized chaos, do they even actually have a role open they can hire, are they stalling?
I've managed to avoid leetcode/hackerrank due to my industry/niche/seniority, but orgs manage to invent their own BS.
In fact, if you sum up all the recommendations of people online about recruitment, you can't hire anybody, because every single move is something you should not do according to one of the self-proclaimed new expert.
Once again, as a developer, I can only notice how much of a diva my peers have become. We are very lucky we are a hot commodity on the market, because I tell you, no other professionals get a pass for a tenth of the things we claim we are entitled too.
One thing that comes over and over again is how much most candidates suck at programming. There are a huge quantity of people that are terrible at coding that will apply to your senior dev $200k job offer.
They all have a great CV, and they cheat at everything: fake interviews with a look-alike, using chatgpt or indian services to solve programming tests are not uncommon.
Last year, I had one former trader applying for a python job with a perfect resume, a stellar homework result, and who was claiming he likes "putting some good 10 hours of coding". First, there are maybe a 100 people in my country that can focus 10 hours in a row on code, and they won't apply for those clients. Second, the live coding review showed that he struggled to even create a basic virtualenv.
Last month I created a test that I knew had one question that ChatGPT got wrong. 2 candidates gave me the GPT answer last week.
So companies are desperate and try sieves after sieves, hoping to separate gold from mud. And they have limited time and resources to do so.
Of course the hiring process sucks. Even if they knew what they were doing, and most of them are not, it would suck.
Now don't get me wrong, it's nice the power balance is shitfing toward the workers for once, but hoping the other side won't react is just naive.
Usually engineers can spot the CVs talking around the fact they can't actually do what they claim well before it even comes to interview, but HR often can't and the recruiters will try it on anyway to get paid!
But we can't have nice things because of the proverbial bad apples.
You are free to reject the job offer, but thinking it will make any difference and that employers won't keep trying to protect themselves against being scammed is wishful thinking.
Wasn’t parent complaining about being verified, because he assumes that implies he’s lying? If your problem with the process is whether your word is believed without verification, or verified, then what’s the difference between a code test in an interview and talking to a previous employer? (BTW there’s a lot of reasons I might prefer the code test to having people discuss me, even when I have a good reputation. You can’t control what people say or think about you.)
> the hiring process has me do some dance
You’re upset by having to do a little bit of the thing that you want the job doing? I have to audition if I want to dance or act or play music. Why shouldn’t we audition to write code, or do anything? If you walk into an interview expecting to demonstrate your skills on the spot, which is what interviews are for and always have been, then it’s no surprise and you’ll be prepared. I’ve watched people get upset in interviews because they were asked technical questions and expected their 20 years of experience or whatever should somehow exempt them from talking about code. That attitude is a huge red flag TBH, and I’ve seen people get rejected for it.
BTW something to keep in mind is that a ton of people complain about interviews that don’t involve coding. Many would-be programmers are quite frustrated by the focus on soft-skills or experience, and very much prefer to be judged strictly on coding skills.
Interviews that don’t involve code are usually fine but not 6-12 of them. I usually start with (and we do not look for Haskell, ocaml, idris or prolog devs); do you know what Haskell is, what are some of the differences between Haskell, Idris and Ocaml. What’s the difference between prolog and Haskell. If they throw huge ‘i have no idea about any of this’ then I know they are going to be people we cannot use. What do lisp and prolog have in common. You cannot really fake knowing any of these and not having had hands on experience. It takes 15 minutes to filter out people who wouldn’t fit our team. But again: I hire seniors only and we work with very specialised financial software. I do apply for similar jobs where this applies as well and then I get a calendar invite with 12 interviews etc. No thanks.
But at the first line, either CVs of unvouched-for engineers are pretty ruthlessly culled by active engineers based on "I don't think these skills are even genuine" or its done by others like HR or management based on some kind of universal system everyone takes. I don't agree with the second method, but I can see why it's done because I know people who give too much credit in the first way and waste days interviewing people for senior roles who think C# and C are "basically the same thing anyway" (that's a quote, by the way).
Personally, I'd rather just not proceed to interview rather then insult everyone's intelligence with game-able and non-representative tests like leetcode. Usually you can decide if a full interview is a good idea or not out of a phone call where you ask a few unstructured technical questions that are specifically appropriate for the role and/or based on previous experience.
Oh, and your dev team is on a dead line and can spare very little time validating candidates, one is sick and you just hired an intern that needs baby sitting.
What's you magical solution?
Usually there's about a CV passed by me or others per week, an interview maybe every 8 weeks and a hire every 6-12 months.
Advantages of not being in a country or industry that offers SF FAANG/MAGMA/whatever salaries, perhaps.
BTW don’t forget that some of the candidates you’re competing against are actually lying, and they’re claiming things on their resume that if taken at face value will get them the job over you. Do you really want employers believing and hiring based on what people can say rather than what they can do? Be careful what you wish for, because if that came true, getting hired would be harder than it is now.
CVs don’t prove anything about skills, even when they’re 100% truthful, and your 10 years is definitely different from my 10 years. Interviewers need a way to compare candidates so they can pick the best ones, right? How else would you do that aside from testing?
This way you could focus on a quality interview with people with actual programming experience.
And for somebody who is a senior dev, it's a 2 minutes job anyway.
- Many interview coding problems are very unlike what we have had to do in our daily tasks, and very unlike what will be required if we get the job.
- If the company is trying to avoid that problem by making the coding part of the interview working on actual problems they're having, then that means the interviewee is giving the company work for free. (Unless the company pays for it, but that's vanishingly rare.)
- Even if they manage to thread the needle and have the coding part of the interview be relevant to the job, but not actually getting free work out of candidates, it's very hard to make it representative of the environment in which the candidates are used to or will be working. It's time-limited, very high pressure, with unfamiliar tools, often without the ability to consult online sources—or they make it a take-home assignment, and run the risk of having the candidates just get someone else to do it for them.
- Most other types of jobs don't require you to prove your skills. They read your resume, they take it at face value, they check your references, and if it turns out you lied on your resume and got the job, you get fired. ...Or they don't do their due diligence, and end up with terrible employees.
It’s an assumption to expect interviews need to reflect the work on the job or match daily tasks. Interviews are the employer trying to select the best candidate for an uncertain future, not mimic the drudgery of a day in the life at work. If I’m interviewing, I don’t want to know if you can code a specific task today, I want to know how well you can adapt to changing roles, whether you’re more extroverted lead material, or introverted and wicked smart or prolific, whether you’re ambitious or happy laying low. I’m much more interested in broad potential more than ability to perform technical tasks.
Isn’t the last item on your list a good reason to do some due diligence by checking whether people can code in practice before going through the expensive process of hiring them and having them fail and then having to try again with someone else? I haven’t seen a lot of outright lying on resumes, but I’ve seen a ton of overconfidence in one’s relative skill, I’ve seen people who are great on paper but duds in practice, but more than those I’ve see a lot of people who don’t communicate well, don’t get along well on a team, have bad attitudes, cover up mistakes instead of learning or admitting skill gaps, etc.
I don’t know what it means to claim most jobs don’t require proving skills. Most jobs are entry-level minimum-wage jobs. Anyone in the arts is used to constantly proving their skills via auditions, critiques, performances, etc. Doctors have it way worse with low paid grueling residency. We’re talking about high paid programmers where hiring the wrong person is an expensive mistake and can damage team productivity.
Do accountants have to provide a portfolio?
Do museum curators have to spend several hours curating a collection for their prospective employers, for free?
Do any of the 31 flavors of middle management have to sit through a "leet-manage" test?
Professions that require on-the-spot demonstration of your skills in order to be hired are very much the outlier, not the norm.
Do you consider certifications and qualifications to be a pre-hiring demonstration of skills? Many many jobs require these. Programming jobs sometimes require them, and those jobs are less likely to ask for on-the-spot programming during interviews. Not all programming jobs ask for live-coding, you shouldn’t assume they all do. Do you consider an interview to be a demonstration of skill? All the jobs you listed require interviews where you have to talk in technical detail about what you’ve done.
Speaking of outliers, there are almost no museum curating jobs, and they have to typically do a master’s degree and then spend years doing intern style work, perhaps similar to a doctor’s residency. Then after all that, the median salary is less than half of the median programmer’s salary. Accountants and Baskin Robbins managers also make less than programmers on average, and the sum total of jobs available in all three jobs you just listed is relatively small compared to doctors and artists - in the US (for example) there are ~1.5M accountants, less than 10k curators, and just over 2k Baskin Robbins, while artist jobs alone are double that of accountants and including doctors is around ~4M jobs. The number of programming jobs in the US is around 4.5M. Between artists and programmers, the number of jobs that requires on-the-spot skills demonstrations is definitely much larger than all jobs you just listed so far, even when I give you the benefit of the doubt and include all fast food managers in the US and not just Baskin Robbins.
Above you illustrated some reasons why asking for a skill demonstration is a good idea, so I’m not sure why it matters whether or not it’s common for other job types. Maybe programming interviews have better outcomes than accounting interviews (fewer firings or bad employees per capita), in addition to higher average pay?
> Interviewers need a way to compare candidates so they can pick the best ones, right?
For the "best" candidates they need a way of deciding which interviewers are worth their time to speak to, and overhead of the hiring process is a fantastic filter.
I've worked with a few of these folks over the years. No one wanted them on the team and they contributed nothing, but somehow they managed to retain their job. These types were the first ones to go whenever there were staff cuts.
I've come across this interviewing too. We had a guy say "I can't do this.". I said, it's OK if you can solve it...let's just start it and work through it together. It's more important that we see how you approach problems and work through them. "No...I don't think I can."
Is it out of place for a chef to critique the hiring process for a head chef position with a restaurant owner that's largely clueless about what happens in the kitchen? Most people would say that the chef might have a better clue about ovens and quiche recipes than the restaurant owner, right?
> Once again, as a developer, I can only notice how much of a diva my peers have become. We are very lucky we are a hot commodity on the market, because I tell you, no other professional gets a pass for a tenth of the things we claim we are entitled too.
Providing some advice about being a bit humble is always valuable. There's a fine line between being confident and knowing your worth and being cocky and a rude jerk.
That said, if you're a software developer, you have a skill that's in demand that most people on Earth have no capacity to perform even if given years of free training. It's reasonable for developers that might provide millions of dollars of value to a company to demand better treatment than people who provide a fraction of that value to a company.
But I find that all those posts and articles about hiring usually come from the beautiful world of fairy-tales in the head of the authors, as they never had to solve the problem themselves.
There is no doubt that hiring suck, and you can't want capitalism and suddenly be surprised the market balances out in favor of the other side when demands of devs exceed supplies.
But the arrogance of my colleagues, many of them never having taken a professional risk in their entire life, is still astonishing me.
Make a test for competences, and people will complain.
Don't make a test, and people will complain.
Make the interview process short and to the point, and people will complain.
Make it long and thorough, and people will complain.
No matter what you do, there is always someone on HN that will tell you that you're doing it wrong.
I've yet to pass an interview process that I would qualify as good, myself.
So if it's the case, it's probably because it's not very common.
Turns out hiring is not a solved problem, and it's easy to be a critics when you don't have to do it.
Spoiler alert: Anand got hired.
I didn't. After a thorough technical interview with the guy that would have been my boss, the VP had a five minutes talk with me, asking about my hobbies, what I looked for in a company and similar platitudes. His added value was deciding he didn't trust me, for no reason, except the magic Excel sheet he was entering my answers in. The first guy did call me to apologize.
The weird thing is the same company reached to me a couple of times years later. The most recent, I learned that the VP was instantly fired as soon as the company was bought by a french conglomerate and the whole infrastructure replaced. It was a mess, so I guess I dodged a bullet.
Once again, as a developer, I can only notice how much of a diva my peers have become.
I totally agree with that. We need to live with the rest of the employees every day, so it's better not to be a jerk.
A lot of the advice is bad because many companies have terrible hiring processes and candidates have to work around that. Questions irrelevant to the actual job are a bad sign, unless they are asked early as part of the screening process or to assess the level of seniority and experience of the developer.
Ultimately you should treat the interviewer as you would a customer, try to understand quickly what they are looking for without asking too many questions, and demonstrate those qualities, assuming you are interested in doing so, of course.
"Interviewees are often told to use “I” to get credit for work done, but “we” is probably a more realistic depiction of how work gets done."
I've had too many candidates talk about "we" and the general project, or what the team they were on did. But when I try to get at what they specifically did I get nothing. Sure we need team players, but not just cheerleaders. Take credit for your work!
The weirdest was one guy who I could tell probably did a lot of good stuff but wouldn't say so. It was like he was coached to always talk about the "we".
When you work in a large, heterogenous organization, it is important to pay attention to these differences, or else you end up either assuming someone did nothing or is a useless braggart because their culture doesn't match your own.
At least you can take credit for your own work, which is better than never being able to get into management (say, become a "cadre" in France) just because you didn't go to a certain school, no matter how good you are or how much experience you have built up. Ivy league elitism exists in the US too, but it's not even close to how prevalent it is in a country like France. To me that's a much worse form of ego brain rot than America's.
I find it very hard to say "I did X" for anything except for personal projects that I did myself from start to finish.
In typical work projects even the best of ideas always need to be bought by rest of the team and also executed collaboratively by the team. I would be dishonest if I were to say "I delivered this project on time/under budget" even if I did play significant part in keeping the project healthy and on track.
I come from a culture that has a similar approach, where taking sole credit for team efforts is typically viewed negatively. Took me a few years to get the hang of lying on interviews and taking sole credit for team efforts.
And ironically, it only dawned on me when I became an interviewer myself. That's when I realized everyone lies on interviews. Especially interviewers.
When everyone is playing the same game, it's a fair ground.
Just be clear about what your influence was on the project.
Not everyone lies on the interviews. I have absolutely never lied, and I can still use the "I" form.
I usually make proportions of my involvements clear.
For example if I start and architect/design the project, I will say so and then I will say I successfully onboarded others to the project and guided them successfully to achieve X results.
If I didn't start it, I will describe it like "I worked on the project X, with 3 other people. My responsibilities were A, B and C. etc".
God, stop being grandiose and talking about the project and deliveries. Did you implement a specific feature? Squash a a bug? Find a solution to a specific problem? If you didn't do any of those - specifically by yourself (or mostly so) I don't want you. Those are the key deliverables of a software developer.
Apparently I was born with no guile (probably an exaggeration), which means in a world where nearly everyone tells what they consider to be harmless little lies, I’m actively damaging my own career prospects.
I think everyone has their own definition of deception, and mine is the act of allowing (by making no attempt at intervention) someone to go away believing something you yourself know to be false. Which seems to be quite a strict one from what I’ve seen.
So you say: "I had this idea A to solve problem B, but not everyone was initially onboard, so I had to do C to convince others. I was able to convince everyone and I led the project to fruition with D results.
If you were in a leading role, it will be more impressive the more people and the higher levels you had to convince or lead.
I had this conversation with a co worker when he was made redundant. I reviewed his CV and he didn’t put any of the stuff he had worked on.
He said he didn’t add it because it wasn’t something he did by himself. It was a team effort. So I asked. Did you do X on project? “Yes”. Did you do Y on project? “Yes”.
It sounds like you contributed to those projects. If you get asked during an interview, you can absolutely take credit for working on those things. That’s your contribution!!! Yes it was a team effort that got the project over the line and made it successful. But you contributed to that effort and you should be proud and take credit where credit it due!
He was a bit taken back. He thought it would be lying or stealing to put those projects on his CV.
Personally it comes from my experience that really talented, passionate people work together they tend to share credit since the real goal is to accomplish great things. For me, over focusing on "this is mine" can be a bad sign of a candidate that is just there to get theirs and get out.
However I have been on the other side of the interview process only to realize that not everyone is driven by passion and excitement for the problems. I have had candidates that listed numerous things on their resume that they clearly only heard about during meetings and couldn't describe the most minor of technical details.
Which to me means the real solution isn't to enforce better phrasing of "I" vs "we", but dive into the technical details. People that are truly active contributors will understand every detail of the inner working of a project, whether they built it themselves entirely and just like to share credit with a team or they worked so closely with another it's impossible for them to disambiguate who did what.
Both types of workplace exist, and both types of candidates exist. The question for me is why the article author sent a type-A candidate into a type-B workplace. So that they could write an article about how they "educated" the VP?
This is a problem. It means the best output you're going to get is that of the level of the person doing the telling rather than the person who's first-hand doing and learning. I see this all the time. I once wondered why sometimes a new club/bar would open up, sparing no expense, but then the music would sound like shit. Not the sound system, but the DJ. It's because they were hired by someone who had more money than sense and didn't actually have good taste.
It doesn't make me bad at hiring painters if I don't want them to have a say in the color.
That's a contradiction right there. If experience is important, the "resource" can't do as they are told. If they can, experience is not important.
> and not rock the boat
And that's a different kind of attitude that has absolutely no relation to independence.
Anyway, from the article:
> He said: “He asked us a ton of questions that the team didn’t have the answers to.”
If you don't have the answers, you are clearly unfit to manage "resources". If you want blind followers, you better have all the answers.
Once you truly understand that then you can relax.
If you get the job, you get it. If you don’t then you don’t.
Roll of the dice. Means nothing.
I went to a job interview recently and the feedback from the recruiter was I couldn’t explain the (many) projects I’d built.
My recollection was I wasn’t asked, in a 30 minute interview that started late.
My lifetime of software development skills and experience was judged in minutes to be inadequate. Roll of the dice.
I'm giddy that the glib article from 7 years back has finally become reality: https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/
VP: "He kept asking questions we weren't prepared to answer."
Recruiter: "I think I'll go work for my cousin's parking lot striping company."
Has anyone figured out how to do this? Like reproducible experiments, formalisms, checklists...?
Last time I got good, actionable advice was from Journey of the Software Professional by Luke Hohmann. Covered stuff like self-selecting teams, assemblying a team with complimentary skills, and so on.
Or maybe there's some secret manual for interviewing as hazing and torture? Like the CIA's simple sabotage field manual?
https://www.thinkwithgoogle.com/future-of-marketing/manageme...
Subsequently I was offered the job and took it.
In a later interview for another position, during that interview it became very clear that they were wanting someone who would follow IT policy and NOT look after the end-user. I then couched my responses to focus on what the end-user needed.
Subsequently I didn't get offered the job for which I was very happy.
I generally welcome questions in an interview, but not all questions are equal. Some may signal a lack of preparation, don't seem particularly relevant, or come across as canned, like something they read in an HBR article (just kidding).
I'm no expert interviewer on either side of the table. If there's one nugget I'd take from this article, it's a challenge to "uncover capabilities, not just experience." How do I convey my own capabilities as a job seeker, or elicit them as a hiring manager?
Incidentally, the "77% of all jobs ... require little to no creativity" link takes you to a marijuana podcast, as the Martin Prosperity Institute is apparently defunct. I believe the statistic refers to a footnote in this paper (co-authored by the author of the submitted article):
The problem with "just read the room" is that you can very easily misread someone when you're meeting them for the first time, for example during a several-hour-long interview session.
Anand should ask all the annoying questions. This way he's saving both himself and the VP all the wasted time of hiring him and then having a broken relationship because things weren't clear later. This way the VP can also see what concerns the potential employee and if they have a potential mismatch in expectations.
Finally, even if we disregard all that I said above, if it's Anand's working style to ask a lot of questions and he hides this style during the interview, then he will invariably clash with management later due to it if he's hired. Then he may have more to lose then just a potential future job.
That's why I don't like the conclusion of the article. Anand didn't fail the interview because the criteria were wrong - the interviewer failed because they suck at being an engineering manager.
you'd be surprised at the amount of people who fake themselves for the date.
It's either that or stay lonely.
There’s really no use searching for the perfect job when the market is flooded with candidates and you have young children and mortgage payments due, yet you have to act like every job you’re applying to is some gift you’ve been searching for your entire life!
While this is certainly true, there still are usually enough jobs that fit the broad parameters of "pays enough to eat and take care of my rent". If you have a choice of a good boss at lower pay, or an a-hole boss at higher pay, you should take the good boss every time.
We spend 1/3, or more, of our lives at work, and life is far too short to spend any of it taking orders from an unpleasant, incompetent, or abusive a-hole. Not only will this make your time at work miserable, it will also lead to poor sleep and spending far too much of your "free time" brooding about your job. In that type of situation, you're not giving them 8 hours per day, you're giving them 24 hours per day. Eventually that's gonna take a toll on your physical and/or mental health. Don't do it.
I mean, in this climate where people are being asked to win X-factor competitions for the privilege of a job, how sure are we that those already onboard would pass if they had to run the gauntlet?
It's sad when "read the room" and "soft skills" are equated to agreeableness and making management comfortable. A company that thinks this way has only one real brain, the one in the head of the leader. Everyone else's job is to agree with that brain, not use their own brains to question it. If the leader happens to be a world-historical genius, this might work, but that's not true in most cases, so such a dictatorial structure doesn't seem likely to be the foundation of a successful company.