Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making software engineering interviews predictive of job performance

qualified.io

Post reply on HN
Print view View original

81–90 of 113 posts

Re: Making software engineering interviews predictive of job performance

#81

Post by jamespollack »

geoffroberts wrote: post #55
jamespollack wrote: post #26

so you're gonna pay us to do these "work samples" at market rate, right?

Actually, yes! Erik Bernhardsson, the CTO at Better.com who is cited in the article a few times, does exactly that for finalist candidates that they ask to provide a significant work sample. I think that's 100% appropriate. But that said, a work sample doesn't necessarily have to be something that takes hours on end either.

ayy, that's awesome if they pay candidates for significant work samples. i think there's some discussion to be had about what's significant. anything more than 1.5-2hours in my opinion. an hour or two is how long an interview might take in any profession. asking me to work unpaid for 4 or 8 hours (one project: 3 days!) is excessive. maybe call it the "half-day" test. is it a half-day of work? if so pay. if not, then you can do that once during an entire interview process.

Re: Making software engineering interviews predictive of job performance

#82

Post by tracker1 »

tschiller wrote: post #15
tracker1 wrote: post #4

In the end, it's a crap shoot... Even their highest marker of validity is only about 50%. In the end, if you make it too hard in an employee market, you will have good to great candidates drop off... if you make it too easy, you will wind up at the bottom of the barrel. Market pay will also vary wildly and dramatically, and perception is equally varied. Where I work now, we have a small pre-interview code challenge..…

Great points - there are things we're trying to address over at Interview GPS. We're building a Wikipedia/Stack Overflow-style knowledge base of the best interviewer guides/rubrics: come join the cause at https://www.interviewgps.com/community/ We tag questions in 3 areas: Personal Values: instead of "culture" we help you assess shared values. For example: do you value fun vs. achievement? Competencies: does your sof…

By what they do outside work/school... I specifically mean if they work on software projects, using skills related to the skills they use at work. I've seen both sides of this and tend not to discriminate when someone has more experience vs. less... it's an offset, more important for interviewing someone out of a bootcamp, or with no formal education.

It really takes all types, so to speak. At this point, I've interviewed and met a pretty broad spectrum. The same goes for on the interviewee side as well.

Again... it's a balance... work history, personal projects (github activity), the pre-interview code challenge, as well as the technical interview are a matter of finding what's needed... someone can be less in one area and make up for it in another. To me at least, independent drive makes up for experience in a lot of ways, especially for more junior-mid roles.

Re: Making software engineering interviews predictive of job performance

#83

Post by tracker1 »

geoffroberts wrote: post #57
tracker1 wrote: post #4

In the end, it's a crap shoot... Even their highest marker of validity is only about 50%. In the end, if you make it too hard in an employee market, you will have good to great candidates drop off... if you make it too easy, you will wind up at the bottom of the barrel. Market pay will also vary wildly and dramatically, and perception is equally varied. Where I work now, we have a small pre-interview code challenge..…

I completely agree that if you're designing an sort of assessment process, you should go through it yourself or ask other engineers to go through it so it's reasonably scoped in terms of expected time commitment. You can also use assessment tools that specifically limit how much time an engineer can invest in working on the challenge, which is also useful in showing how much progress each candidate made in a set amou…

That's fair... a few days ago, got a solution (the problem is generally a cli program to transform a csv) that included a full API, data access layer and React ui. It was frankly impressive, and total overkill... turns out the request was unclear from management on our end.

I'm still surprised that almost nobody has used an actual library for csv parsing (naive solutions reading a line and splitting mostly), which to me results in so many headaches in practice.

Re: Making software engineering interviews predictive of job performance

#84

Post by lugu »

Just to share my experience.

1. We sucks at hiring, so we need to train juniors on how to hire early. 2. Programs live in the head of their creators. The code is just a draft left for computer to execute. Build a human culture where the aspiration is discussed. 3. We don’t replace people, we hand over the responsibility. Be ready to work differently. 4. I conduct interview by asking the candidates to explain me I piece of work she is is proud of. If I understand the what, how and why, she usually pass. 5. Remember: most issues are not technical but organizational. We can train people, but we can’t change them. 6. Set high quality standards for your team. Make them proud of their work. On boarding will be easier.

So, it is less about how to hire the shinning star and more about how to welcome and how to create a culture around your values.

My two cents.

Re: Making software engineering interviews predictive of job performance

#86

Post by xenihn »

dominotw wrote: post #34
new_realist wrote: post #3

“General Mental Ability (GMA) tests (like the IQ test) are very predictive of future job performance, largely because people with high intelligence can learn the skills needed to be successful on the job more rapidly. However, due to legal concerns they’re not recommended for companies hiring in the US.” This is what a classic FAANG interview is: an IQ test which is disguised as a relevant skills test for legal reaso…

you can pass every facebook iterview by practicing facebook tagged questions on leetcode. People do that every single day, here is an example from today https://leetcode.com/discuss/interview-question/551434/faceb... Its NOT related to IQ. You can search leetcode forum for tons of examples of actual FB questions, all of them are tagged on leetcode.

You can get better at IQ tests by practicing them.

Re: Making software engineering interviews predictive of job performance

#87

Post by pravda »

bitwize wrote: post #14
amznthrowaway5 wrote: post #11

Earlier quoted context omitted.

Why not just give an actual IQ test?

That opens you up to liability for race-based discrimination. The accepted wisdom is that IQ tests are inherently racist and favor white evaluees over black and brown ones.

>The accepted wisdom is that IQ tests are inherently racist and favor white evaluees over black and brown ones.

Huh? Where did you hear that?

The reality is that Asians score the highest on IQ tests, whites score somewhat below, blacks score lowest.

The accepted wisdom is that Asians have the highest IQs, followed by whites, followed by blacks.

Well, that's not entirely true. Ashkenazi Jews have the highest IQs, but their IQ-advantage is in the verbal area, which is why when you see lists of the highest-paid lawyers a disproportionate number are Tribe members.

Keep in mind that these are averages. There are plenty of dumb Asians and there are plenty of smart blacks! You can't apply group statistics to individuals.

Re: Making software engineering interviews predictive of job performance

#88

Post by proverbialbunny »

chapium wrote: post #19

The best interview process is not going to account for bad corporate policy, terrible bosses, or other confounding factors.

So true!

It's sad it's so hard to tell if someone is going to be a terrible boss or if there are systemic issues.

Some of the best interviews I've had, have had the worst bosses, and vice versa. Though, totally anecdotal, especially given I can only go off of the jobs I've accepted which is a sample set of the best interviews I've had.

Re: Making software engineering interviews predictive of job performance

#89

Post by proverbialbunny »

Data Science interviews almost always have a take home interview as the technical challenge. The in person interviews tend to be cultural fit interviews.

This is because DS work is larger than a bug fix, implementing a new feature, and even larger than writing a program from scratch. Even a small DS problem is a multi day problem. Most interviews allow one to take weeks to do a "quick" 2-3 day problem.

This process may be out of necessity, but I feel it reduces noise. You really do have a better idea of knowing what you're getting.

Software Engineers may groan at the idea of a take home project, but just throwing this out here: What if a company let the interviewer choose between a take home problem or an in person 30 min style white board interview? What kind of results would come from that? Would the people who take the take home interview work out better at the company, or would the whiteboard interviewers end up working out better?

Re: Making software engineering interviews predictive of job performance

#90

Post by TSiege »

The best interview I've ever had was I was asked how I might design a real user feature for their company and review a sloppy PR with errors. For the first I came up with two options and weighed the best reason for each and which I might go with depending on the circumstances of the project. For the second I wrote PR comments I would leave any developer with suggestions for improvements, concerns, and praise for good work. That was representative of my actual job as a software engineer.

The normal is taking some sort of tricky pop quiz styled questionnaire, which in my opinion was not representative of anything about me beyond I know how to use a for loop efficiently. Yet this is what I find these companies offer. They tout them as a quick fix cause its easy to standardize, analyze, and hard to do therefore good, and last but not least waste the candidates time but not the companies. Their the metrics are moot. Not only have they been proven to be ineffective by the big companies that spawned them, but I also find them demoralizing and a turn off.

It seems like the industry is heading towards a self imposed SAT style quiz where the lucky winner of this startup war holds all the power and provides little benefit to either side of this process.

Post reply on HN