Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was once brought in to interview as a technical lead by a turnaround artist (the company was in dire straits). During the course of the interview, they asked me about a problem they were banging their heads against for _months_ where tomcat taking a very long time to restart (on the order of 30-60m). I thought about it for a second, and once I overcame my surprise that they were using Tomcat, I asked if they had large session objects.

Years ago, I'd run into a somewhat similar issue, as Tomcat serializes its internal session representation on shutdown, so that when it comes back up, state can be restored. If one has truly gigantic session objects (which is a no-no anyway), it takes forever to serialize them, and as muster them back into memory.

They tweaked the config, the problem went away, their "chief architect" was fired, and I got the gig. Turns out this problem had them weeks away from going out of business, they'd been working on solving it for months.

The gig turned out to be a major disaster anyway, their problems were far deeper than technology.



> The gig turned out to be a major disaster anyway, their problems were far deeper than technology.

Weinberg's Second Law of Consulting: "No matter how it looks at first, it's always a people problem."




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: