The goal of the interview shouldn't always be to get the job. If you have any length of career, you are interviewing the company as much (or more) than they are interviewing you.

My approach would have been to go with the new idea and see what discussion can come out of it. If they don't have time to get into it, that's one thing but if they are simply not open-minded to new ideas, I don't want to work there.

In the real world, people have to apply to dozens if not hundreds of jobs just to get an offer. The company has all of the power, so you tell them what they want to hear or you starve.

The job application process varies immensely by position and profession. For a junior developer there are hundreds of new listing each day but hundreds of qualified people applying, so the company has all the power and your comment would be true in that context. For a very qualified senior dev, there are dozens of positions posted each day where the company is truly set back until the role is filled, with only a handful of qualified people applying, so the senior dev has a lot of power.

In another profession like say a specialized electrical engineer, there may be only a few positions posted a month and a handful of qualified people so both the engineer and the company would be desperate that they could together be a fit.

This story was about an anecdotal experience where the power dynamic was fairly equal

That's true of unskilled jobs where there are usually more applicants than positions. That's not what's being discussed here.

Well - not true for all industries. In some, there’s a lot of competition for candidates.

We don't even need to look at other industries. It's demonstrably not the case for professional software developers at the moment. The companies are simply doing whatever is in their best interest which is retaining expensive and hard to hire for talent, ergo they'll treat you nicer. The second it's no longer expensive or hard to hire, things will take a turn for the worse (for the candidates).

I really love this kind of thinking. This isn't the first time I have happen upon it, but I really like the idea that the work I do for a company is an exchange in which both the company and I get something out of it.

Certainly when I got my first job I felt like I was there to take a job, not seeing if the company was a good fit.

Yeah, and obviously that's an ideal, not necessarily reality -- fresh out of college, or just looking more urgently for a job, I think the stakes are a little different and you gotta be a little more willing to just "take the job."

But as someone with experience, looking for higher-level positions, ideally with some time on your hands / savings in the bank to take your time interviewing around? Yeah, it should totally be a two-way street.

"Experienced software developer" is a comically in-demand job title. It's good to know that fact, and to be proportionately selective.

I don't think I could make a decision about whether I'd want to work for a company on the basis of a single employee's attitude. That person might not even be part of my day to day work group.

And yet the company chose to let themselves be represented by this person. It might also go the other way around, you are interviewed by someone that's awesome and you end up with another team that truly sucks.

In that case bad luck but if they send a dick to interview you it is more likely that the rest of them are also gonna be dicks. I like companies where you actually interview with some of the people you will be working with at least as the last interview round.

I mean, this is all the surmise of the person writing the article. I'd like to draw your attention to the fact that the interviewer never actually did anything wrong in the actual event described.

In terms of your idea that a single interviewer should turn you off from working for a company, possibly. Companies can be pretty big. I am skeptical that there are many medium or large companies that can prevent all negative interviewing experiences. Especially if the negative experience is, "I saw my interviewer make a facial expression that I over-analyzed and made a huge narrative about."

That said, if you want to use that as a signal that's your prerogative. My guess is that you'd mostly get false negatives from this signal but if you have many options for employment that's hardly a major problem.

It's true that there will be some false negatives. I basically have to go with my gut that if I get a certain strength of a vibe I have to interpret it some way. In one case it was one of the top senior devs interviewing me and didn't like the terms I was using or pronouncing them and seemed to be somewhat hung up on it. I considered that trivial and was trying to get to the meat of the discussion. I took that as a cue for the engineering culture, how would you interpret it?

Fair points though I was really only replying to your comment here, not the article any longer. I do agree that the article seems to "overanalyze" the situation, potentially there was literally nothing and he gave the 'wrong answer' for no good reason at all. Makes a nice article though I guess. FWIW I have experience with giving the "hard truth" in the "wrong situation" and I've come out unscathed, because I was very objectively correct and there was no way around it. Nothing pedantically debatable in my case, just "this is how the protocol works, not the way you say, no interpretation possible, look it up in the RFC". Not the actual example but like someone saying it's "SYN, ACK, ACK ACK" instead of "SYN, SYN ACK, ACK".

Companies can be large and in that case it's likely you will be encountering a fair number of people you won't like while there anyway. The question is whether you interview with "random interviewer of the day" (still bad if that's a bad apple but if the company is large you might take your chances while if the company is small, it's likely this is 'their best' or you will work closely with this person) or if you're actually interviewing with the team members you'll work with. If the company is large but you know you are interviewing with the team members you'll be working with and the feeling just isn't there or worse, then I think I'd take the possible false positive if I wasn't in a bind for a job.

At my current place for example I interviewed with a bunch of people in various rounds, from the typical HR stuff at the front, through various layers from CTO, my boss, our architect and then a sample of people from my immediate team. All of them very pleasant, had the best interview experience ever with the architect. We had a great discussion of pros and cons of various choices I made for the code I had to write, alternative approaches etc. Really awesome. Felt basically like a regular working session, no leetcode quizzing BS.

Previously I have interviewed with other companies where it just became clear after some time that the company and I were on very different terms with regards to how we think software development should work. A different interviewer might have been able to 'hide' some of it and I might have joined that company and been miserable.

The more time I've spent in tech, the more I realize that there are very few "correct answers" - there are things that work in a particular context. Software patterns in particular are just what you make of them.

I would have no problem saying "many people use MVC to mean 3 tier and other people use it to mean XYZ".

It is very difficult to be completely technically correct. It is also rare that one needs to be completely technically correct in conversation.

Also each person has an unique model in their head. Even if you read the same material, you could interpret it differently and people learn in different ways.

Do you want to have that discussion with your team-lead almost fully cold, in front of his superior? Because in the article, that is the key point. The applicant was totally willing to go into a fair discussion about the pattern.

However, doing that in front of the tech-lead his boss is likely to be different from a fair discussion. Disagreement about technical architecture is fine. Doing so in front of higher management is likely a different ball game.

Unless you absolutely need the job, I would consider this a great opportunity to figure out how his boss would react.

Getting into a lively technical discussion when you can see how well people can control their egos to find out the best course of action is very valuable. If I had a chance during an interview to find out how people behave in those circumstances I would definitely go for it. Who knows maybe the "boss" would be present in future technical discussions as well, I wouldn't want his presenc to change the discourse negatively.

And as I've personally been in positions like that (being the tech lead with the boss on the call), I'm usually thrilled to learn new information and discuss technical things, raising my opinion of the interviewee greatly.

Maybe that's because I come from a very straight forward culture where political subterfuge is frowned upon, but it wouldn't actually look very good to me if a member of my team would subtly alter a technical matter for the worse because of political pressure. Would I be able to trust that person? I would always have this doubt that they are "playing a deeper game", regardless if it was for my benefit or not.

The tech lead is not the one being interviewed here. Presumably, they are already respected in their workplace, and admitting that they learned something from the candidate's full answer should be seen as a positive by their manager. The way the candidate frames the answer is important here, so no-one seems stupid for holding a common misconception.

And if the tech lead can't admit in front of their manager to not knowing everything? That's a sign of a toxic workplace.

I'm not ashamed to admit that I have previously found myself in a situation similar to the tech lead: the interviewee gave a solution that I didn't know about - one that could be considered better - and my manager was in the room interviewing with me. I told the interviewee that this is a new direction I haven't thought about until now. It's important, otherwise we can't continue an honest discussion about the solution.

seems like having a discussion like that in front/with management would be a great way to suss out the way management will respond to future differences of opinion. A very valuable thing to know in deciding whether to accept a position

If you're already deciding you need to BS to keep the managers sweet in the interview, that seems like a pretty toxic work environment.

And giving a response like this is still a good indication of people skills -- Do you know how to present a controversial opinion in a way that encourages people to accept it, or do you ram it down people's throats?

Yeah I think this is way overblown- The way to approach this is "Well typically MVC is presented as such and people think its represented in typical architectures as blah blah blah, but from an actual theory perspective what actually happens is that blah blah blah..."

You cover both bases, give the blogspam answer that most view is the "right" one, but also show that you have a much deeper understanding.

My favorite question when interviewing node.js candidates was around this type of ambiguity- "Is node.js single threaded or multithreaded?" and most would immediately shout back "single threaded!" but the reality is that its a bit more complicated than that, its a single threaded event loop backed by a thread pool, and I wouldn't ever hold a "single threaded!" answer against them, but start to ask leading questions as to what happens when we have say 5 requests all come in more or less at the same time to see if they really understood how things work. And the point is not to gotcha! them, its just to start a discussion- though if they reply back "well its complicated..." then I know they probably are already there.

In the context of MVC though, I feel this is really overly pedantic. MVC is an idea that is never actually implemented in purity, and understanding the basic idea is all that is really needed, outside of maybe very specific roles implementing web frameworks.

Or "MVC is often thought of as mapping to the three tiers although that's a bit of a simplification that doesn't fully capture the mapping."

And there are essentially always nuances. So that's not really a controversial statement. At which point, the tech lead can accept the answer as pretty much what they were looking for or can probe further if it's actually the nuances they're interested in.

> "there's a widely-held concept X, but my understanding is that this is not completely correct, and in fact a better model is Y."

Why not say "there are many similarities and some differences, they're similar in these ways..."