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?

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.

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".

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!

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 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.

> 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.

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.

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

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.

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.