Live data from Hacker News

Limitations and pitfalls of the job interview

fs.blog

61–70 of 185 posts

Re: Limitations and pitfalls of the job interview

#61
post #11

There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process. Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process. Part of my job is helping companies "fix" their hiring and one of t…

This sounds like what most internships are intended to be? How much does it cost to employ one of these apprentices?

> This sounds like what most internships are intended to be?

Does anyone take interns in their 30s?

Re: Limitations and pitfalls of the job interview

#62
In the summer before my senior year at college, I did a 3 month internship at a software development company. The interview for the internship was very soft, partly because it was only an internship, and also because I knew someone at the company who helped me get the position.

After I graduated, I applied for a full-time position there and have been there for 10 years. The interview process for the full-time position was also fairly soft and non-technical because I was hiring into a team that I worked with during my internship. I like to describe it as a 3-month long interview process. Not only did the company get to know me and what I was capable of, but I got to know the company and its people (in order to make a decision about if it was some place that I would like to work).

Surely this isn't scalable (internship are fairly rare, and generally are not available to anyone except students or recent grads), but the whole internship process worked out very well for me. It allowed me to bypass the traditional tech interview, which is something I feel very fortunate about.

Re: Limitations and pitfalls of the job interview

#63
post #51

I'm wondering if much of the discussion here is even about the article, which advocates for things we long know work better: * Structured interviews * Blind auditions * Competency-related evaluations The title "Job interviews don't work" is rather bait-clicky when clearly they advocate that _some_ form of job interviews work. Or are at least better. As a technical hiring manager for over a decade, here's where I'm at…

> The next best interview would be a portfolio.

I tried using my (limited) open source hobby project portfolio as a substitute for coding interviews. Companies either didn't take me up on it, or still also required me to do their regular take-home. Twice now, I have had two companies ask for the same take-home, although in the first case they asked me to re-do the work in their preferred language.

Re: Limitations and pitfalls of the job interview

#64
Never say no, but don't say yes unless you're sure about it.

You won't believe how often that will be good enough.

"Can you code in X?"

"I can program in many languages!"

Didn't answer the question, but was often enough for the interviewer.

Re: Limitations and pitfalls of the job interview

#65

A rather click-baity headline. The article doesn't claim that job interviews don't work so much as it claims that subjective job interviews are more subject to bias than structured job-interviews. I'd say that's true, but the caveat is that structured job interviews are more subject to people studying and honing skills specific to the job interview process. Grinding leetcode definitely makes you a better at solving a…

Nice analysis.

In my hiring process, we use a number of filters to gather the data we're looking for to make a decision. That requires a bunch of different steps. By the time we're done, we've spent at least 8-10 hours talking with this person.

From a technical perspective, we do the following:

- A short screen to go over the resume and ensure we've got a rough fit to the right role.

- A simple consistent coding exercise using coderpad. (surprisingly some fail)

- A series of consistent open-ended questions we ask everyone about their tech background, such as, what was one of the most difficult bugs you ever fixed?

- A set of consistent design/architecture problems: "given this design, what problems do you see? How would you fix them?"

- Another consistent, more involved coding exercise with an existing code base that is VERY much related to the work they'll be doing.

- A Q&A session on a wide range of technical topics. Goal is NOT for someone to know everything, it's to get a bit of map of their strengths and weaknesses. We found we make assumptions of what someone knows based on our background and their resume. We try to make this fun.

- Another set of behavioral and situational questions with a shared scoring rubric on values such as teamwork, collaboration, communication and leadership.

And then we have to take all of that data and look at it holistically and across a wide range of candidates. And even then we'll make mistakes, but we keep trying to optimize it, reduce bias, and make it better for candidates and us alike.

One last note: I like to finish my first interview with the question:

"Is there anything about yourself that you really want me to know that we haven’t discussed?"

Because I know I've only had ~40 minutes to get to know this person. I have my agenda of what I want to know, but I could easily miss a lot. So I want to give them a chance to represent themselves in the broadest way possible.

Re: Limitations and pitfalls of the job interview

#66
> A job interview is meant to be a quick snapshot to tell a company how a candidate would be at a job.

> Unstructured interviews can make sense for certain roles. The ability to give a good first impression and be charming matters for a salesperson. But not all roles need charm, and just because you don’t want to hang out with someone after an interview doesn’t mean they won’t be an amazing software engineer.

If that's the attitude someone has towards interviews, then no wonder they draw the conclusion that they don't work.

The real issue is that most teams either don't give much attention to interviewing (because they have their primary job to attend to), or too much of the process is delegated/outsourced elsewhere (where people only tangentially understand the work area, and/or have no deep knowledge of the job role).

Lean on interviews for measuring soft skills, and lean on demonstrations (portfolios, code tests, pseudo-code, problem solving, etc) for measuring hard skills. Every job requires some balance of hard and soft skills. If you use the wrong tool for the evaluation, or if the person using the tool doesn't know how to use it, you get the wrong result. Interviews have their place, but technical evaluation is not it.

Re: Limitations and pitfalls of the job interview

#67
post #51

I'm wondering if much of the discussion here is even about the article, which advocates for things we long know work better: * Structured interviews * Blind auditions * Competency-related evaluations The title "Job interviews don't work" is rather bait-clicky when clearly they advocate that _some_ form of job interviews work. Or are at least better. As a technical hiring manager for over a decade, here's where I'm at…

> The next best interview would be a portfolio. I tried using my (limited) open source hobby project portfolio as a substitute for coding interviews. Companies either didn't take me up on it, or still also required me to do their regular take-home. Twice now, I have had two companies ask for the same take-home, although in the first case they asked me to re-do the work in their preferred language.

I think it's a great idea and you should keep trying. Lots of places (somewhat understandably) won't deviate from their policy because consistency of the interview process is a good goal.

But at places that are a bit more flexible, it may work.

Re: Limitations and pitfalls of the job interview

#68
post #64

Never say no, but don't say yes unless you're sure about it. You won't believe how often that will be good enough. "Can you code in X?" "I can program in many languages!" Didn't answer the question, but was often enough for the interviewer.

Yikes, I don't know about that. If somebody asked me if I could program in, say, Perl, I'd say I knew what it was but that was about it. That's like somebody asking if I can speak Chinese: I know what it sounds like, but no, I can't.

Re: Limitations and pitfalls of the job interview

#69
post #48

If you want a really big competitive advantage, figure out how to hire great people who don't interview well.

Find them through word-of-mouth.

Double edged sword.

Certainly helps to find great talent and build a cohesive team.

Also tends to perpetuate our biases, create cliques and echo chambers. Makes it harder for new talent to break in.

When I build my teams, I try to balance referrals with newly sourced talent far outside my network.

Post reply on HN