I'd like to offer a spin on this.
In my experience, asking a question that demands one to recall specific details about a painful event in an interview, which is typically a stressful situation, may produce poor results.
What do you think about giving the candidate an opportunity to get advance notice of that you'll be asking that question, in an interview, and ask them to prepare three to five bullet points to discuss? Whether the candidate sends the bullet points back to you before the interview, or just brings them to the interview, is beyond the scope of what I'm proposing.
Let's say your trying to assess a 3 things:
* Has Architect been through the meat grinder at all? Bullet points with little depth log a warning, as there has been plenty of time to prepare a thoughtful answer.
* Does Architect talk about failure in a calm and composed manner? Bullet points give ability to ability to recall challenges before stress of interview sets in.
Does Architect trash talk former employer or coworkers? The stress of interview can erode one's asshole filter, and cause them to be a bit of the jerk they've worked really hard to not be (speaking a bit for myself here).
To wrap this up, I like interview questions that are functional with minimal side effects, meaning the person is given every opportunity to provide the answer you are looking without external pressure or distraction. If you want to see how a person handles stress, give them a situation that is stressful in a way it'd be on the job, perhaps leading with "apologies in advance for the following situation, which is intentionally stressful..."
People tend to slide into a comfort zone and open up a bit about their successes. They then -tend- to stay open and offer up useful insights into their past behaviors under pressure. I've found that it helps to ask the "success" question first, then ask the "failure" question second, rather than directly asking about someone's failures.
As an aside, the technique outlined above is something taken from "Influence: The Psychology of Persuasion," [1] and is a useful read to recognize situations where someone might be using certain techniques to influence the outcome of a situation. :-) Also - note that the general prompt above expects someone to answer in the "STAR" technique. [2]
[1] https://www.amazon.com/gp/product/B002BD2UUC/
[2] https://careerservices.wayne.edu/behavioralinterviewinfo.pdf
Depends on the level you want to interview for. For a higher-level position, I don't think it's unreasonable to rely on someone's communication and presentation skills to adapt on the fly. Explicitly tell them that they can take a minute to think about it, rather than having to have an instant response.
Now, I do my level best to make interviews unstressful. I don't think a stressed candidate is going to do their best, or be their best. They're going to be second-guessing their answers.
That's the point of war stories. Every experienced candidate has them. We've all done memorable things in our career, both good and bad. If it sticks with you, the details aren't what matter.
edit: This goes both ways. I expect the war stories to be an exchange, a patter. They should be learning about me and my co-interviewers as well. And, as someone who gets interviewed, if I feel the interview is completely one-sided and not revealing anything about potential colleagues and the working environment, I'm going to hesitate.
Me, I'm always good for that kind of conversation. It's not going to stress me out if they're asking me things like this.
To some extent, yes. But the flip side is that for candidates that have had negative experiences in poorly managed environments (i.e. negative experience with past employers) this allows them to vent this information in a somewhat more clinical (neutral) way.
Stressful and painful are not the same. Every engineer is going to go through stressful situations. Good ones will learn from them: to minimize the risk of them happening, and to better cope when they do.
> If you want to see how a person handles stress, give them a situation that is stressful in a way it'd be on the job
How is this any better?
> "apologies in advance for the following situation, which is intentionally stressful..."
Stressful situations don't send calendar invites.
I'm not arguing one should be an asshole during the interview. I've been interviewed by clearly hostile engineers. I didn't like it, and it surely impacted my performance. But real life is like that. Being able to react in a polite and composed manner to an unexpected situation, and recover from it, is a superb data point in an interview.
Mainly because you're paying someone to do a job, not to interview. I've interviewed a lot of people, and sometimes interviewing just sucks for reasons that have nothing to do with the interview.
For example, say you're homeless, and you get your first interview in quite a while. Landing the job means housing for you. The pressure to perform is enormous, and it's not something you can prepare for. I was homeless for a bit, and in that situation.
I don't expect to get a job for which I'm not qualified, but it'd be nice if an interview process allows me to show I can meet the requirements of the position, regardless of the circumstances of my life situation outside of work.
I like screening people in for the right reasons, and not screen them out for reasons that aren't really all that important. And when you have a hard time getting any qualified applicants, can you really afford to false negatives?
I agree, having someone be clearly hostile to you during an interview (which is often the first impression of what the culture at a particular company is like) is a great data point for the decision on whether to continue with the process of interviewing there.
I've been doing this and advocating for the practice for years. What is with the "gotcha" interview?
[EDIT] remove word that didn't need to be there.
There are many failure modes other than "death march". I'd be shocked if an architect doesn't have at least one good answer to "talk about a project that went badly". Or, failing that, "almost went badly".
> I absolutely would not hire an architect who's never done a death march
An architect role isn't just a technical role. It's a leadership role. An architect who cracks under pressure easily is a liability for the entire team. If someone has never had to work when they know they're going to lose, they have no experience with it, and don't know what to do when it happens.
> "Can you talk about a project you experienced that went very badly?"
And that question, as phrased, seems quite reasonable to ask any prospective architect. The answer tells you quite a bit about how they handled themselves, how they worked with their team, how they talk about their project and team, and how they diagnosed and addressed the situation.
I agree that death marches are counterproductive. However, if you've been around long enough you've run across situations where they are unfortunately necessary. Another example: production goes down Friday at 5pm. Do you say "we'll pick this up Monday morning"? No... it's all hands on deck to get production back up working as long as it takes, assuming your company isn't large enough to have its own dedicated 24/7 incident response team. Hopefully there's a lot of process and automation which helps to minimize the effort, and if not that's a great takeaway to improving the process down the road.
So then the question is actually asking, "have you ever worked at a company that was two weeks away from complete failure and bankruptcy?"
> Another example: production goes down Friday at 5pm.
While highly stressful, this is not what a death march is.
> A lot of hard deadlines are made up.
Yes, but not all of them are. A lot of my clients face legislative deadlines that don't take developer comfort or work-life balance into account. We need to help them ship X by January Y. It's rare that overtime happens but it has happened and there's little you can do to get around it when a bill is signed into law mandating you do something in 30 days or the state becomes a litigation target.
The worst death march I was ever on was against a legislative deadline. Oh god, may I never do that again.
This also happened to be during a hiring freeze, so no new contractors, no temp employees, nothing. Current team of half a dozen or so had to drop everything they were doing, switch over to this project and work ~12 hour days six days a week just to deliver a mostly-broken implementation right at the deadline and spend another week and a half at the same schedule fixing bugs and other issues.
It would have been much worse if the timelines were extended, if it was 6 months worth of work to be done in 90 days I think the team probably would have quit. They were mostly contractors so paid hourly, so they got paid for all the work, but that's still a lot of hours for that many weeks in a row.
I have been very lucky not to come across anything like that yet.
How do you align this with the "don't talk shit about previous employers" rule?
One of my most difficult experiences was the very last day on a job, when an "Everything is going to crash in four hours if you don't fix this and you were the last person to touch the code" bug appeared (we would have run out of disk space). It turned out the bug wasn't mine - it had been latent in the code for years, caused by the difference between NULL and 0 in a C pointer. The changes I had made just made it visible. Terrifying, stressful, and I'm kind of proud I was able to resolve it under such stress.
See? Terrible situation, not a single bad thing to say about my employer, my co-workers, or my own work. And none of those were actually the root cause of the problem.
What? In C pointers, `NULL` is equivalent to `(void *) 0`, is it not?
Were you compiling in a debug mode where your compiler reinterprets NULL as a bad pointer value other than literal 0?
Technical detail in this case... we were creating rows with a BLOB column in Sybase. If you passed in NULL, Sybase did not allocate space for the blob. But if you passed in 0, it allocated 8k.
We had been storing data in the blobs, in the dozens-to-hundreds of k size range. Sometimes we didn't store data in a row, but mostly we did. The data got moved to the filesystem, resulting in a huge performance boost. Because we pulled the blobs out of Sybase, we massively downsized the databases, to about 10% of their original size - which was still a few times larger than what was needed for an entire production season (about three months of data).
Now, this is where I badmouth co-workers... I had argued strenuously for removing that BLOB column completely, as it smelled wrong to me to leave it. But the tech lead, a rather nervous man who was always afraid of things breaking unexpectedly, insisted we leave it there, because removing it might break something else (I wouldn't be introduced to the Lava Flow Antipattern until years later...) (also, welcome to the world of coding in C without testing frameworks).
The code worked fine in testing. Beautifully. But testing couldn't even fill 1% of a database. The wasted space from the BLOB allocation was invisible... until production started, and rows were 100 times larger than they should have been on our biggest table. Oops.
Thankfully, Sybase has excellent documentation. The gleaming row of carefully indexed, spiral-bound manuals helped me find detailed example code quicky, which got me to the latent bug. We'd never noticed the 8k being allocated for empty blobs before because they were swamped by the size of the actual blobs.
Hmmm, no, sorry. `NULL` is #defined as `((void )0)`. There is no 99% or other probability involved.
Sorry to be so pedantic as it's kind of an aside to the discussion at hand. I thought perhaps you knew something about NULL in C that I never knew and was eager to be enlightened.
I think you're conflating C pointer `NULL` with the database concept of `NULL` which is not necessarily represented the same way when interfacing with database client APIs.
There's probably a detail you glossed over whereby you're passing 0 vs NULL via separate method calls to the database client API. The distinction cannot be due to literal `NULL` vs. literal `0` purely in C programming terms.
The limitations of C require that database-NULL be represented differently from integral values in terms of data structures. Even if you do pass `NULL` and `0` in the exact same parameter location to the exact same method name, you'd have to ignore a warning about the implicit type conversion from `void ` to `int` and still the semantics do not change and you have no runtime bug as you described.
The middle of the interview should be reserved for a bit of uncomfortable talk where you talk to him about something that went bad. Thrash some of his ideas, question a few approaches and let him react to it. I also try to make it point to make him work on a situation where he doesn't have control over a few variables(like the stack, or the timelines, or the people or the requirements).
I keep the last few minutes for agreement, the conversation should leave a happy memory after all.
Likely outcome to meet the criteria is burn-out / resignation / death of personnel, especially if repeated.
In the original context, it is of course: https://en.wikipedia.org/wiki/Bataan_Death_March
https://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013...
https://en.m.wikipedia.org/wiki/Death_march_(project_managem...
The source:
When interviewing senior people, I like to get them going on war stories. "Can you talk about a project you experienced that went very badly?" is a good one. It's not necessarily that they went badly, but we've all been on death marches before (and I absolutely would not hire an architect who's never done a death march!).
The beauty of this is you can find out how they react to impossible demands and pressures. What they're proud of accomplishing in dire circumstances. Possibly what they're ashamed or embarrassed about, or mistakes/lessons learned (if they're that bold). You can learn a ton about how they talk about their colleagues! Are they full of praise, or contempt? Do they find someone to blame, or talk about how someone else saved their asses? You can also learn a lot about their actual approach to technical decisions - their taste, for lack of a better word.
You can ask probing questions here, but the important part is to get them speaking in an unguarded way. Nobody makes it to the architect level in this field without at least kind of loving the job. Find out what they love. Find out what they hate. Find out what they regret. Find out any strong technical biases they have, and why. But most of all, find out how they play with others. Because the architect's job isn't just to design, but to communicate. You don't just want a technical expert. You want someone that can value and respect the rest of the team, or they're just going to cause problems.