Live data from Hacker News

Technical interview performance is kind of arbitrary

blog.interviewing.io

201–210 of 246 posts

Re: Technical interview performance is kind of arbitrary

#201

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

Interest is not sufficient.

People who have natural abilities chronically underestimate their effects. Some, regardless of interests, will always struggle more with certain physical or mental tasks.

Interest is important, but ignoring ability is not the right way to interview.

Re: Technical interview performance is kind of arbitrary

#202
post #164
post #161

Earlier quoted context omitted.

> The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride. Sorry, but you are being scammed. You are selecting for sales skill…

> Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written. You're asking the parent commenter to set aside eight years of personal hiring experience, over which time "every person I've ever hired who has passed that part has ended up in my 'great hire' category" (assuming, that is, that you've read what he/she's written). Can a candidate lacking the technic…

> Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

I withdraw this somewhat rhetorical question. I should never have asked it because it's not the point (and it invites answers out of the original context that overlook "the way the parent commenter describes").

Here we have two ways of evaluating technical candidates, just two of perhaps many: One seems to be more arbitrary and unreliable than many have assumed, and the other is very time-consuming, doesn't reduce to graphable data and requires a really good interviewer.

Please just recognize that having candidates jump through technical hoops is not as solid and objective a method of evaluation as it might seem to you, and could even filter out certain kinds of great candidates. Where at all possible, please try to treat the human being under evaluation more like a human being and less like a horse.

Re: Technical interview performance is kind of arbitrary

#203
post #10

I have been to lots of interviews, on both sides of the table. I find most interviewers unprepared to evaluate the person for the role, and instead exercise their own biases, stroke their egos, etc. It's largely a voodoo practice that we'll look back and laugh at as a civilization at some point..

I wonder how many employ Kahneman's recommendation based on his book, "Thinking, Fast and Slow": > Suppose that you need to hire a sales representative for your firm. If you are serious about hiring the best possible person for the job, this is what you should do. First, select a few traits that are prerequisites for success in this position (technical proficiency, engaging personality, reliability, and so on. Don't…

On a Manager Tools podcast episode they talk about hiring against a standard. First, have a standard (the six dimensions you mentioned fit the bill). Make every interviewer ask the same, or very similar, questions. Use the standard as your only source, and evaluate candidates against that. Hire the strongest one.

They ask interviewers and hiring managers to ignore "future potential". Humans are incredibly bad at predicting the future. Even if you think you can say how a person will perform in 5 years, the role might change, the market might change, customers preferences, personal developments, etc...

Re: Technical interview performance is kind of arbitrary

#204
post #84
post #62

Earlier quoted context omitted.

I have one major disagreement with you: > I have a Github profile with more than enough stuff on it Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not…

> Having them do code tests is pretty much the only way that doesn't involve talking to every single one. I get where you're coming from. But to me that's still a very, very selfish way of approaching this. You are asking for a blind burn of four hours of their time just to consider talking to them. Four hours is a lot of time. It's half a workday. You're asking for a hell of a lot just to not-a-culture-fit them out…

I don't know, I personally consider an all-day onsite interview to be a bigger waste of my time. With two or four hours spent on a take-home test, those can be any time during the day, probably time that I would have been wasting anyway. An interview has to happen during business hours, which means I have to take one of my scarce and therefore precious vacation days, and then actually go somewhere which is likely to take two hours round trip anyway, and that commuting time is entirely wasted. At least a work sample test can be an opportunity to practice my skills and an interesting challenge in itself. Then again, I actually used to do programming contests back in school so maybe that's just my personal preference.

Re: Technical interview performance is kind of arbitrary

#205

technical interviews are a joke. the majority of the time they exist so the interviewer can try to feel smart and subject the interviewee to whatever whimsical problem they found on the internet. how often do you do group coding in a whiteboard in your actual job? at one interview I was criticized for sitting and thinking about a problem for a minute without just blindly jumping into attempting to solve it. also tons…

I once was called into an emergency meeting by the CEO of the company I was working for the time. When I entered the room, all of the top brass were seated around the table, some visibly agitated. The CEO proceeded to hand me a single black whiteboard marker as he stated "the fate of the company depends on you". The problem was outlined by a fellow engineer and it was explained that I had 10 minutes to solve it, or w…

I believe you, but this really reads like something on /r/thathappened.

Re: Technical interview performance is kind of arbitrary

#206
post #188
post #109

Earlier quoted context omitted.

So how exactly is anyone supposed to gain new experience? I don't mean to be combative, but so many job recs and interviews expect X years of Y. How do you get that time it? You learn it, right? I didn't used to know Python, but it was obviously useful for my job. So, I installed it and learned it. I was producing useful results for my company very rapidly. Sure, a few years later my skills are more well rounded and…

If you're good at picking things up in a hurry, the best way to gain experience in new skills is to get hired for your existing skill set, either at a very small company or (better yet) a large one with incompetent management. In a small company, everyone wears a bunch of different hats and you will often be asked to do new things outside your official role. In a large company with bad management, staff turnover will…

>> "...(better yet) a large one with incompetent management."

Luckily this is >75% of large companies, IMHE.

Re: Technical interview performance is kind of arbitrary

#207

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

I would like to add that interviewing requires quite different skills from engineering. A good tech interviewer has to be a good engineer, but a good engineer might not be a good interviewer. I have seen good engineers with poor ability to read people, with strong bias of "curse of knowledge". They are more likely to fall for saleperson-typed candidates.

Therefore, a hiring manager should have the ability to tell which engineers are good interviewers, and give more weights to their opinions. Pay extra attention to those interviewers who is more of a big talker and less of a listener, if you have to ask him/her to interview. If one can't be a good listener to his/her teammates, I can't imagine he/she would listen to and observe a stranger with any substantial effort. Unless he/she is a genius in reading people, his/her feedback can be mostly ignored.

Re: Technical interview performance is kind of arbitrary

#208
I dunno - if you look at the data, there are fairly clear clusters of people who are 'probably good' and 'probably not so good'.

'Programming' is necessary but not sufficient for product engineering and that is what most of these interviews are trying to tease out. Good companies will balance out 'programming' with other rounds like 'technical design' or 'pair programming' or even non-technical rounds with business analysts or product to gauge general ability.

Re: Technical interview performance is kind of arbitrary

#209

Earlier quoted context omitted.

Startup A asked me to do a take-home programming challenge to prove my skills, as well as a general algorithm test to give them ideas how to run their core architecture. This took hours, I felt I was being asked to do their job for free (on the second test), and the results were pathetic. Startup B gave me an assignment to add a feature to their API and have my work merged with their active code base. I was compensat…

Option B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.

What's the difference between Option B and onsite whiteboard coding? Aren't you violating your employment contract all the same?
Post reply on HN