Hacker News Reader

Comment by axegon_ | Hacker News Reader

Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology. Yes, the quality of their tests will be lower, but that's fine and you can take that into account when you are checking them and you can check the test along with the candidates and ask additional questions which will steer them in the right direction, which ultimately will give you more insights about their thought process. Imo, their thought process is arguably the most valuable factor.

Also the most valuable question you can ask as a part of the non-technical interview: "So do you have any questions for us"? If the answer is "no", you are not looking at a good candidate.

View on HN

> Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology.

I agree that you want to see someone thinking on their feet and tackling a new problem. But you can get that without making the whole interview a mystery. I can tell you "we will be giving you some C# code with concurrency bugs and asking you to find them", and it's still going to be a challenge when i do.

I have recently been doing interviews where we talk to candidates about past projects they've worked on, and ask them to go through some of the technical decisions they made. We don't warn them ahead of time that we're going to do this. Often, candidates have interesting projects they did a few years ago, and they just don't remember them in enough detail to go through them with us. This tells us nothing useful about the candidate. I think the interview would be far more useful if we had prompted them to revise their old projects, and i don't think this would generate false positives, because we can still distinguish bullshit from actual understanding (although of course i think that!).

> Also the most valuable question you can ask as a part of the non-technical interview: "So do you have any questions for us"? If the answer is "no", you are not looking at a good candidate.

I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart?

> I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart?

If a senior engineer, at no part of the process, asks questions about the company, I would question that. To be clear, my experience is exclusively startups, but everyone I know would be very discerning about where they're going to be working for the next x years (x ≥ 2) and that's a long time with great opportunity cost. I'd be using every part of the interview that I can to extract information about how the company is run, who makes what decisions, and how long it takes to get a trivial feature out (mean-time-to-copy-change haha).

If they don't ask, then they either already know (which can only mean they're familiar with someone on the inside or someone who left on good terms, both of which are worth mentioning) or they don't know at all and don't care.

> I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart?

Not at all. The lack of questions shows a lack of interest. In every test I've ever prepared I've deliberately left one or two questions which are near impossible to answer and no one has ever been able to correctly answer them so far. The least you can do is ask about those. Or what does the release cycle look like or how is the development being tracked - literally anything, just to indicate that you genuinely are interested and not "I simply want this job".

> Or what does the release cycle look like or how is the development being tracked - literally anything, just to indicate that you genuinely are interested and not "I simply want this job".

What if I'm so interested in the job that I simply don't care about those things? If you're doing amazing work, who gives a crap about the small details!

If you're maximally interested in doing the job, you would ask questions to learn details that will accelerate your onboarding into your productive role and culture of the firm.

Also, if you are unaware of the norm that asking questions indicates interest, you are likely to have social/cultural deficits relative to an ideal employee; the likelihood of you being unaware of other workplace norms is increased.

> I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart?

I recently got told by the VP of Engineering of the company I am now undergoing onboarding with, that if a senior programmer asks no questions about how the company['s teams] work and doesn't have any requirements, that to him sends the message they are desperate and don't know their value.

Other people told me that not asking anything means that the interviewee is not proactive.

That only works if your task is equally unexpected/unusual for all candidates. If it isn't then either you punish them for being familiar with your stack (as you don't get that valuable knowledge) or you punish them for not being familiar (as you reward a good result).

> you can take that into account

I seriously doubt you can do this in a consistent and fair way.

Whether someone does well in a completely unfamiliar stack is fairly random, so you're almost certainly filtering out excellent candidates who just got unlucky with understanding the IDE.

> I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect

But why? The odds of them facing unexpected tasks on the job aren't that high, they have their job description, they have their set of skills, you delegate tasks based on that. It's not like there are curveballs coming every week where they have to upend their knowledge and strategies. It might be good to see how they act under pressure but seeing the person comfortable and putting in their best work helps evaluate how beneficial they will be to the company.

Imo, most of most jobs come down to how well you can tolerate doing what is basically intellectual grunt work while people interrupt your attention. As an IC, things are much more boring than ridiculous interview processes would have you believe.

> most of most jobs come down to how well you can tolerate doing what is basically intellectual grunt work while people interrupt your attention

I have never heard a better description of the majority of jobs out there.

The main thing "did the candidate have any questions for us yes/no?" tells you is "has the candidate read the usual 'how to prepare for interviews' guides where this is noted as a very common question for which the candidate should spend a little time in advance thinking of one or two good questions to ask". I guess that's a little bit of signal about their ability to prep for interviews but you probably are getting enough "does candidate know how to play the job-interview game" signal already...

> I think that seeing how someone reacts unprepared is a lot more valuable

I share your unpopular opinion, because the truth is generally told between the lines. At my last job I was the only one excluded from interviewing new candidates, because I am silly enough to throw ad-hoc technical questions into the discussion. My colleges managed to hire really nice people lacking basic technical skills, e.g. data analyst with 17 years of experience not knowing how to make a left join or a sub-select or PHDs not knowing what python or even a "programming language" is. We had some "fun", I can tell.

And this goes both ways. I remember as an "unprepared" candidate facing the ad-hoc question "how would you deal with time series data". Through well placed questions I figured out that they have - after removing the obvious seasonal effects - only 5 data point. After my answer "I wouldn't even fit a regression line on it" the interviewer said "no one here does time series analysis, not even I" and left the room with some made up excuse. Or when the interviewer was bragging about "valuing work-life balance and having a lower churn rate than the industry average" and I figured out he is with the company since 9 months. He was just smiling and left the room with some made up excuse.

Basic rule for hiring: don't let fool yourself AND don't try to fool others.

I am not sure I agree on the have you got any questions for us. Interviewing is a strange process. I find it quite difficult from being sociable friendly, coming up with decent answers then jumping into some kind of coding question, as it engages different parts of your brain. After you have done that coming up with questions for the interviewers is something different again. I can see why many people wouldn't have anything unless it was prepared. The interview process should be fairly two way anyway, so I ask as I am being interviewed, so often any questions I have are answered already.

If other people find thay have this problem have a couple of canned questions ready. Ask how much of a mess their code base is on a scale of 1 - 10.

Reply on news.ycombinator.com