> Anyway, there was only 1 proper solution to this: I had to answer what they thought was correct.
I think it was a poor solution. There are ways to respectfully disagree.
"I really think I'm right on this one. Since it's a question of facts, not opinion, we could easily verify it later."
Did the author know they were hired because they didn't rock the boat, or despite of it?
If I were hiring someone, I would want to know I'm hiring someone who can argue politely for what they think is right, and not see the argument in the context of "winning or losing", but in trying to find the best way forward.
How would you empirically test if the answer was right or wrong? What's on Wikipedia is also someone's opinion, isn't it? What's in a book that Wikipedia references is again someone's opinion.
If you can't write a program or other set of instructions to test it... it's an opinion.
'How does Dr Foo say that MVC maps to database-server-client?' would be a question of fact though.
Well, it's a matter of definitions. What means it's a completely useless and dumb question, but also that the majoritarian opinion on the relevant context is a fact.
That said, I don't think I've seen MVC used with the same meaning twice... what makes the question even worse.
knowing how many people can't take disagreement well, I don't think this was a poor decision, practically you can't just trust everyone to have a good head on their shoulders, when you just want a job to survive or get your foot in the door, you can't be picky with who you work for.
I think the underlying assumption here, is that it is better for your job prospects to agree with something you know is wrong, in order to avoid confrontation.
I don't think this should be the default recommended advice. It could just as well cost you the job, if you are interviewed by two people, with the other also knowing what his or her colleague said was wrong, and being disappointed you didn't find a way of politely disagreeing.
In job interviews, I would count it as a positive if I could see that the candidate could handle disagreement. That is in my view more important than getting a rather generic technical question "correct".
Behavioral interview questions give you more insight to this e.g. "Tell me about a time when...". In a technical interview you'd be wasting precious time determining how they present arguments. You'd also get false signal from interviewees who are uncomfortable debating their interviewer/know that they need to progress through the question.
A job interview is also you judging the company and people you’re applying to join. If you feel the team lead can’t handle you answering questions honestly because it might reveal one of his or her blind spots, that’s not a great sign.
At a certain point in your career, you'll start finding that the current TL you'd be joining often doesn't have the same context as you do. It can be threatening for junior leadership to onboard someone who has extra capabilities beyond what they do, and a big part of your job in these situations is to rock the boat...slowly.
Bear in mind, many TLs are in their current role by virtue of having a good idea, supportive management, trust of their team and good/lucky execution. This combination of activities can easily mean that you have a great up and coming TL with ~3 years of experience. Management may be bringing in more senior talent as the upscaling product requires it, but that doesn't mean you start with the same trust, management support, ideas, or in-house knowledge as the TL.
In such a situation, setting out to prove that you can outsmart the junior TL as your first contribution seems suspect...
Bear in mind that often successful companies, have many inexperienced leaders due to growth.
I was also thinking something along the line of whether you'd even want to work somewhere like that. But I guess not everyone is in a position to be so picky about their employment or maybe it would be a gateway to other opportunities.
Ironic, as I almost always interview for the opposite.
I don't really care what you currently know because software development paradigms can be learned with relative ease for a motivated and intelligent individual who already knows something.
So instead I:
1) Poke around their CV/Resume. Just ensuring that they have the stuff they say to a basic level (some people just spam keywords)
2) Get them to a point where they admit they don't know something. Usually this means a deep dive on something common to the role I'm hiring for and that they have experience in.
If you're unwilling to say you don't know something I usually reject the candidate. I know interviews are stressful and you want to impress your interviewer, but if you're willing to try to bullshit me at an interview then you're willing to bullshit me in a post-mortem, and I can't have that.
This may be a little naive, but what if your expertise runs out before theirs? It’s not unthinkable that a candidate has more depth in a field than you do.
I remember asking a friend once if he could answer any Tolkien question, and he answered that he couldn’t answer everything, but the stuff he couldn’t answer, I didn’t know the right questions for.
I'm always hopeful that the person I'm interviewing is more capable than I, and they very often are. But there's an interesting thing: the more expert a person is, the more willing they tend to be to say "I don't know" (often rapidly followed by informed speculation and a comment about how they would find out). Combining that with the fact that true experts usually prefer to operate at the limits of their knowledge means it's not hard to get such a candidate to say "I don't know".
It's certainly not necessary to operate at the same level as a person to get them to operate at the limits of their knowledge and ability. In fact, relatively inexperienced people have a knack for asking those "naive" questions that lead into very deep pools.
Edit: I should also mention that my interview style is not in the form of a quiz. It's a conversation. I think that makes a difference as well.
> So I decided to start by giving the correct answer, and see how he responded. I explained “The model-view-controller is a software pattern, and so resides inside the written code. Since in most cases, this code only runs on the application tier, …”. But then I saw him frowning, and so knew this was not the answer the was expecting. So I continued:
This is a great cold reading technique that works in magic tricks too.
You have some trick where someone needs to pick from 10 cards. And your patter goes something like "Picture the card in your mind. Ace of hearts. Ace of hearts" If they give a big reaction then you've found their card and performed a miracle. If not then you just continue "Of course, that's just an example..." and continue the patter throwing out other hints. Of course, it's tough to make this your only trick but it can really elevate a good trick to amazing.
> "Picture the card in your mind. Ace of hearts. Ace of hearts" If they give a big reaction then you've found their card and performed a miracle. If not then you just continue "Of course, that's just an example..." and continue the patter throwing out other hints
Wouldn't you have to do this on average five times to get the right one? Wouldn't it be a bit suspicious giving five example cards before arriving at the right one?
That’s not how it works. Usually you try to force a card with a high percentage success but if it fails you will fall back to another way of revealing the card
Yeah, it's all about card control. I used to work with someone who could shuffle and unshuffle a deck, and place any card into the deck and pull it back out (after one or more shuffles.) Takes years of practice.
The hard part is writing your patter so that it doesn't sound like you're listing cards. Without giving away too many magical secrets, I invite you to consider the fact that there are many ways to reference cards more subtly. Color, suit, number, high and low. There are also a few different possible reactions.
I once got two raises in an interview because I was so (pleasantly) surprised by the size of the first offer that I wasn't sure what to say. There was a bit more to this situation - I liked the job I was in and the employer really needed someone, but it was still a revelation.
Keeping your mouth shut, saying no, and not lying or BSing are three of the most useful skills you can develop. Many people feel pressure to respond quickly, especially in a performance situation like an interview, just as the writer of this article was highly tuned to what his interviewer wanted to hear. Controlling the tempo and direction of your own responses is a way to gain the strategic initiative without being disagreeable.
We are trained to answer quickly, people find silence uncomfortable (except with close friends).
Just pausing and not answering quickly when given an offer is a power move. I know it consciously but I still find it hard/impossible to do in real life.
I used to do a very stupid magic trick where I would have someone pick a card and then shuffle it back into the deck. I would shuffle a few more times while asking them to focus on their card. Then I would ask them to name their card. They did. I would put down the deck and say "not only have I found your Ten of Clubs..." and then I would look at the top card and finish with "...but I have changed it into the Ace of Spades".
Every once in a while, purely by luck, the correct card would be at the top. In which case I would just change the second line to "...but I have brought it to the top of the deck for you". My sister begged me to tell her how I did it for years.
Dai Vernon had something akin to that. I -assume- it was the serendipitous case you mention, but it is, after all, anecdote, so it might have been something more. But, pulling from Wikipedia - 'He also had an encounter with another up-and-coming young magician from his town, Cliff Green, who asked Vernon, "What kind of magic do you do?" Vernon responded by asking the boy to name a card. Upon pulling a pack of cards from his pocket, Vernon turned over the top card of the deck to reveal the named card and replied to Green "That's the kind of magic I do. What kind of magic do you do?" '
Heh. Happens all the time with tests and questionnaires, the choice is always frustrating:
* "Does the author really mean what they are asking? Are the mistakes in the phrasing or corner cases intentional, meant to catch me, test my deep knowledge?", or
* "Is the author just not very good with logic / not thinking this through?"
I go with the latter in "soft social" contexts. Never regretted it yet.
This saved my hide recently in June, when I had to undergo a mandatory psychological examination for my gun license permit. Serious official stuff, with my permit on the line… And the "serious" psy-test was exactly as "robust" you'd expect from the field of psychology.
I answered the way I figured the test author construed the questions (= what they likely meant to ask), not what they actually asked. Easy pass.
Same with some driving exam questions I have had. For example worded something like that, "does driving faster in some sections of the journey affect your planned time of arrival?"
I don't remember if the wording was specifically like this, but it was something that to me logically obvious answer is "yes", but the correct answer and what they expect is "no", to show that you are a reasonable driver who won't speed unnecessarily.
And I think throughout the driving exam there were several questions like that. This type of thing really annoys me.
EDIT:
I found the actual question - although I still had to translate it - and I think I was giving the question a benefit of the doubt from my memory, with the term "planned" as I had written here, the actual way the question was setup was following:
What affects the duration of a planned journey?
a) Length of the journey.
b) Maximum speed in few lone sections of the journey.
It uses checkboxes, so you can check both.
They expect you to check only a), but b) is in my view also logically correct answer as if at any section even if it's shorter than 1 metres, if your max speed nears 0, duration of your journey will reach infinity. But it is worded in such a way that most people will get the hint that B) should not be checked.
I don't know about that person, but a friend of mine from India was telling me about a driving test question there - [translated] "How far should you stay behind another car - A) 2 meters B) 2 seconds". Apparently the correct answer is 2 seconds. In my opinion, the question is weirdly ambiguous.
What's ambiguous about it? Two meters behind a car at highway speeds can get you killed.
If it were a question only about cars at rest it would be phrased something like "how far behind a car should you stop when queued" or something of that nature.
I guess two meters is sufficient when you drive a walking pace, but any faster than that two meters will be too little. You say that this was in India, and I'm guessing two meters is way too much in a traffic jam :-)
"Two seconds" is what I learned too. The book here says that you should be at the spot where the previous car was two seconds ago, which is good advice, as it's independent of speed.
You can think of it as "it'll take you one second to react and one to brake to a stop, so you should be two seconds away".
I was taking a firearms safety course and there was a true/false section on a test. I can’t recall what the question was specifically but it was about which laws something fell under and the main issue was the word ‘or’ - when used as a logical OR the answer was True. When used as a sort of common day ‘or’ the answer was probably false.
I put false without thinking. I had everything else on the test right and part of the course was the instructor reviewing your test and going over your incorrect answers. He wasn’t a programmer (I think former military tbh) and didn’t really understand why I got it wrong even after I explained it…
In common usage, "or" is usually taken to mean exclusive or (XOR). Logical OR is non-exclusive. In most cases you can infer which is meant from context or it doesn't actually matter (much).
On a test for a gun license, it could get a little squishy as there are likely questions about the law (which only sometimes aligns with common sense) translated into lay English (which lacks the degree of precision you would likely find in the actual legal phrasing).
From Reddit ELI5:
"Cream or Sugar, in coffee is OR it means one the other or both
Fish or Chicken, for dinner is XOR it means one or the other not both."
Let's just imagine (for the sake of an argument) that you're just about to be given a roadside alcohol breath test by a police officer, but in this universe having just eaten fish or chicken can cause a false positive. The officer asks you if you had eaten fish or chicken recently. In fact, you had both fish and chicken in your last meal an hour ago (don't ask). You should answer "yes".
Most cases where "or" is taken to mean xor are actually asking for a choice, expecting one of the options as an answer. If the "or" is part of a question expecting a yes/no answer, then it is much harder to justify it being an xor.
I imagine they could ask questions like, "should you point the barrel at the ground or check the chamber for a bullet?" and you might say "or?" NO stop you need to do both, while the expected answer is YES you idiot you need to do both. Sometimes you just can't win.
Actually, as worded, I think "no" is technically the correct answer to that. The current projected/expected arrival time would be altered at the time that you begin driving more quickly, but the planned arrival time is ossified before you start the car.
Yeah, I couldn't find the specific wording right now and whether there was some sort of plausible play with the word "planned". This question is also translated.
Actually I managed to find out the exact wording of the question, it was fairly different from what I remembered:
What affects the duration of a planned journey?
a) Length of the journey.
b) Maximum speed in few lone sections of the journey.
It uses checkboxes, so you can check both.
They expect you to check only a), but b) is in my view also logically correct answer as if at any section even if it's shorter than 1 metres, if your max speed nears 0, duration of your journey will reach infinity. But it is worded in such a way that most people will get the hint that B) should not be checked.
While we are at looking at it pedantically (keeping also in mind that you said it's translated) I think their expectation of the answer is fair and they give more than a hint on it as well. Like you'd be stupid not to know what answer they want you to check.
"few" and "lone sections". As in statistically irrelevant. The assumption is that people 'get' for example (and its being taught over and over in driving school too) that if you speed to get through one traffic light in the city you'll not make it through the next one anyway and thus not really be faster. On the highway if you only speed once or twice for a short lone section you won't really notice in the end.
You don't even have to come at it with a nerd mathematicians mind and play tricks like Max speed near zero (not a realistic scenario so not something a driving exam would ask but definitely a fun scenario in a math lecture at university maybe). I can think of multiple sections in my city where speeding through the right traffic light when it's "cherry green" will net you a significant advantage because of the awful street and intersection layout and traffic light phases in that area. If you do the same just one traffic light after it though it won't help you at all because the next light will catch you unless you really want to cause an accident.
And if you are driving a 500km+ route and you can "speed" through it at 160+ km/h for a significant portion of it vs. going 120 that will save you a noticeable amount of time on the journey. This assumes something like Germany and your route being in parts with not many speed limits and not too much traffic so that you can comfortably cruise at 160 to 180 vs. arriving as a nervous wreck close to a heart attack because of all the near crashes from slowing down for the grandma going 100 switching to the left lane a few car lengths in front of you.
If I remember correctly, that question likely refers to some argument in the driving manual about speeding.
Something along the lines of "speeding in most urban areas doesn't actually help get someone to their destination faster. There are always multiple traffic lights and other cars to contend with, so it's not helpful to go over the speed limit and it increases the risk and severity of an accident." It's perfectly solid advice, who hasn't been passed aggressively by an ah-ole with tinted windows only to catch up to them at every traffic light?
The question obviously wants to screen for that tidbit of knowledge, but it's not phrased rigorously enough for the HN-crowd, I guess.
On the other hand, if you are driving on the interstate highways across the USA, driving 85 mph instead of the 65 mph limit will save you roughly 3 hours from an 800-mile journey.
Isn't there some confirmation bias (not sure if that's necessarily the correct term here, but you'll get the gist regardless) here in that you're more likely to remember the situations in which you catch up with the person who passed you (i.e. "look at this idiot getting nowhere"), and less likely to remember the situations in which that person makes a light that you don't and you never see them again? Massively depends on the specifics of the roads you're on too of course (and also how the lights are timed).
Years ago the did an experiment in Germany (I know, a one time test with 2 cars/drivers is more or less anecdata).
The task was to drive from Duesseldorf to Munich. Two identical cars, two very experienced drivers. one was told to go as fast as possible without breaking speed limits on the way (we don't have a general speed limit on the German Autobahn (highway)) tthe oother ro drive at a relaxed 120 km/h were possible and also honor speed limits.
Both were equipped with EEG (heart rate and stuff).
The driving distance is slightly above 600km.
The first drive (as fast as possible) arrived first. Waiting for the relaxed driver to come in second. That happened 20 minutes later. So on a trip of > 5 hours the gain was 20 minutes.
But at what cost. The EEG told a story of pure stress, massive heart rate spikes even for an experienced driver like the one behind the wheel. While the other one came in not only at a relaxed speed but a way more relaxed body and mind.
Medical doctors concluded that the EEG of number two was way more healthy.
Btw: One reason why the first car was only 20 minutes quicker was the fact that the driver had to stop to refuel. This cost him minutes. While the second driver arrived with gas to spare. So even economically it made sense to drive a relaxed style. Not to speak of the ecological aspect.
So to wrap up. The fast driver often comes in first. But not as quick as the feel they are. And at a high price.
Counter anecdata. I monitor my heartrate (along with other relevant statistics like speed, distance, elevation, and barometric pressure) while engaged in activities like mountaineering. Even when I'm not physically straining myself but just carefully traversing an exposed face, I don't consider a raised heartrate there 'less healthy' in and of itself because it's a side-effect of the excitement I'm feeling, and that feeling (sometimes not necessarily in the moment, but always afterwards) gives me an overall sense of improved wellbeing. Do I get stressed out sometimes? Sure, it's a dangerous activity. But overcoming that and accomplishing my goal rewards my mental health in a different way. Only half tongue-in-cheek: Maybe the faster driver was simply having more fun?
In this case you're probably right that the faster driver was just more stressed for no real benefit, but an EEG is not always a good proxy for how "healthy" something is (even ignoring obvious cases like physical exertion).
If you have a link to the study I'd love to read more.
EDIT:
One other thing I missed on the first read of your comment was the fact that the driver was instructed to "drive as fast as possible" and then given access to roads with no speed limits. I feel like that would have the potential to exacerbate the 'negative' side of things and that a more reasonable middle-ground could be found both in terms of driver stress and also fuel economy.
Basically this guy made his scientific career by doing epic experiments where he observed communities of baboons during various social interactions, blow-gunned individual baboons with tranquilizers, then very quickly, took samples of their blood to analyze glucocorticoids (these are stress-response hormones and have a half-life measured in minutes).
Anyway, crudely stated, the major finding is that animals have intense episodic stress throughout their lives but never suffer health consequences from that stress because it's occasional. Humans, on the other hand, can get the same levels of "fight-or-flight" stress but at long-lived, daily intervals. Excessive glucocorticoids, over a long term, can interfere with the normal functioning of the body and precipitate a wide variety of health problems including heart-disease (and ulcers, as the title suggests).
In the case of driving, an aggressive lane-changing drive in a fast car might be exhilarating under certain conditions, but it's a different story for a daily commute. It's no accident that the advice given to people that experience aggressive drivers on the road is often along the lines of "Let him go, don't become a part of his bad day." Aggressive driving is a self-reinforcing bad habit that becomes part of people's identity in many cases. Personally, I don't care about the health of aggressive drivers, but I do care about their propensity to cause accidents and hurt innocent people.
> but I do care about their propensity to cause accidents and hurt innocent people
Absolutely agree. I live in a 30km/h zone (regular speed in a city is 50km/h in Germany). And we have speeders every day. While kids are playing and elderly people trying to cross the streets.
What I wanted to say:
I care - and we petitioned the city to at least have marked parking spaces implemented with big flower pots on every side to at least reduce the speed people can go here.
The spikes and reactions were stress reactions measured by medical doctors from the monitoring of multiple signals (heart rate being one).
So they came to the experimental conclusion that (at least in this experiment) driving at the limit of what was possible in terms of speed the car could go and speed traffic would somehow allow was a factor of stress for the driver.
They also qualified the added amount of fuel necessary to drive the distance.
But they did not say one was better, one was worse. They just let the viewer decide on which variant they preferred.
And as I said: If the externalities were priced into taxes and cost of fuel - why not let people and the market decide if it was worth to them to arrive 20 minutes quicker on this distance.
it isn't true though. suppose there are n lanes and more than n cars, which is almost always the case in the city. if you pass someone, even just to end up stopped at the same light, you are still ahead of them in line. moving ahead by one slot is a very marginal gain, but it does add up if you pass many cars on your journey. in addition to being ahead by however many slots, eventually you will encounter step-wise jumps in travel time where you get through a yellow but the person right behind you has to stop.
over enough journeys, driving faster will always decrease your average travel time (unless you crash or get pulled over, I guess). the way to discourage people from speeding is not to tell them something obviously wrong, but to discuss the legal/safety risks and the increased gas and brake pad consumption. I understand that I can get places faster by speeding in the city, but I don't do it because, to me at least, the gains are marginal compared to the risk, cost, and stress.
> [...] eventually you will encounter step-wise jumps in travel time where you get through a yellow but the person right behind you has to stop.
Keep in mind that driving manuals are deliberately written at a 6th to 9th grade reading level depending on the state.
Yes, you're right that the gains from speeding are marginal compared to the risk, cost, and stress. But it's hard to communicate that kind of nuance. If the manual just says lead-foots aren't going to get somewhere faster by speeding to each intersection that's "good enough" and very close to reality for the purpose of the manual. National merit semifinalists can get the queue-theory version from their high-school math/driving instructor during driver's ed.
>the way to discourage people from speeding is not to tell them something obviously wrong, but to discuss the legal/safety risks and the increased gas and brake pad consumption.
Is it though? Almost all the knowledge we have is taught using flawed and simplified models that we can niptick and find "obviously wrong" when deeply examined. https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder
And IME, when I'm explaining something, pedantry and specifics almost always get my audience confused more than help to get the point across.
There's that, but there's also the possibility that it's conflating two things: If you're speeding, you'll also have to go around cars that aren't, which reminds me of this one about weaving between lanes vs sticking to one lane that the Mythbusters tested: https://www.youtube.com/watch?v=ZefgUVg3qx0 (4 minute long cut of segments from the episode).
They found that weaving between lanes is faster, but not by very much depending on which lane you're comparing it to. The final result (shown at 3:54 in the link) was:
* Weaving between lanes: 1h 16m
* Lane 1: 1h 19m
* Lane 2: 1h 20m
* Lane 3: 1h 29m
* Lane 4: 1h 33m
Lanes 1 and 2 are close enough I can imagine it being chance and more tests resulting no noticeable difference. And for an over-an-hour drive, it's already no reasonable difference anyway.
This basically just says you have to know which lane will usually be faster and why.
If you know the area and traffic patterns you can do that and basically stick to your lane for long periods and just switch a few times. I have something like that on my pre-covid commute for example, where you have to be in the right most lane until between a certain off ramp and the corresponding on ramp. There's always lots of traffic and you go between 10 and maaaybe 40 km/h. There you switch to the leftmost land so that you don't get bogged down by the regular mergers from the on ramp in the right lane and the 'middle lane drivers' who merge into the middle lane right about there too. Then until the next on ramp you stay on the left lane but have to switch over to the right lane again because no trucks allowed on it and most people try to pass on the left lane while everyone else is stuck with middle lane drivers and trucks.
If you know the area in the above example, just choose lane 1 for sanity. If you don't know the area and happen to stick to lane 4,id rather try weaving to be honest.
Certainly over longer distances and highway driving, driving faster will get you somewhere faster. In city driving though, where most people drive, it is correct that speeding up for certain portions of the journey will not get you there faster since the increased speed over short spurts can't make up for congestion, stop lights, etc.
Pretty much. Every EVIP (emergency vehicle incident prevention) course preaches this. The advantage to lights and sirens and opticom (the traffic light changing technology) is minimizing stop and go, and optimizing flow of traffic in your direction. They demonstrate that an extra 20mph on your average response, which is likely less than 3 miles (if not quite a bit less), and not much more than 5 until you start to get more rural, is likely only to save you seconds - and there's very very few things where an ambulance arriving literally seconds faster makes a difference in patient outcomes.
But it does slow your reaction time, and it does massively increase your accident risk. And that's couched in, "And now it's going to take many many more minutes for another unit to get to your patient than the few seconds you'd have saved".
I don't know about gun-permit tests, but people DO fail these kinds of screens. To a large extent failing a test like that would demonstrate how far out-of-touch the test-taker is.
I suppose in this case it might instead just be a formality? And no one has actually ever failed that test?
The tax forms in my country are filled with this second-guessing. For example if it asks how much income you earned from interest, you're supposed to exclude income that you've already paid tax on and exclude some kinds of investment that are asked about separately in another question but they don't explain this so you have to keep tweaking the numbers until the automatic calculation looks right. There's also a question about having "returned to the country" which really confused me when I was travelling back and forth. I had to talk to the helpdesk to discover that "returned" isn't the same as "arrived after having previously left". I might have got some of the wording wrong but that's the gist.
Tests are actually one of the sturdier aspects of Psychology, epistemically speaking. It's one of the areas where reliability is actually testable.
That said improvised psychology is as bad as anything improvised, only people are generally more comfortable improvising it (and indeed commenting on it) without knowledge of their lack of knowledge, as opposed to fields that look more like science such as software engineering.
Model View Controller doesn't really mean anything in 2021. It might have meant something when the term was first coined, but everyone has such different ideas on what it means it's not a useful term anymore.
Until then (and thanks to Smalltalk) it was a composite UI design pattern combining observable and mediator patterns. It was also a recursive pattern, in which the "editor" could itself be a model-view-controller.
Rails designers completely misunderstood it (or deliberately ignored it) and simply reused the terms for something that was only marginally similar, not recursive and was not inherently "active".
Other frameworks adopted Rails' terminology and now we are left with the original pattern having been completely forgotten.
I was once in this position, but decided to continue through with the "right" answer anyway. Even though the interviewer was adamant that he was right (as, of course, was I), we briefly stopped the interview and made some Google searches to get to the truth.
I could ostensibly argue that I got the job not by telling the interviewer what he wanted to hear, but by doubling down on the right answer and showing that I had the capacity to prove it.
I’ve seen people go through the pipeline with “no hires” from interviewers because of small differences of opinion. In your case, I’d wager that the disagreeing interviewers feedback may have just been discarded.
They didn't fully clarify what kind of feedback the interviewer likely ended up giving in the end, though. I'd be curious to know if after they Googled it the interviewer acknowledged he was wrong and the interviewee was right. (I think they're kind of implying that, but it's unclear.)
This is a good lesson in why LC style interviews are so popular. There are generally only one or two correct/optimal answers that an individual could code in 20 minutes. There is limited ambiguity as to the task to be solved for both the interviewer and the interviewee. There is easy calibration across multiple interviewers as a set of boolean progressions points - did they solve the problem? did they need hints? did they present an optimal/correct solution? The edge cases/traps are likewise known to the interviewers for quick calibration.
The alternatives I've see boil down to these trivia style interviews which come down to simply memorizing answers the interviewer deemed important/correct. The most rediculous cases include obscura such as "what would you do if [X debugging tool] stalled [Y application process?" or "what would you do if you saw a server with high IO time?"
There are many versions of correct answer to these, but odds are your interviewer has a specific one in mind. In a real discussion of these events there would likely be back and forth on root cause/severity/solution, but you simply can't have back and forth in an interview situation. The starting impression will always devolve towards "this person doesn't know what they are talking about".
Can't really comment on whether that was the correct way to handle the situation, given that passing the interview was the goal. However, I would have a hard time giving an incorrect answer on purpose. I also consider an interview as an opportunity to learn about the company I'm going to work for, and especially my future colleagues.
I would probably try to give a full answer, such as "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." A technical lead that can't work with an answer like that is one I probably don't want to work with.
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.
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.
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
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.
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 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.
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
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.
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.
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?
This isn't a great example to me. I doubt the interviewers would disagree that the actual code in MVC runs at the "application tier".
I think they were just trying to elicit the idea that the model defines interaction with the database and that the view defines interaction with the browser client. That there is some relation there between MVC and 3-tier architecture. The Wikipedia snippet that disputes any relationship seems overly pedantic to me.
Though all moot to me since there's very little real world pure MVC or pure "3-tier" anyway. For good reason.
Disagree. The difference is fundamental and if you don't know it you are going to be stuck with a false understanding of the framework you're working with - and you will likely end up trying to shove bad abstractions into places where they don't belong, resulting in an unmaintainable mess of code. I have seen this happen in a lot of codebases where people fundamentally misunderstand the abstractions they're building on top of.
I disagree with this. If you believe that one thing "3 tier" means is that the client doesn't interact directly with a database, as the old fat-client -> database model did, then "MVC" was one pattern to accomplish that. So, to me, there is some relationship. Enough of one to have a interview discussion about it.
I do agree that they aren't the same thing, but they are pretty clearly related to me.
The interview question was “How does this architecture relate to the model-view-controller pattern?”
I find it to be pedantic as well. Sure, all of the code exists in the application layer. But that doesn't really tell you anything about it's relationship to the system as a whole does it?
How about we look at vectors of change? Or dependency relationships? You see, in many systems changes[0] to the UI affect changes to the View and changes[1] to the database affect changes to the Model.
[0][1] I don't mean to say the UI changes and then the View is updated to match. I mean that stakeholders will have decided that the UI needs to display different information, so the View is updated to accommodate such a change (which can then be passed to the UI). The same story above for the Model/Database relationship.
> “How does this architecture relate to the model-view-controller pattern?”
It's an ambiguous question.
One answer is that all the mvc code runs on the application layer. This correct in a nearly tautological way (the code is where the code is).
The other answer is how does it relate. The model relates to the database in their three tier example.
Indeed, I think this question definitely implies something other than "where does the mvc code exist?"
I really don't think his answer is even a pedantic one. It's bending over backwards to read a question in a certain way that his preferred clever answer could be considered correct.
Well, no… the correct answer is that MVC and 3-tier are actually orthogonal concepts. And probably the better answer even in his given interview context.
exactly. The author could have gone into the differences between the 2, how they are the same but not really, by choosing the words wisely. He could have made it a non-attack by interjecting "from my experience" or "from what I know" or "the way I usually refer to this" etc. There are no correct answers, since these patterns are never applied in practice in a pure format, pretty much just like the classic design patterns from the GOF. This is a weak example from OP.
The article really rubbed me the wrong way. It feels like the writer was insanely judge mental of interviewer, immediately thinking that he was so much smarter than the guy that he was afraid to embarrass his future boss. All this confirmed by a brief moment if body language? Give me a break.
I do not think I am smarter than anyone else. It's just that some things you know better and other things you don't. I worked with the team lead for several months, and really enjoyed it. He was smart and a very good team lead.
I think you're fine. The GP is just threatened by your everyday social intelligence. It's not that you're superior to him, it's that he feels inferior or lacking compared to you.
As far as I can remember now, I was also not 100% sure about my answer, because I did need to look it up later to confirm that I was right. So maybe I just took the easy road and answered what I knew they wanted to hear.
I guess the real question is what Koen's goal was. Was it to be hired for this particular job? Or was it to get a technically satisfying job?
Personally I'd find it very difficult to knowingly give a wrong answer to a client or potential employer, even if it's clearly the one they want. After all, they're hiring me to find the right answer for them, not to agree with them. That's just me though.
I don't like this kind of interview question because it's all about subjective terminology and superficial knowledge and not about logic or reasoning.
The author is right, the MVC pattern can be considered from many different angles. It's possible to have MVC just on the client side (e.g. with React framework with Redux you have a store as a model, components are views and the router is essentially a controller). React (the library) is itself is also a controller since it handles the DOM diffing and handles the state reactive update mechanism and thus acts as the glue logic between all the views.
I wouldn't want to work for a company with such a rigid view of software development.
It's a sign of seniority when you notice inconsistencies with terminology.
For example, I know some senior developers who had totally different ideas about what is 'unit testing' versus 'integration testing'. Both are valid views because the terminology is still currently ambiguous.
Does unit testing have to only test 1 class in complete isolation (stub out all function calls to dependencies)? Or is it OK to test a class along with its dependencies (no stubbing)? Some developers say that if you include dependencies, then you're testing more than 1 class so it should be called 'integration test', other developers will claim that it's still a unit test with respect to that class - That integration tests must interact with the system from outside via the API (not method calls on a class). Either way, I think that stubbing out dependencies is a bad idea in most cases (aside from mocking I/O calls to external systems like a database) so if I was to accept the definition of a unit test as being without dependencies, then I would very rarely use unit tests... Anyway this shows that even a simple term which is widely known can be the subject of conflicting opinions and it's wrong to criticize people for choosing a definition which doesn't match your own.
Software development doesn't have much global consensus nowadays and part of the problem is that companies are using bad hiring techniques to interview candidates; companies end up forming tribes of like-minded individuals and completely miss all these nuances and these debates.
Its not even superficial knowledge, it's overloaded terminology. MVC as originally formulated came out of Smalltalk and looked more like what we would call MVVM today with smaller controllers. Apple took MVC with iOS and moved it to the opposite extreme with their god-controller objects that knew everything and did everything. Meanwhile what web developers think of as MVC is really the JSP Model-2 architecture where the controller is the entry point to the system which is responsible for coordinating with the models and views to generate a response, where in traditional thick client GUI MVC the view layer is the entry point into the system and the controller sits between the views and the model.
Point being, "What is MVC?" is a very expansive question and I'd be very wary of working for any developer who thought there was one right answer to it.
if i had to give a wrong answer in order to get a job, i would just take another job. I just cant work with close minded people. I can for a while, but not for years. It drains your soul.
I also hate questions that ask you to explain the meaning of a word. I mean, i have no idea what 3 tier arch is. Yet, after looking it up, it's just frontend, backend, datastorage... i know everything about those things.. but the question makes it look like i dont know any of them =/ Personally, i would label this as a failure of the interviewer, but sadly, that's not how reality works.
Why would you want to work for a supervisor who is so prideful they can't stand the fact that there are other people who know more than them? Aside from needing an income of course.
I don't feel this particular example is very strong since MVC is a bit of a loose/spongy term, especially nowadays. But I've been in interviews - on both sides of the table - where the interviewer is just outright incorrect. On several occasions I've needed to defend the candidate as my colleague was protesting something the candidate came up with based on incorrect knowledge. In my experience, this is very common. I'm sure I've been incorrect as an interviewer at times too. I really dislike software job interviews, on either side of the table, this just being one reason.
Humans are important (and also illogical). If we are to work in a team, then we definitely need to factor humans into the equation.
That also means, that when we evaluate the employer, we should try to find out as much as possible about the human culture there. Even if they are all tech whizzes, if the team is broken, the job will be a nightmare.
I was talking to a guy a couple of days ago, about a job he quit after two days.
He noticed that every time the manager walked onto the floor, everyone put their heads down, and avoided eye contact. It was only a matter of time before the manager cut a victim out of the herd, and humiliated them in front of the others.
During the interview, this same manager was a font of friendliness. But on the floor, he was a tyrant.
In my experience, being "right" is no bar to getting the job.
In one case where I was going for a C++ expert job, I got asked a question (that I can't remember now), gave the correct answer, which the interviewer disputed. I asked if they had a copy of TC++PL on hand, which they did, and I pointed out the relevant section. I got the job.
In another case, I was asked something complicated about "const" in C++ (which has a few gotchas), gave the right answer, but was still disputed. I got the job, and on my first day the guy that asked the question came up and apologised to me - he'd read up on it after.
IMHO, telling the truth about technical matters is always best; I might fib a bit about other things.
I've been passed over for a job because I did not recite the right buzzwords (framework names, etc.). Your job in an interview is to please the person across the table from you. Some interviewers are looking for a sharp technical mind unafraid to challenge them. Others view any challenge to what they think is right as a threat.
It get's tricky with ambiguous subjects. If there is a concrete correct answer then yes, give that stick to your guns. If there isn't and the issue comes down to opinion and interpretation ... things get dicy ...
Well, I disagree - people are presumably paying me for my experience and successes, which will affect my opinion and interpretation. If they don't like those, then presumably they don't value my experience, and we would probably not be happy working together.
I think there's a slight confusion here. An opinion should be stated as an opinion and not treated as or claimed to be a fact. If the point in question is stated as an opinion then fine and I'd agree with you. On the other hand, saying that an opinion is the factually one true way is a big red flag on either side.
This behavior selects for good, or at least compatible, coworkers. Of course if you are desperate for a job then you should read the room and say whatever they want to hear, but if the job market for your skill set is strong, you should show your personality and be open about how you approach technical problems (unless you're really an over-the-top asshole, and nobody thinks that about themselves, so it's pointless to give advice for that situation.)
Once in a technical interview I was asked what data structure I would use for certain functionality "if performance was really critical." I said it would depend on the size and structure of the data that we needed to support, and when the interviewer said "unbounded," I said that the answer to that would go beyond an in-memory data structure, and if performance is critical you need to be able to project the sizes of data you need to support in the near future.
I could tell the interviewer thought my answer was ignorant and sloppy. He started giving me a few "hints," which showed that what he wanted was the data structure had the best big-O performance. So I told what the best big-O performance was for the problem and what common data structure would provide it.
Then he said, "So you would use that?" wanting to put the question to rest and move on the the next one, and I could have said yes. But instead I said "maybe," and I told him I remembered Bjarne Stroustrup talking about how algorithms classes in computer science education give students the wrong idea about how software engineers choose data structures and algorithms in practice. The university version, he said, is that if performance isn't critical, you just pick a container with the right functionality, and then if it turns out that performance matters, you pick something with the best possible big-O characteristics to get ideal performance.
In reality (according to Stroustrup), when performance isn't critical, you should pick something with good big-O performance, and if it turns out that performance matters, you measure on realistic hardware with the data sizes and characteristics you need to support, and in many practical performance-critical cases you will end up choosing something with theoretically suboptimal big-O performance.
I told the interviewer I liked Stroustrup's approach, and I always used data structures with known good performance by default, but I would measure if it mattered. I didn't get the job, and that was probably for the best at that stage in my career. I've nevertheless ended up working in situations like that, where people living by ideas I knew well thought I was an idiot for not understanding them, when I really just didn't completely agree with them, and those situations did not end well.
In the Benelux, try to get a job after answering what you really think about Scrum. If the local Scrum Master is present in the interview team you will be
"persona non grata" for the rest of your career...
"One Hacker Way Rational alternative of Agile - Erik Meijer"
> try to get a job after answering what you really think about Scrum.
That's providing an opinion, a very perilous thing.
Scrum can work, and it can also fail spectacularly. Often it just presses forward as well as any other process. By saying, "Scrum is awful" you're positioning yourself against the current trend in many businesses (similarly saying that about DevOps in many places, or DevSecOps if you go to the US gov't or DoD contractor). And since the value of Scrum is so dependent on the people doing the work and how they actually run things there's no universal statement that can be made about it anyways.
So don't, qualify it: I've seen Scrum at a past employer where they insisted on only code-based stories in each Sprint which led to massive technical debt, and eventually the project came to an incredible slowdown as they paid no attention to refactoring or other cleanup tasks until after they were bit by it. If the stories are a mix of maintenance and development stories then it seems to be more successful.
Such a statement is hard to dispute (it's about personal experience) and is non-confrontational (you're not entirely dismissing Scrum but you're not endorsing it either, only offering insight into what seems to be a problem feature and a potential solution). You aren't making yourself stupid, but you're opening up a potential discussion. If the Scrum Master is present you can get into a discussion about their specific process as implemented in their organization. That can give you more useful insight than saying something negative as if it's a universal truth, when it's not.
The headline feels wrong, as the author started by laying out their assumptions, and revised after more or less getting their question answered.
One could just as easily form this as a question.
“All three are usually at the application layer in my experience. Would you like me to discuss this, or give you a more general mapping?”
In either case, asking questions before answering is something any good interviewer should be looking for as a positive signal.
A general knowledge question like this, though, seems designed for a quick answer, so I’d only ask the question if I was really confused rather than splitting hairs.
My first programming job interview (like 100 years ago) was a group interview. One guy asked me to write string compare in C.
Not sure I did it right, but I basically walked the two char* pointers looking for a '0' or a mismatch. The guy asking the question said, "No, first you should compare the string lengths -- since if they have a different length they will be different."
I was nervous, but I thought he was wrong. I said, "Well, to get the length you need to walk both strings, so that isn't faster."
He got annoyed and said, "They have optimized functions for that!"
I didn't argue. Needless to say, I didn't get the job :)
Modern strcmp and strlen both contain optimizations based on modern hardwarae, and I believe strlen can be faster than strcmp, but that's overoptimizing for performance.
This story uses a technical question (MVC vs n-tier) as an example, but conforming your answer to interviewer expectations also applies to behavioral and soft-skill questions (perhaps more so).
There are some traditional corporate HR-screening questions that have flummoxed tech people since forever. Those who are savvy about people-skills in a workspace know instinctively how to answer these questions, but some techies have a very hard time with them because they're either being radically honest or awkwardly trying to second-guess what the interviewer wants to hear.
The best thing you one can do is to practice. Interviewing is a skill (for both sides), it doesn't come naturally to most folks.
408 comments
[ 3.5 ms ] story [ 333 ms ] threadI think it was a poor solution. There are ways to respectfully disagree.
"I really think I'm right on this one. Since it's a question of facts, not opinion, we could easily verify it later."
Did the author know they were hired because they didn't rock the boat, or despite of it?
If I were hiring someone, I would want to know I'm hiring someone who can argue politely for what they think is right, and not see the argument in the context of "winning or losing", but in trying to find the best way forward.
Is it?
I think it's an opinion.
How would you empirically test if the answer was right or wrong? What's on Wikipedia is also someone's opinion, isn't it? What's in a book that Wikipedia references is again someone's opinion.
If you can't write a program or other set of instructions to test it... it's an opinion.
'How does Dr Foo say that MVC maps to database-server-client?' would be a question of fact though.
That said, I don't think I've seen MVC used with the same meaning twice... what makes the question even worse.
Apple's definition of MVC specifically contradicts the Wikipedia definition for MVC that OP gives.
https://developer.apple.com/library/archive/documentation/Ge...
The current Wikipedia content on multitier vs MVC is quite vague.
https://en.wikipedia.org/wiki/Multitier_architecture
I think "correct" is a reach here.
Stock CRUD multitier should not be confused with MVC, nor vice versa.
A company that doesn't understand the differences is a Red Flag.
If you hiring involves ego, you're going to end up with a Challenger disaster some time down the road.
I don't think this should be the default recommended advice. It could just as well cost you the job, if you are interviewed by two people, with the other also knowing what his or her colleague said was wrong, and being disappointed you didn't find a way of politely disagreeing.
In job interviews, I would count it as a positive if I could see that the candidate could handle disagreement. That is in my view more important than getting a rather generic technical question "correct".
"As an analogy, perhaps one could view..."
Two months later when that person runs across the wiki article:
"Ah, right that's why I said as an analogy perhaps one could view it that way. I thought you knew?"
Bear in mind, many TLs are in their current role by virtue of having a good idea, supportive management, trust of their team and good/lucky execution. This combination of activities can easily mean that you have a great up and coming TL with ~3 years of experience. Management may be bringing in more senior talent as the upscaling product requires it, but that doesn't mean you start with the same trust, management support, ideas, or in-house knowledge as the TL.
In such a situation, setting out to prove that you can outsmart the junior TL as your first contribution seems suspect...
Bear in mind that often successful companies, have many inexperienced leaders due to growth.
I don't really care what you currently know because software development paradigms can be learned with relative ease for a motivated and intelligent individual who already knows something.
So instead I:
1) Poke around their CV/Resume. Just ensuring that they have the stuff they say to a basic level (some people just spam keywords)
2) Get them to a point where they admit they don't know something. Usually this means a deep dive on something common to the role I'm hiring for and that they have experience in.
If you're unwilling to say you don't know something I usually reject the candidate. I know interviews are stressful and you want to impress your interviewer, but if you're willing to try to bullshit me at an interview then you're willing to bullshit me in a post-mortem, and I can't have that.
Honesty - Intelligence - Experience
in that order, always.
I remember asking a friend once if he could answer any Tolkien question, and he answered that he couldn’t answer everything, but the stuff he couldn’t answer, I didn’t know the right questions for.
If you don’t understand then they likely don’t understand it enough to explain it.
I'm always hopeful that the person I'm interviewing is more capable than I, and they very often are. But there's an interesting thing: the more expert a person is, the more willing they tend to be to say "I don't know" (often rapidly followed by informed speculation and a comment about how they would find out). Combining that with the fact that true experts usually prefer to operate at the limits of their knowledge means it's not hard to get such a candidate to say "I don't know".
It's certainly not necessary to operate at the same level as a person to get them to operate at the limits of their knowledge and ability. In fact, relatively inexperienced people have a knack for asking those "naive" questions that lead into very deep pools.
Edit: I should also mention that my interview style is not in the form of a quiz. It's a conversation. I think that makes a difference as well.
This is a great cold reading technique that works in magic tricks too.
You have some trick where someone needs to pick from 10 cards. And your patter goes something like "Picture the card in your mind. Ace of hearts. Ace of hearts" If they give a big reaction then you've found their card and performed a miracle. If not then you just continue "Of course, that's just an example..." and continue the patter throwing out other hints. Of course, it's tough to make this your only trick but it can really elevate a good trick to amazing.
Great example at 1.50 here: https://www.youtube.com/watch?v=QI5-NDiY7IM
Wouldn't you have to do this on average five times to get the right one? Wouldn't it be a bit suspicious giving five example cards before arriving at the right one?
(It's Monday. Smile a little.)
Keeping your mouth shut, saying no, and not lying or BSing are three of the most useful skills you can develop. Many people feel pressure to respond quickly, especially in a performance situation like an interview, just as the writer of this article was highly tuned to what his interviewer wanted to hear. Controlling the tempo and direction of your own responses is a way to gain the strategic initiative without being disagreeable.
Just pausing and not answering quickly when given an offer is a power move. I know it consciously but I still find it hard/impossible to do in real life.
Every once in a while, purely by luck, the correct card would be at the top. In which case I would just change the second line to "...but I have brought it to the top of the deck for you". My sister begged me to tell her how I did it for years.
* "Does the author really mean what they are asking? Are the mistakes in the phrasing or corner cases intentional, meant to catch me, test my deep knowledge?", or
* "Is the author just not very good with logic / not thinking this through?"
I go with the latter in "soft social" contexts. Never regretted it yet.
This saved my hide recently in June, when I had to undergo a mandatory psychological examination for my gun license permit. Serious official stuff, with my permit on the line… And the "serious" psy-test was exactly as "robust" you'd expect from the field of psychology.
I answered the way I figured the test author construed the questions (= what they likely meant to ask), not what they actually asked. Easy pass.
I don't remember if the wording was specifically like this, but it was something that to me logically obvious answer is "yes", but the correct answer and what they expect is "no", to show that you are a reasonable driver who won't speed unnecessarily.
And I think throughout the driving exam there were several questions like that. This type of thing really annoys me.
EDIT: I found the actual question - although I still had to translate it - and I think I was giving the question a benefit of the doubt from my memory, with the term "planned" as I had written here, the actual way the question was setup was following:
What affects the duration of a planned journey?
a) Length of the journey.
b) Maximum speed in few lone sections of the journey.
It uses checkboxes, so you can check both.
They expect you to check only a), but b) is in my view also logically correct answer as if at any section even if it's shorter than 1 metres, if your max speed nears 0, duration of your journey will reach infinity. But it is worded in such a way that most people will get the hint that B) should not be checked.
If it were a question only about cars at rest it would be phrased something like "how far behind a car should you stop when queued" or something of that nature.
You can think of it as "it'll take you one second to react and one to brake to a stop, so you should be two seconds away".
I put false without thinking. I had everything else on the test right and part of the course was the instructor reviewing your test and going over your incorrect answers. He wasn’t a programmer (I think former military tbh) and didn’t really understand why I got it wrong even after I explained it…
On a test for a gun license, it could get a little squishy as there are likely questions about the law (which only sometimes aligns with common sense) translated into lay English (which lacks the degree of precision you would likely find in the actual legal phrasing).
From Reddit ELI5:
"Cream or Sugar, in coffee is OR it means one the other or both
Fish or Chicken, for dinner is XOR it means one or the other not both."
https://www.reddit.com/r/explainlikeimfive/comments/4v6dcd/c...
Most cases where "or" is taken to mean xor are actually asking for a choice, expecting one of the options as an answer. If the "or" is part of a question expecting a yes/no answer, then it is much harder to justify it being an xor.
What affects the duration of a planned journey?
a) Length of the journey.
b) Maximum speed in few lone sections of the journey.
It uses checkboxes, so you can check both.
They expect you to check only a), but b) is in my view also logically correct answer as if at any section even if it's shorter than 1 metres, if your max speed nears 0, duration of your journey will reach infinity. But it is worded in such a way that most people will get the hint that B) should not be checked.
"few" and "lone sections". As in statistically irrelevant. The assumption is that people 'get' for example (and its being taught over and over in driving school too) that if you speed to get through one traffic light in the city you'll not make it through the next one anyway and thus not really be faster. On the highway if you only speed once or twice for a short lone section you won't really notice in the end.
You don't even have to come at it with a nerd mathematicians mind and play tricks like Max speed near zero (not a realistic scenario so not something a driving exam would ask but definitely a fun scenario in a math lecture at university maybe). I can think of multiple sections in my city where speeding through the right traffic light when it's "cherry green" will net you a significant advantage because of the awful street and intersection layout and traffic light phases in that area. If you do the same just one traffic light after it though it won't help you at all because the next light will catch you unless you really want to cause an accident.
And if you are driving a 500km+ route and you can "speed" through it at 160+ km/h for a significant portion of it vs. going 120 that will save you a noticeable amount of time on the journey. This assumes something like Germany and your route being in parts with not many speed limits and not too much traffic so that you can comfortably cruise at 160 to 180 vs. arriving as a nervous wreck close to a heart attack because of all the near crashes from slowing down for the grandma going 100 switching to the left lane a few car lengths in front of you.
Something along the lines of "speeding in most urban areas doesn't actually help get someone to their destination faster. There are always multiple traffic lights and other cars to contend with, so it's not helpful to go over the speed limit and it increases the risk and severity of an accident." It's perfectly solid advice, who hasn't been passed aggressively by an ah-ole with tinted windows only to catch up to them at every traffic light?
The question obviously wants to screen for that tidbit of knowledge, but it's not phrased rigorously enough for the HN-crowd, I guess.
The task was to drive from Duesseldorf to Munich. Two identical cars, two very experienced drivers. one was told to go as fast as possible without breaking speed limits on the way (we don't have a general speed limit on the German Autobahn (highway)) tthe oother ro drive at a relaxed 120 km/h were possible and also honor speed limits.
Both were equipped with EEG (heart rate and stuff).
The driving distance is slightly above 600km.
The first drive (as fast as possible) arrived first. Waiting for the relaxed driver to come in second. That happened 20 minutes later. So on a trip of > 5 hours the gain was 20 minutes.
But at what cost. The EEG told a story of pure stress, massive heart rate spikes even for an experienced driver like the one behind the wheel. While the other one came in not only at a relaxed speed but a way more relaxed body and mind.
Medical doctors concluded that the EEG of number two was way more healthy.
Btw: One reason why the first car was only 20 minutes quicker was the fact that the driver had to stop to refuel. This cost him minutes. While the second driver arrived with gas to spare. So even economically it made sense to drive a relaxed style. Not to speak of the ecological aspect.
So to wrap up. The fast driver often comes in first. But not as quick as the feel they are. And at a high price.
In this case you're probably right that the faster driver was just more stressed for no real benefit, but an EEG is not always a good proxy for how "healthy" something is (even ignoring obvious cases like physical exertion).
If you have a link to the study I'd love to read more.
EDIT:
One other thing I missed on the first read of your comment was the fact that the driver was instructed to "drive as fast as possible" and then given access to roads with no speed limits. I feel like that would have the potential to exacerbate the 'negative' side of things and that a more reasonable middle-ground could be found both in terms of driver stress and also fuel economy.
Basically this guy made his scientific career by doing epic experiments where he observed communities of baboons during various social interactions, blow-gunned individual baboons with tranquilizers, then very quickly, took samples of their blood to analyze glucocorticoids (these are stress-response hormones and have a half-life measured in minutes).
Anyway, crudely stated, the major finding is that animals have intense episodic stress throughout their lives but never suffer health consequences from that stress because it's occasional. Humans, on the other hand, can get the same levels of "fight-or-flight" stress but at long-lived, daily intervals. Excessive glucocorticoids, over a long term, can interfere with the normal functioning of the body and precipitate a wide variety of health problems including heart-disease (and ulcers, as the title suggests).
In the case of driving, an aggressive lane-changing drive in a fast car might be exhilarating under certain conditions, but it's a different story for a daily commute. It's no accident that the advice given to people that experience aggressive drivers on the road is often along the lines of "Let him go, don't become a part of his bad day." Aggressive driving is a self-reinforcing bad habit that becomes part of people's identity in many cases. Personally, I don't care about the health of aggressive drivers, but I do care about their propensity to cause accidents and hurt innocent people.
Absolutely agree. I live in a 30km/h zone (regular speed in a city is 50km/h in Germany). And we have speeders every day. While kids are playing and elderly people trying to cross the streets.
What I wanted to say:
I care - and we petitioned the city to at least have marked parking spaces implemented with big flower pots on every side to at least reduce the speed people can go here.
The spikes and reactions were stress reactions measured by medical doctors from the monitoring of multiple signals (heart rate being one).
So they came to the experimental conclusion that (at least in this experiment) driving at the limit of what was possible in terms of speed the car could go and speed traffic would somehow allow was a factor of stress for the driver.
They also qualified the added amount of fuel necessary to drive the distance.
But they did not say one was better, one was worse. They just let the viewer decide on which variant they preferred.
And as I said: If the externalities were priced into taxes and cost of fuel - why not let people and the market decide if it was worth to them to arrive 20 minutes quicker on this distance.
over enough journeys, driving faster will always decrease your average travel time (unless you crash or get pulled over, I guess). the way to discourage people from speeding is not to tell them something obviously wrong, but to discuss the legal/safety risks and the increased gas and brake pad consumption. I understand that I can get places faster by speeding in the city, but I don't do it because, to me at least, the gains are marginal compared to the risk, cost, and stress.
Keep in mind that driving manuals are deliberately written at a 6th to 9th grade reading level depending on the state.
Yes, you're right that the gains from speeding are marginal compared to the risk, cost, and stress. But it's hard to communicate that kind of nuance. If the manual just says lead-foots aren't going to get somewhere faster by speeding to each intersection that's "good enough" and very close to reality for the purpose of the manual. National merit semifinalists can get the queue-theory version from their high-school math/driving instructor during driver's ed.
Is it though? Almost all the knowledge we have is taught using flawed and simplified models that we can niptick and find "obviously wrong" when deeply examined. https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder
And IME, when I'm explaining something, pedantry and specifics almost always get my audience confused more than help to get the point across.
They found that weaving between lanes is faster, but not by very much depending on which lane you're comparing it to. The final result (shown at 3:54 in the link) was:
* Weaving between lanes: 1h 16m
* Lane 1: 1h 19m
* Lane 2: 1h 20m
* Lane 3: 1h 29m
* Lane 4: 1h 33m
Lanes 1 and 2 are close enough I can imagine it being chance and more tests resulting no noticeable difference. And for an over-an-hour drive, it's already no reasonable difference anyway.
If you know the area and traffic patterns you can do that and basically stick to your lane for long periods and just switch a few times. I have something like that on my pre-covid commute for example, where you have to be in the right most lane until between a certain off ramp and the corresponding on ramp. There's always lots of traffic and you go between 10 and maaaybe 40 km/h. There you switch to the leftmost land so that you don't get bogged down by the regular mergers from the on ramp in the right lane and the 'middle lane drivers' who merge into the middle lane right about there too. Then until the next on ramp you stay on the left lane but have to switch over to the right lane again because no trucks allowed on it and most people try to pass on the left lane while everyone else is stuck with middle lane drivers and trucks.
If you know the area in the above example, just choose lane 1 for sanity. If you don't know the area and happen to stick to lane 4,id rather try weaving to be honest.
But it does slow your reaction time, and it does massively increase your accident risk. And that's couched in, "And now it's going to take many many more minutes for another unit to get to your patient than the few seconds you'd have saved".
The free-response question was something like: “What is the single most important thing you can do to improve your safety as a driver?”
I answered: “Always drive sober.”
The “correct” answer was: “Fasten your seatbelt.”
I can only imagine the grader’s face / thoughts when they had to mark my answer as incorrect.
I suppose in this case it might instead just be a formality? And no one has actually ever failed that test?
A vendor offers you season tickets to the Cubs games. Are you allowed to accept?
1) Yes, because neither of you are in the baseball business.
2) No, not under any circumstances.
3) Yes, if you give the tickets to someone else, such as your brother-in-law.
The "right answer" was quite obvious, making it more of an intelligence test than an ethics test.
That said improvised psychology is as bad as anything improvised, only people are generally more comfortable improvising it (and indeed commenting on it) without knowledge of their lack of knowledge, as opposed to fields that look more like science such as software engineering.
Until then (and thanks to Smalltalk) it was a composite UI design pattern combining observable and mediator patterns. It was also a recursive pattern, in which the "editor" could itself be a model-view-controller.
Rails designers completely misunderstood it (or deliberately ignored it) and simply reused the terms for something that was only marginally similar, not recursive and was not inherently "active".
Other frameworks adopted Rails' terminology and now we are left with the original pattern having been completely forgotten.
I could ostensibly argue that I got the job not by telling the interviewer what he wanted to hear, but by doubling down on the right answer and showing that I had the capacity to prove it.
The alternatives I've see boil down to these trivia style interviews which come down to simply memorizing answers the interviewer deemed important/correct. The most rediculous cases include obscura such as "what would you do if [X debugging tool] stalled [Y application process?" or "what would you do if you saw a server with high IO time?"
There are many versions of correct answer to these, but odds are your interviewer has a specific one in mind. In a real discussion of these events there would likely be back and forth on root cause/severity/solution, but you simply can't have back and forth in an interview situation. The starting impression will always devolve towards "this person doesn't know what they are talking about".
I would probably try to give a full answer, such as "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." A technical lead that can't work with an answer like that is one I probably don't want to work with.
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.
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.
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.
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.
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.
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.
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 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
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.
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.
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.
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.
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.
Why not say "there are many similarities and some differences, they're similar in these ways..."
I think they were just trying to elicit the idea that the model defines interaction with the database and that the view defines interaction with the browser client. That there is some relation there between MVC and 3-tier architecture. The Wikipedia snippet that disputes any relationship seems overly pedantic to me.
Though all moot to me since there's very little real world pure MVC or pure "3-tier" anyway. For good reason.
I do agree that they aren't the same thing, but they are pretty clearly related to me.
The interview question was “How does this architecture relate to the model-view-controller pattern?”
How about we look at vectors of change? Or dependency relationships? You see, in many systems changes[0] to the UI affect changes to the View and changes[1] to the database affect changes to the Model.
[0][1] I don't mean to say the UI changes and then the View is updated to match. I mean that stakeholders will have decided that the UI needs to display different information, so the View is updated to accommodate such a change (which can then be passed to the UI). The same story above for the Model/Database relationship.
It's an ambiguous question.
One answer is that all the mvc code runs on the application layer. This correct in a nearly tautological way (the code is where the code is).
The other answer is how does it relate. The model relates to the database in their three tier example.
Indeed, I think this question definitely implies something other than "where does the mvc code exist?"
I really don't think his answer is even a pedantic one. It's bending over backwards to read a question in a certain way that his preferred clever answer could be considered correct.
Sorry if my article gave you a wrong vibe.
"There are two views on this. Some people say x, but I would argue that the better view is y."
Giving the wrong answer intentionally is both dishonest - never a quality I would want to have, especially in an interview - and liable to backfire.
Personally I'd find it very difficult to knowingly give a wrong answer to a client or potential employer, even if it's clearly the one they want. After all, they're hiring me to find the right answer for them, not to agree with them. That's just me though.
The author is right, the MVC pattern can be considered from many different angles. It's possible to have MVC just on the client side (e.g. with React framework with Redux you have a store as a model, components are views and the router is essentially a controller). React (the library) is itself is also a controller since it handles the DOM diffing and handles the state reactive update mechanism and thus acts as the glue logic between all the views.
I wouldn't want to work for a company with such a rigid view of software development.
It's a sign of seniority when you notice inconsistencies with terminology.
For example, I know some senior developers who had totally different ideas about what is 'unit testing' versus 'integration testing'. Both are valid views because the terminology is still currently ambiguous.
Does unit testing have to only test 1 class in complete isolation (stub out all function calls to dependencies)? Or is it OK to test a class along with its dependencies (no stubbing)? Some developers say that if you include dependencies, then you're testing more than 1 class so it should be called 'integration test', other developers will claim that it's still a unit test with respect to that class - That integration tests must interact with the system from outside via the API (not method calls on a class). Either way, I think that stubbing out dependencies is a bad idea in most cases (aside from mocking I/O calls to external systems like a database) so if I was to accept the definition of a unit test as being without dependencies, then I would very rarely use unit tests... Anyway this shows that even a simple term which is widely known can be the subject of conflicting opinions and it's wrong to criticize people for choosing a definition which doesn't match your own.
Software development doesn't have much global consensus nowadays and part of the problem is that companies are using bad hiring techniques to interview candidates; companies end up forming tribes of like-minded individuals and completely miss all these nuances and these debates.
Point being, "What is MVC?" is a very expansive question and I'd be very wary of working for any developer who thought there was one right answer to it.
I also hate questions that ask you to explain the meaning of a word. I mean, i have no idea what 3 tier arch is. Yet, after looking it up, it's just frontend, backend, datastorage... i know everything about those things.. but the question makes it look like i dont know any of them =/ Personally, i would label this as a failure of the interviewer, but sadly, that's not how reality works.
No other topic in our design pattern study group would incite such heated debates.
Any more, any time someone refers to MVC, non ironically, I just mentally check out. Bozo bit style.
Humans are important (and also illogical). If we are to work in a team, then we definitely need to factor humans into the equation.
That also means, that when we evaluate the employer, we should try to find out as much as possible about the human culture there. Even if they are all tech whizzes, if the team is broken, the job will be a nightmare.
I was talking to a guy a couple of days ago, about a job he quit after two days.
He noticed that every time the manager walked onto the floor, everyone put their heads down, and avoided eye contact. It was only a matter of time before the manager cut a victim out of the herd, and humiliated them in front of the others.
During the interview, this same manager was a font of friendliness. But on the floor, he was a tyrant.
In one case where I was going for a C++ expert job, I got asked a question (that I can't remember now), gave the correct answer, which the interviewer disputed. I asked if they had a copy of TC++PL on hand, which they did, and I pointed out the relevant section. I got the job.
In another case, I was asked something complicated about "const" in C++ (which has a few gotchas), gave the right answer, but was still disputed. I got the job, and on my first day the guy that asked the question came up and apologised to me - he'd read up on it after.
IMHO, telling the truth about technical matters is always best; I might fib a bit about other things.
I've been passed over for a job because I did not recite the right buzzwords (framework names, etc.). Your job in an interview is to please the person across the table from you. Some interviewers are looking for a sharp technical mind unafraid to challenge them. Others view any challenge to what they think is right as a threat.
And people like that are those you want to work with.
> Others view any challenge to what they think is right as a threat.
And those you don't.
Otherwise, I'd agree with your stance completely.
Once in a technical interview I was asked what data structure I would use for certain functionality "if performance was really critical." I said it would depend on the size and structure of the data that we needed to support, and when the interviewer said "unbounded," I said that the answer to that would go beyond an in-memory data structure, and if performance is critical you need to be able to project the sizes of data you need to support in the near future.
I could tell the interviewer thought my answer was ignorant and sloppy. He started giving me a few "hints," which showed that what he wanted was the data structure had the best big-O performance. So I told what the best big-O performance was for the problem and what common data structure would provide it.
Then he said, "So you would use that?" wanting to put the question to rest and move on the the next one, and I could have said yes. But instead I said "maybe," and I told him I remembered Bjarne Stroustrup talking about how algorithms classes in computer science education give students the wrong idea about how software engineers choose data structures and algorithms in practice. The university version, he said, is that if performance isn't critical, you just pick a container with the right functionality, and then if it turns out that performance matters, you pick something with the best possible big-O characteristics to get ideal performance.
In reality (according to Stroustrup), when performance isn't critical, you should pick something with good big-O performance, and if it turns out that performance matters, you measure on realistic hardware with the data sizes and characteristics you need to support, and in many practical performance-critical cases you will end up choosing something with theoretically suboptimal big-O performance.
I told the interviewer I liked Stroustrup's approach, and I always used data structures with known good performance by default, but I would measure if it mattered. I didn't get the job, and that was probably for the best at that stage in my career. I've nevertheless ended up working in situations like that, where people living by ideas I knew well thought I was an idiot for not understanding them, when I really just didn't completely agree with them, and those situations did not end well.
"One Hacker Way Rational alternative of Agile - Erik Meijer"
https://youtu.be/2u0sNRO-QKQ
Nowadays a Developer has to act a little bit like in this scene from Good Will Hunting.
Make yourself stupid...you will be hired.
https://youtu.be/UpL3ncoK99U
That's providing an opinion, a very perilous thing.
Scrum can work, and it can also fail spectacularly. Often it just presses forward as well as any other process. By saying, "Scrum is awful" you're positioning yourself against the current trend in many businesses (similarly saying that about DevOps in many places, or DevSecOps if you go to the US gov't or DoD contractor). And since the value of Scrum is so dependent on the people doing the work and how they actually run things there's no universal statement that can be made about it anyways.
So don't, qualify it: I've seen Scrum at a past employer where they insisted on only code-based stories in each Sprint which led to massive technical debt, and eventually the project came to an incredible slowdown as they paid no attention to refactoring or other cleanup tasks until after they were bit by it. If the stories are a mix of maintenance and development stories then it seems to be more successful.
Such a statement is hard to dispute (it's about personal experience) and is non-confrontational (you're not entirely dismissing Scrum but you're not endorsing it either, only offering insight into what seems to be a problem feature and a potential solution). You aren't making yourself stupid, but you're opening up a potential discussion. If the Scrum Master is present you can get into a discussion about their specific process as implemented in their organization. That can give you more useful insight than saying something negative as if it's a universal truth, when it's not.
"That term/phrase is actually used in a couple of different ways. Originally it referred to X But it's sometimes also used to mean Y"
One could just as easily form this as a question.
“All three are usually at the application layer in my experience. Would you like me to discuss this, or give you a more general mapping?”
In either case, asking questions before answering is something any good interviewer should be looking for as a positive signal.
A general knowledge question like this, though, seems designed for a quick answer, so I’d only ask the question if I was really confused rather than splitting hairs.
Not sure I did it right, but I basically walked the two char* pointers looking for a '0' or a mismatch. The guy asking the question said, "No, first you should compare the string lengths -- since if they have a different length they will be different."
I was nervous, but I thought he was wrong. I said, "Well, to get the length you need to walk both strings, so that isn't faster."
He got annoyed and said, "They have optimized functions for that!"
I didn't argue. Needless to say, I didn't get the job :)
There are some traditional corporate HR-screening questions that have flummoxed tech people since forever. Those who are savvy about people-skills in a workspace know instinctively how to answer these questions, but some techies have a very hard time with them because they're either being radically honest or awkwardly trying to second-guess what the interviewer wants to hear.
The best thing you one can do is to practice. Interviewing is a skill (for both sides), it doesn't come naturally to most folks.