I suppose that briefly turning it around on the immediate interviewer could be constructive, with some people, but I doubt I could pull that off even half the time.

My impression, from HN comments and firsthand, is that people still doing it seem to be thinking one-sided about it (i.e., they want to assess and/or manipulate "the candidate", and they seem to assume it's implied that everyone at the company is good). They probably also think this is convention, and perhaps resent or are suspicious of anyone not complying.

Personally, rather than turning the tables with the hazing, which can come across as hostile or combative, my natural inclination is to have a candid and thoughtful discussion about it.

(Warning: I've had poor success with trying to discuss with people who want to do the leetcode/puzzle-style whiteboard coding hazing. Maybe partly because the conversation only has occasion to happen with people who are still doing it, so it's not a representative sample of the field. I also suspect that, when it's with the more HR/recruiter-type people (not engineers or managers), they tend to not be participating in the discussion in the same way I am, but instead are performing the right head nods, while focusing on their normal modes, such as looking for red flags in what "the candidate" says, formulating how they'll report this, and being careful what they say.)

Company is interviewing the candidate not the other way around, no matter what we like to think.

Edit: Sorry I should've clarified. I am specially referring to companies that don't really have to care about your feelings towards their interviews. FAANGs for example. They simply don't care and there are million others who are willing and happy to go though whiteboarding. They just don't have to put up with your stuff.

Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.

I can deal with most tech problems and flawed companies, but the above list are my deal-breakers, and I absolutely am interviewing them to find out the answers.

If you assume you have no leverage then you will have no leverage, but that's more because you choose not to exercise it than because you couldn't exercise it.

I disagree. Unless the candidate desperately needs this job, he/she can walk away. The candidate is free to consider "company won't bother to answer my questions at the point when they have most reason to be nice to me" as a bad signal.

> I am specially referring to companies that don't really have to care about your feelings towards their interviews

"This company doesn't have to care about my feelings because they are huge and have lots of applicants and a giant incessant interview machine chugging through them efficiently" is certainly something I'd consider in whether I want to work for them, because it tells me I'd be a cog in a machine. (And if enough people consider that, perhaps they will have to care.)

To the parent question: I wouldn't ask a whiteboard question exactly, but I would certainly ask some questions about existing architecture and rationale so I have an idea what I may be working on.

Aren't you a cog regardless though. Why would one work for half the salary just because of an interview. If one can get over the interview part, he/she can retire 10 yrs sooner.

For what I'm paid, I don't mind being a bit of a cog. Work is a means to an end for me, not my identity. But I would like to be kept greased and worked within spec, not constantly in crunch time. And while I am fundamentally disposable, I prefer to work in a place that sees I'm lot more valuable not being disposed of. (Again, metaphor breaks down here; planning on your personnel being routinely disposed means you are planning on nobody ever actually developing any skill in your systems.) It's not all the same thing.

TLDR if you don't think you're interviewing the company too, you're doing yourself a big disservice and selling yourself short.

Absolutely.

But outside of places like SV or NYC, there may not be a lot of jobs available. For someone with a similar length of career, I'm not as flexible about being able to move to where there are more jobs. Is one just SOL when trying to improve their career; take what you can get?

I’ve worked for 20+ years but have only gotten serious about job hopping and interviewing for the last ten.

At any given time when I am job hunting I usually have three or four offers within three weeks. Not saying I am a special snowflake. That’s just the reality of the market. I’m very much interviewing the company. I usually have a BATNA of just keeping my current job.

Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.

Despite the HN bubble where every developer lives on the west coast and works for a FAANG or the next unicorn, that’s the reality for most developers. But there is definitely a difference.

Is tooling important to you? Ask about that. Do you want to push to prod like a cowboy, or does that repulse you? Ask about that. Whatever frustrates you about your current job, you can try to find out before you take a job where it's worse.

Framing those questions to get usable answers is a skill, of course, but if you've got a few areas to ask for, you can use lists like these to find different ways to ask. Just like interviewing, asking leading questions gets you 'right' answers that don't tell you what you want to know, so you want to get the interviewer to go off script and probably be truthful.

So at FAANGs for example, there are hundreds of teams that do all of kinds of stuff. You aren't necessarily interviewing directly with people from that team.

Why would you not? You're taking the risk of wasting a few months until you find out that the fit is poor.

But I do ask things that show if the technical recruiter actually knows what they are talking about.

"What strategy do you use to complete Pull Requests?" There are many ways to answer that question that will show you don't know.

In general, I ask things that make me see if the other person is reasonable, and I can talk to one-to-one, but also that they make conscious decisions and don't just carry around cruft.

This might involve asking "What ORM do you use?", then responding to their answer with "Oh, why didn't you use <other ORM>?".

Usually it literally does not matter how the interviewer thinks and what they believe is right, you want to know the actual company policy, which often will not be the same as the interviewer might want to.

However, if you're being interviewed by your future direct manager, then you do want to get a perspective on how they think, as their individual attitude towards various aspects of work life will be relevant to you - but usually most interviewers aren't that relevant.

I also ask 'company culture' related questions, my go-to question is ask what the team I would end up in did as a teambuilding event last year, and follow up with who decided the type of event. It tells you a lot on the freedom you'll get, the company's attitude towards people working there, and how healthy the company is.

In a somewhat related point, last time I was designing the coding question, I tested it on my teammmates. They all solved it, and their response was very helpful, and it allowed me to clarify some points in the problem.

But did they all solve in under the interview conditions? ( time pressure, coding infront of strangers, possiblity of not getting the job that you need etc).

I can pretty much solve all leetcodes on my own computer with noone staring at me like hungry wolf eyeing its next meal.

My goal was that the co-workers solve it under 10 minutes -- that 3x length factor is trying to compensate for harsher interview conditions.

As for leetcodes -- I just looked at the site, and my interview question would be rated 'easy'. In fact, I'd say that most of the 'easy' questions there are too hard for the programming interview.

do you have an example of this? I have hard time imagining solving algortihm qs under 10 mins.

I'm a manager that rarely codes as well, but was still asked coding questions in an interview. It's a bit annoying, but having had managers that have never written a line of code ever, I understand wanting to verify that the manager could theoretically do the work themselves.

That said, it was the only one of my four interviews that actually included any coding.

I don't write much code on a whiteboard, so that makes two of us.

But I agree that having a discussion about such problems can be productive. It may help separate legitimate problem-solving from mere hazing.