6 ms·

Not so much a question as an approach, but... When interviewing senior people, I like to get them going on war stories. "Can you talk about a project you exper

by beat 10y ago

Not so much a question as an approach, but... 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.

ryanx435 10y ago
What is a death March in this context?
- popey456963 10y ago
  You continue even though you're doomed to fail.
  - troebr 10y ago
    I've heard Death March more meant as a crazy period before a deadline.
  - enraged_camel 10y ago
    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.
  - beat 10y ago
    Yes, this. A death march, to me, is a project that is doomed to fail, but you have to keep working on it anyway.
- sailfast 10y ago
  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 https://en.wikipedia.org/wiki/Bataan_Death_March
  - BurningFrog 10y ago
    To me, the concept also includes that it's all for naught, since the project fails anyway.
    - ChristianGeek 10y ago
      That's correct: https://en.m.wikipedia.org/wiki/Death_march_(project_management) https://en.m.wikipedia.org/wiki/Death_march_(project_managem... The source: https://www.amazon.com/dp/013143635X https://www.amazon.com/dp/013143635X
  - enave 10y ago
    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/013143635X https://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013...
segmondy 10y ago
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.
- biot 10y ago
  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.
  - nilkn 10y ago
    > 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.
- pc86 10y ago
  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.
_d8fd 10y ago
>> 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..."
- JoshTriplett 10y ago
  > 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.
- beat 10y ago
  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.
flukus 10y ago
> "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?
- beat 10y ago
  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.
  - jsd1982 10y ago
    > 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?
    - beat 10y ago
      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.
deleted 10y ago
[deleted]
danellis 10y ago
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.
UK-AL 10y ago
10 years. Never had a death march. Reason being chose good companies with good processes. Being a product company helps a lot.
iitr_sourabh 10y ago
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.

by beat 10y ago

ryanx435 10y ago

What is a death March in this context?

popey456963 10y ago
You continue even though you're doomed to fail.
- troebr 10y ago
  I've heard Death March more meant as a crazy period before a deadline.
- enraged_camel 10y ago
  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.
- beat 10y ago
  Yes, this. A death march, to me, is a project that is doomed to fail, but you have to keep working on it anyway.
sailfast 10y ago
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 https://en.wikipedia.org/wiki/Bataan_Death_March
- BurningFrog 10y ago
  To me, the concept also includes that it's all for naught, since the project fails anyway.
  - ChristianGeek 10y ago
    That's correct: https://en.m.wikipedia.org/wiki/Death_march_(project_management) https://en.m.wikipedia.org/wiki/Death_march_(project_managem... The source: https://www.amazon.com/dp/013143635X https://www.amazon.com/dp/013143635X
- enave 10y ago
  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/013143635X https://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013...

segmondy 10y ago

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.

biot 10y ago
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.
- nilkn 10y ago
  > 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.
pc86 10y ago
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.

_d8fd 10y ago

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

JoshTriplett 10y ago
> 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.
beat 10y ago
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.

flukus 10y ago

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

beat 10y ago
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.
- jsd1982 10y ago
  > 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?
  - beat 10y ago
    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.

deleted 10y ago

[deleted]

danellis 10y ago

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.

UK-AL 10y ago

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

iitr_sourabh 10y ago

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.