Probably not what’s going on here. But human systems require debugging as much as technical ones.
I would personally walk away as well, its not like am some kind of superstar, I just feel that I won't be a good match to a company that asks questions that I feel are not needed. The way I see it an interview is always two ways. The company is interviewing me to see if am a good fit and I am interviewing the company to see if they are a good fit for me since I'll be spending at least 8 hours a day 5 days a week of my time working for that company.
Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit.
Bingo. Thats basically our interview process. I could ask stupid technical gotchas but thats idiotic. Better to ask pointed questions like: oh you like to program micros on the side, if you've programmed SPI before tell me what your most fun debug session involving that entailed.
These questions tell me more than anything like fizzbuzz can. You dig into details as much/little as you need to based on the replies but I honestly think the people you want shine though with their stories, not their rote knowledge.
If someone started spouting off intentionally wrong things in an interview as stated in this comment tree, I would call it a day and say thanks for all the fish, but I'm not starting off having to rebut 2+2=5 for this company. Even if that is a tactic for discussion, lets just have the discussion, as it stands that just makes me not want to work there as now what is the day to day like? Do I have to prove the world isn't flat constantly? Better to not find out and look elsewhere, even the weird cs quizz jobs are better than trying to deal with those kind of dynamics.
You’re a perfectly-reasonable person. I also think you’d find the work those positions do frustrating.
You can’t tell a multibillion-dollar client they’re asking stupid questions. You also can’t ignore the potential problems their asking them hints at. Walking away, usually, isn’t an option. Similarly, a CEO and CFO must be able to productively field “dumb” questions from potential investors, acquirers, distributors and yes, employees. “Dumb question” shouldn’t frankly exist as a category in certain relationships. Only opportunities to improve mutual understanding.
Not every role is for everyone. And not everyone is for each role. Part of interviewing, in my opinion, is not only qualifying for fit with the company but also fit with the role. (For solely internally-facing roles, I prefer a let’s get a walk/beer/take a hike together chat.)
To see it from another perspective, imagine what your response would be if you found out that someone you were interviewing was pretending to know something they didn't, just because they preferred to work with people smart enough to notice they were faking.
I agree. I never proposed that. I said I purposely ask questions the person at hand might consider dumb.
Note that many classic “dumb” questions are actually interesting, if not in their specifics then in why so many people ask them.
> imagine what your response would be if you found out that someone you were interviewing was pretending to know something they didn't
Again, asking dumb questions doesn’t require lying. Everyone goes through a dumb-question asking phase when learning. (I do.) The worst effect of this might be the interviewee walking away thinking me uninformed. Which, if I’m interviewing them, I probably am (relative to them). That’s why they’re being sought! In any case, people thinking I’m dumb is a fair price to pay for a well-tempered executive.
It's a huge part of the job and the idea that I shouldn't test people on it strikes me as absurd. You seem like you're jumping to interpret what I've said negatively.
Imagine a candidate who came in and said, "I'm really great at this computer stuff, just trust me!" but refused to show a resume, prior work, to even talk about it.
"Push back, it's fine, trust us!"
This ends up filtering for people who can deal with your bullshit,(as in: have other options) and don't mind doing so. So, good for you, I guess, but you could get better people by fixing your culture and being straight with people.
Regarding tenure, I don't understand how that's applicable to hiring new people.
Regarding the imaginary candidate I think this is supporting my point - no? Just like you wouldn't want to trust someone who offered no evidence for their abilities, I want to discern whether people can stand up to arguments and make compelling arguments for their case. In order to get the evidence I put them in a position to stand up to arguments and put arguments forward.
Regarding your thoughts about how this filters people, I think you've summarized it incorrectly. Even if I agreed that asking people to argue against me in an interview was "bullshit" then that wouldn't filter only "for people who can deal with your bullshit,(as in: have other options) and don't mind doing so". Clearly, the people who have no other option would also put up with the tactic, as they have no other option. Thus, the filter, as you put it, filters only people who don't mind putting up with the interview question. This is actually a point in my favor because if the candidate is not comfortable arguing for or against positions in a professional context then they would not be a good fit for the role.
Finally, you suggest "fixing your culture and being straight with people." I think I am being straight with the interviewee. I tell them upfront that if I say anything they disagree with I want them to push back on me, that I think disagreement and debate is positive and sometimes necessary. Again, the role requires disagreeing and pushing back on arguments, often in situations where there is pressure not to, so I think giving friendly encouragement and setting up a hypothetical situation where I will disagree with the candidate is a very reasonable thing to do.
> I always preface these sections of the interview with a moment to explain that I expect them to push back and disagree if I say something they think is wrong so that we can talk about it.
I interpreted that as, at least implicitly, flagging to the interviewee that not everything the interviewer says will accurately represent his/her views. Perhaps it could be made clearer, but it doesn't seem like the intent is to deceive.
That's pretty much the definition of a liar and outright deceptive.
Besides that, the tactic of trying to be debative and in this case outright dishonest and slightly combative is an incredibly terrible method for interviews.
Honestly the poster should be banned from giving interviews.
It seems to me that you've jumped to a very strong conclusion, based on a brief conversation that you have interpreted in the least charitable way possible.
In an interview both sides should put their best foot forward, assuming positive intent and trust. Purposefully asking “dumb questions” on the hopes someone picks up on the game, and then plays it as you expect, seems like a suboptimal approach.
I find “describe a time when” answers mostly useless. Interviewing, at a senior level, is a proxy for time on the job. Senior people must constantly deal with information flow. Being able to pick up on when to add to or correct that flow is key.
Note that this doesn’t have to be done in a pretentious way. My favourite way to do it is to discuss the company’s R&D. I will almost always know less than the interviewee. Their ability to accurately communicate in that context is vital.
Again, this only applies at senior positions. Lower down, one expects managers to know their subject matter with more detail. You can’t do the “go solve this approximate problem” thing one can with senior management.
* thought pushing n elements into an empty vector took O(n) amortized time (it's just O(n) guaranteed)
* thought a hashmap lookup took O(1) amortized time (it's O(1) expected not O(1) amortized).
I tried to gently correct him but he insisted on his views and I felt like I had to drop it so we could discuss other things also felt like I was dinged for it.
On the other hand I've been on the other side of the table, and can appreciate that interviewing people is hard too.
Similarly with a typical hashmap, the keyspace should occasionally collide, meaning non-edgecases would amortize to O(1) for multiple inserts.
This can be OK as long as you preface it with something like, "If you don't mind I'd like to ask something that might like a dumb question..."
If not -- if you're deliberately gaming the candidate (or cloaking your true intent in any way) -- then of course the better candidates are going to smell that right away. At which point walking out the door is not only permissible - but arguably the only response that make any sense.
I want to give out questions people don't know because I want to hear how they talk through understanding the question, what they know that might be related and why, and how they'd go about finding out. Hearing all of that is far more interesting to me.
Note, this was not a FANG, was not for SRE or Systems admin type role either. But this was my experience. The majority of interviews want you to repeat trivia bullshit because it makes their job 'easier'.
Honestly though, annoying interviews are just no-poach 2.0. It's a form of wage suppression if you really think about it.
There was a whole lawsuit about no-poach where a group of employers chose explicitly not to compete by agreeing to not hire each other's employees. I believe the same effect can be had by simply adding friction to the structure of the market itself.
What's amusing to me is the brilliance of it. It essentially exploits egos in the workforce to suppress their own wages.
One way to think about the interview process is that it's a way for small, compatible, minorities to find each other.
To make that happen, you have to be real during the interview. It's not for everyone, I know :)
My experience is that candidates are ready for trivia and sample/theory but are not ready to brag about their own cool shit. Talk about how great you are and what you learned, defend your choice, evaluate where to improve. That's what we do every day. we only use the white board for drawing arch-pictures/diagrams, and the occasional dickbutt.
In fact, that's my new (and only) whiteboard question.
I loathe this type of interview bullshit culture, and it more than anything else is driving me out of the industry. Sure I'm not Jon Skeet, but I do my job and I do it well. Continuing with these types of interviews and company shit, makes me want to go be an electrician or mechanic or anything the hell else.
Especially in any language where you have suggestions in your IDE, just remembering where it is would be fine. "Oh yeah that's in the IO.Sensors namespace" or wherever it is.
If there are some incredibly common pitfalls or footguns, those are a better test, especially if you can ask something like what the difference between two methods is. But even that is pushing it.
Operators, on the other hand, I think are fair game. If you're doing Javascript you'd better be able to tell the difference between `==` and `===`, even if the answer is "== does magic things that surprise people and I don't remember what they are, so I stick to ===".