Hacker News Reader

>> Can you talk about a project you experienced that went very badly

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..."

I actually ask "Tell me about a project that went well for you. What was it, what was your role, and what was the final outcome?" I ask follow-ups, and generally let the interviewee get comfortable, since it's a low-pressure question. However, as a follow-up, I usually ask "Tell me about a project that -didn't- go so well. Same questions, and what'd you take away from the experience?"

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

Yes, that's an excellent approach, and really, that's how I'd usually do it. The important thing is to get them feeling comfortable, safe, and confident.

> 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?

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.

I'm after maximal side effects here. I'm not trying to figure out what they know. I'm trying to figure out who they are. That happens when they're unguarded.

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.

This could end up being stressful for both sides. Experienced candidates could/should counter with the same question. I doubt decision made under stress will turn out good.

If someone is so nervous and anxious that they can't just talk shop with a peer and share some war stories without feeling stressed... well, that tells me something very important about them.

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.

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.

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.

> 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.

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.

> 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

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've been interviewed by clearly hostile engineers... is a superb data point in an interview.

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.

>What do you think about giving the candidate an opportunity to get advance notice of that you'll be asking that question

I've been doing this and advocating for the practice for years. What is with the "gotcha" interview?

Uh, maybe they are so good and come from an environment with good process hence no death match. As a manager, no death march here, I rather ship a few weeks late and have a superior product and developers not burnt out. A lot of hard deadlines are made up. No one on my team will ever experience, that's what agile is all about. We ship the best we can within the constraints we have.

A combination of having been fairly lucky and terrible autobiographical memory (I have trouble assembling stories from memories—basically, nothing sticks in my brain as a story and very little from my personal life ever strikes me as story worthy, which made those "what did you do over the Summer?" writing prompts in elementary school absolute hell) mean I have little choice but to pick a real event and invent a narrative for these kinds of questions. I hate them.

[EDIT] remove word that didn't need to be there.

> Uh, maybe they are so good and come from an environment with good process hence no death match.

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".

Absolutely, there are many nightmares. I know death march, I've experienced it, but I'll fight for my team never ever to, should I succeed they shouldn't be penalized for not going through the pain. I'm constantly teaching how to be pragmatic while shipping. My nightmare has been integration with external vendors. Testing blind all from unproven specs.

Agree. Even in the best environments with good processes, everyone with a few years' experience will absolutely encounter a case of "something was more difficult than we expected." Being in a good environment just means that more solutions are available (e.g. communicating with management and reducing scope).

Note that the parent post put a lot of emphasis and importance on "death march" specifically, so you are actually altering his/her point quite a lot here:

> I absolutely would not hire an architect who's never done a death march

Oh, I meant that. A candidate for a junior programming job who'd never been on a doomed, nightmare project? Sure, no problem. But an architect? What if something we're working on turns into a death march, for reasons outside of our control?

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.

Perhaps, though I'd strongly disagree. However, they phrased the actual interview question as:

> "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.

Sometimes you don't have that luxury. What if your company requires an influx of new capital to be able to maintain your current staffing levels and one requirement of the funding is delivering a set of features in a week? Adopting the attitude "we'll just ship a few weeks late" may result in funding not going through, everyone losing their jobs, and the company dissolving.

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.

> Sometimes you don't have that luxury. What if your company requires an influx of new capital to be able to maintain your current staffing levels and one requirement of the funding is delivering a set of features in a week? Adopting the attitude "we'll just ship a few weeks late" may result in funding not going through, everyone losing their jobs, and the company dissolving.

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.

If they've never worked anywhere with poor processes then they're incredibly lucky. Even places with good processes can end up in a situation where these sorts of things are necessary.

> 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.

I've worked in industries with hard deadlines. My first job was in large-scale academic test scanning. The kids take their test when the calendar says to take the test. And the trucks would show up at our docks with boxes full of tests whether we were ready for them or not. We might have a four month period to do our development, but the production season rolled around and we had to be ready.

The worst death march I was ever on was against a legislative deadline. Oh god, may I never do that again.

Before I started with my current company, there was a legislative deadline that gave an agency 30 days to implement some pretty substantial changes, roughly 60 days of full-time work for the entire team. Apparently the folks writing the bill felt that 60 days was too long and the agency should just figure out how to do it.

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.

> "Can you talk about a project you experienced that went very badly?"

How do you align this with the "don't talk shit about previous employers" rule?

I'm not asking them to talk shit about previous employers. I'm asking them to describe a situation. You can have a difficult experience, and describe that difficult experience, without talking shit about the employer at the time.

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.

> caused by the difference between NULL and 0 in a C pointer

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?

99% of the time, yes. But not always.

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.

> 99% of the time, yes. But not always.

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.

For senior positions especially, getting on to things that "went bad" right away in the beginning of the interview might be counter productive. It makes the person uncomfortable. How about seeking his advice(genuinely) on a problem that you are facing. Or telling him about a situation where you personally fucked up and ask him how would he handle it. The purpose is to build trust and to do that it is extremely important to be genuine, not just sound genuine.

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.

As an ADHD sufferer, I loathe questions like this, because while I can assimilate the knowledge and lessons that came out of a failed project, I am very poor at recalling specific events on demand.

10 years. Never had a death march. Reason being chose good companies with good processes. Being a product company helps a lot.

What is a death March in this context?

A grueling process being forced upon you by circumstances / management that requires an unhealthy amount of hours, stress, etc to achieve to a (potentially unreasonable) objective by a certain time.

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

I don't doubt that Bataan is the original, original context, but as far as software engineering goes, the term comes from this book:

https://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013...

To me, the concept also includes that it's all for naught, since the project fails anyway.

That's correct:

https://en.m.wikipedia.org/wiki/Death_march_(project_managem...

The source:

https://www.amazon.com/dp/013143635X

You continue even though you're doomed to fail.

Yes, this. A death march, to me, is a project that is doomed to fail, but you have to keep working on it anyway.

No, a death march refers to the pace of the march, i.e. you're marching so hard (without rest) that you start losing troops to fatigue or worse.

I've heard Death March more meant as a crazy period before a deadline.