Side topic, I think the question "give me an example of when you resolved a difficult challenge at work" and the like is the most bullshit part of job interviews.
Bullshit questions get bullshit answers. Majority of people bullshit their answers on that type of questions. Pretty much majority of the job interview coach tells us to bullshit anyway, or embellish our mini accomplishments to the point it is not distinguishable from bullshit, and say "hey it is not lying". Sure, but the answer is worthless anyway and don't tell anything about a candidate.
You can turn this question into BS, and provide a BS answer, but the correct way to respond is not to focus on the scenario (there are only a few themes anyway) but use it as an opportunity to share your values, perspective and strategy. This says a lot about the candidate, especially if the resolution failed. Even if you think LC is more representative of the type of work you'll end up doing, it's probably not assigned in discrete packages every day for you to complete; there's a lot of the softer "difficult challenge" stuff around it. If you're only optimizing for LC you're tackling the part of the job that will be commoditized by a global workforce and even machines first.
The problem is, if I would share my true personal values, true personal perspective and true personal strategy, I become vulnerable and I open a discussion that I cannot expect to end well. Thus, instead I share my "business" values, which is to say bullshit, because they are in a quite different ballpark than my actual values.
Of course the problem can be instantly solved by changing the definition of the word "problem" to exclude the mental and moral hassle of maintaining two complete personas. (`s/hassle/amazing opportunity/`) At which point business-you can honestly talk about your business-values, and private-you about your separate private-values.
Certainly I can't bring up my penchant for unionization in a job interview, nor would I dare bring up my values as an ethnic minority: I don't want to face avoidable prejudice.
Except there are companies/roles where those values would be just fine if not desired.
The assumption that all gigs have a rigid culture they're selecting for and programming for is defeatist.
If those things are your values -- and not just contrarion reactions -- why would you hide and compromise them instead of finding a role that matches who you are and what you want in the world? It's not often entire industries are privileged enough to behave this way, but it has certainly been the case with SWEs
There are no companies where union values are desired by management, and there are no companies where ethnic minorities are free from discrimination (although there's always nepotism, but that's hardly a sustainable economic practice.)
I thought it was common knowledge that "all gigs have a rigid culture they're selecting for." I am confused and surprised by your assertion that the status quo is otherwise.
Again, "finding a role that matches who you are" is easier said than done for most people on earth. Perhaps you've lucked into a privileged identity in a region of relatively greater social mobility. (I certainly have, but not without limit, and that is why I dare not risk "bringing my whole self to work" and must, instead, compromise. But, then again, why should we tolerate "whole selves" at work? If you've an obsessive penchant for matchbox cars — frankly, you can leave that at home as far as I'm concerned.)
The status quo is as you say, but that doesn't mean pro-union companies don't exist. They're generally called coops. They exist in practically all industries, and the most prominent example is likely the Mondragon Corporation of Spain.
Your cynicism is understandable. The thought that there's nothing to be done isn't. While luck is a factor in all things, many of my privileges come from not accepting that I can't have them.
If I was applying at let's say Enron or [REDACTED], I wouldn't exactly be comfortable giving my opinion of their business model according to my values. I mean, that's why I don't work at any of the [REDACTED] companies, but to each their own.
I am cursed to be about eight-ten years ahead of the industry on development philosophy. Half the stuff I was begging people to do in 2005 was de rigeur by 2015. People who are trying to catch up with the last things they weren’t early adopters for don’t want to hear about the next three things after.
And they sure as hell don’t want to hear about how much of our difficulties with software come down to self delusion and misplaced optimism. Or how that new tech is old tech with a coat of paint and how it only lasted four years last time.
I don’t often win this argument until after something really bad happens and everyone is looking for a deathbed conversion. Until then I’m just some weirdo street preacher. So no, I’m not going to share all of my opinions with people I just met. Unless I’m specifically trying to fuck with them.
I’m very relieved that we have finally seen the sense in about 75% of the stuff Kent Beck wrote down in ‘99. Not that he invented most of those things, because a lot of them were done somewhere in isolation in the 80’s but more seeing the complimentary nature. That doing 6 things could be 8 times as good as doing none of them. When the refactoring book came out some of us said, “oh yeah, so that’s what you call that” and half the people said “that’s the dumbest thing I’ve ever seen, why would I ever waste my time doing that?” I still meet people like this, but many try to keep it to themselves.
Kanban seemed so intuitive that I accidentally made a kanban board in 1995, when the only thing I knew about Japan was tiny trees.
But really the biggest thing for me was that I was poorly served by the education system and spent my first few years thinking there was something wrong with me instead of something wrong with them, so you ten I was having introspective conversations with myself and by twelve overhearing other frustrated learners and interjecting things like, “yeah that didn’t make sense to me at all until I thought of it this way”.
The teachers who say they learn as much as their students aren’t lying (or at least not all of them). Watching - actually watching- people struggle with things teaches you a lot about that thing, that person, and people in general (problem solving and task management). Being able to take a proposed solution and extrapolate on whether this will help or hurt a lot of people. Most only get as far as whether it’ll be awesome for them or horrible, and sometimes they’re wrong.
What’s difficult though is that you see is that what people think they know and how they know it is usually wrong, for better and for worse. Most people aren’t open to hearing that until they are well and truly stuck. There are people who make their whole life about helping people with this. One of the advantages they have is that they are not personally invested in your experience, because they aren’t sharing in it. Whereas your coworkers are either stuck in it with you, or seen as distant and uncaring because they aren’t getting upset too.
There was a conversation the other day where someone asserted that CI/CD was new to us all ten years ago and a few of us said, well no actually it’s been closer to 20.
Sounds like you've an abrasive personality. With emotional intelligence as lacking as yours, it's no wonder you think you've figured out the next three generations of cutting edge technology — you've left many requirements on the floor!
Try solving for problems as though other people actually have rich internal lives (and that their ostensibly petty hangups actually matter), and you'll discover that the technology industry is much more difficult than you think.
Well if that ain’t the voice of experience then I don’t know what is.
Most of what makes Scrum successful today is that they are doing half of XP, and not necessarily calling that out. Kent Beck published the first XP book in 1999, and people were still arguing - energetically - about adopting aspects of that book in 2010.
Google’s secret sauce was based on an algorithm that was 28 years old at that point (and yet never came up in any of my classes).
It’s not invention that limits us. It’s adoption.
Howard Aiken clearly understood this:
Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats.
You really missed the point there.
Being ahead of your time isn't a compliment. It's a failure to find the meaningful connective tissue between where people are and where you want them to be.
It's good to set an ambitious north star - far beyond what people think is realistic or possible. But then you actually have to help them get there, both technologically, and psychologically.
Otherwise, you might as well be waiting around for teleportation to become a reality and then claim "I've been begging people to teleport to save time since 2005, but they just weren't listening".
Of course this is not required. Most people don't do this, and are able to have a happy and productive career not moving the state of the art forward, but just following what's already out there.
But you don't get to claim both being a brilliant innovator ahead of the curve, misunderstood in your time, if you're not able to convince anyone of your vision.
Back to your original post: It's totally OK to have different personal values and business values, unless you're a founder/CEO, at which point those become one and the same. Every company has it's own set of distinct business values (likely influenced by THEIR founder/CEO). So long as you're an employee, you can figure out how you can adapt your values to the needs of the company (or try - maybe successfully, but probably not - to change theirs).
It's not a failure to recognize that you prioritize different values in different circumstances. It doesn't make you dishonest, any more than it makes you dishonest by behaving socially one way with your friends of 20 years, and a different way at dinner the first time you meet a girlfriend's parents.
Problem is that the question optimizes to hire the most toxic of people: great social skills but no morals. You are probably better off not asking it at all, every such hire will destroy parts of your culture and make it look like it was someone else's fault making them harder to fire than any other kind of toxic employee.
It's called a behavioral question.[1] Many interviewers do it wrong. I even had a "job coach" swear to me that it was ok to ask hypothetical questions. So it may seem like BS because your interviewers don't know what they're doing.
It's not possible to detect skilled liars with these questions, so if you're one of those, answer however you like. If you're one of the rest of us, tell an actual story about you - the point is to get to know you.
Also, use the STAR method[2]. Some interviewers look for those explicit steps. And some interviewers don't know what to look for, so it can help for you to be explicit about each of those stages by name.
Side topic, I think the question "give me an example of when you resolved a difficult challenge at work" and the like is the most bullshit part of job interviews.
Only for boring jobs.
For interesting jobs, such questions offer the interviewer a chance to assess the candidate's sense of perspective (low level, architectural, maintenance, operations, security, efficiency, management bottom line, etc.), reason (often mutually conflicting cross-domain priorities), articulation, honesty/openness, reflectiveness (re. benefit-of-hindsight), and so forth.
And as such, this type of open question allowing one to draw from past challenges should be a gem for a good candidate in the right context.
As an interviewer, I take these as an opportunity to really drill down into their experience. If they actually did the thing they are taking credit for, they will be able to talk about it in great detail. For more advanced candidates, it also provides a springboard to assess their ability to identify tradeoffs (Why didn’t you do it this way? If you had to do it again would you change anything?)
But it does require more effort for the interviewer. Surprisingly, many candidates are blindsided by the (well-advertised) behavioral questions which I don’t understand. Or they fail to contextualize anything.
I don't ask this question a lot, but when I did, it was mostly as a nice starter to get started on a drill-down interview on that specific topic. The candidate is giving me the topic, and I would just dig into it and ask them to describe their approach and how it would change given certain constraints. Being able to lay out options in a mece-way (mutually exclusive and completely exhaustive) comes handy.
I believe it's also a very difficult exercise if you didn't experienced the problem solving yourself.
I disagree. The answers to these situational questions say a lot about a candidate, and their importance is often underestimated by inexperienced interviewers, IMO.
In this specific question, a few things I'd be looking for are:
* Was the candidate proactive in resolving the challenge? Many people just complain when they run into hard problems and expect someone else to pick up the slack.
* Did the candidate learn something, or step outside of their comfort zone? This could be as technical as "I had to learn how this legacy codebase's build scripts worked" or "I had to research postgres' MVCC implementation" to something as nontechnical as "I had to schedule a meeting across 10 different departments and get agreement on changing an internal process."
Coding challenges are just one piece of the puzzle. I've previously made hires who were great at the coding part but gave weak answers to situational questions and they ended up not working out; they were excellent coders but would never really push anything forward beyond whatever tickets were assigned to them. By that I don't mean "they didn't work 60 hours a week," I mean that they never wanted to take the time to think about the current state of how things were done and come up with ways to improve the situation. This type of developer would probably be fine in a larger organization, but when you're hiring a senior dev for your 20-person startup, a hire like this can be a disaster.
I think OP point is that everyone a bit skilled at interviewing knows what you are looking for in the answer and will craft you a solid retelling of something which didn’t actually happen.
Don’t get me wrong it’s a good skill to have. You want people who understand what’s expected of them and can craft you a solid story. It’s just that there is better question to ask if you want to test for that.
> "I had to schedule a meeting across 10 different departments and get agreement on changing an internal process."
That’s a good exemple. I don’t interview developers but I have seen similar situations happen in plenty of interviews. You are telling me you have the pull to get a large cross-departments meeting organised and enough political savviness to get internal policy changed but are now interviewing to be a developer. I would find that strange and have a ton of follow-up questions.
> and will craft you a solid retelling of something which didn’t actually happen.
A story about anything that did really happen would disclose information of/about the current/former employer. A story about anything made up would put the current/former employer in the wrong light.
Is it possible to answer any questions that demand a story at all?
Unless you signed a far more comprehensive NDA that the one I have seen until know, you can disclose enough information about your current employer to tell this kind of story.
All that can easily be bullshitted a hundred times easier than any leetcode-style question. I am not saying "just use technical questions" but you are extremely naive as a interviewer if you dont think candidates will MASSIVELY overstate the importance and magnitude of their accomplishments. Hell, politicians do it all the time, we can notice that they are lying and they still do it. My experience indicates the better you are at this (there is a grayzone between outright lying and exaggerating) the better you will do, specially in big organizations when you can "hide" behind lawyers of bureaucracy and other employees.
I don't think there are only two alternatives: "bullshit" questions or Leetcode. For example, you can ask the interviewee to review code, design a system with them, or ask them to describe, in detail, the technical aspects of a project that they worked on. I think these are less prone to bullshit answers but are not as contrived as Leetcode (though I do think Leetcode has its place).
That was my expectation when I started interviewing candidates for a post, but I was surprised to find that most of the candidates didn’t seem to have that one prepared. It really seemed they honestly struggled and had to meditate the question. (They were very technical people and were expecting technical questions)
I think that anyone who’s been around the block in an operations or customer support role in a tech company will likely have some really good answers to that sort of question. If someone asked me that question, I’d probably start with “oh boy, where to start!” before bringing back memories of production incidents.
You can convince a candidate to do a full day of interviews, but every individual interview would be at most 1 hour.
Accounting for introductions, and giving THEM a chance to ask questions leaves you 45-50 minutes.
Oh and you probably want to do a technical question to ensure the candidate is not a "talker" fraud, like a toy programming problem or a system design, so budget 25 minutes for that. You have 25 left, max.
Just how many different stories of "a difficult challenge at work" can you get in 25 minutes? (With context, background, follow-ups, and clarifications?).
My guess is 3-4 max. Which is still fairly good and maybe better than 1. But it's certainly nowhere close to 17.
This fact was a minor irritation to me until someone pointed out the ways you can discriminate against people with these processes. We really do need to be better about these arbitrary interview techniques. The off the cuff stuff tends to be very biased, and it takes a long time for most of us to notice that maybe hiring ten people who think exactly like I do was not my smartest decision. If indeed they ever work it out at all.
Bullshit questions get bullshit answers. Majority of people bullshit their answers on that type of questions. Pretty much majority of the job interview coach tells us to bullshit anyway, or embellish our mini accomplishments to the point it is not distinguishable from bullshit, and say "hey it is not lying". Sure, but the answer is worthless anyway and don't tell anything about a candidate.
I'd take Leetcode any day.