As a software developer, how do I ask an employer about internal support when handing production errors?

Question

I've worked as a software developer for 4 years and find that there is a specific scenario I dislike very much.

The scenario is that I am "thrown" at a problem with no internal support. I will be tasked by my manager to fix something that went wrong and will have no useful access to how anything is done, how the software works, no documentation, all the test code I dig up are out-dated and do not work.

The problem is that I am literally "stuck" with this type of cases until it is fixed or I leave the company, then whatever I don't fix goes to someone else. When I started I inherited some of these, and well, I still had them when I left. I don't think the manager breathed down my neck to fix these, but having these "unfixable" cases with me bothered me quite a bit, and felt it was pointless to give them to me.

Just recalling from my last role, there was a case dealing with FTP connections. It took me 2 days of talking with people around the office (100 people office) to get a definitive answer on whether our internal FTP connections to the outside are passive or active. My manager obviously didn't know, so he pointed me to different people, then I had to track down false leads, bad leads, people who aren't sure, etc.

I'm not sure how to ask an interviewer about this type of scenario. How can I ask a potential employer about internal facing resources to assist developers? I am thinking of either some sort of documentation practices, or mentoring role for new hires, or something... but I have no idea how to frame the question.

Answer 1

I find that often in organizations like that, you can find comments in the code that have people's names in them. Go to your project manager and say, "I need to have some time with 'msmith' or whoever is doing his job now.

Answer 2

Asking about documentation protocols would be the best way I would think. A perfectly legit question to ask in an interview. It's always a good idea to get an idea of what you will be tasked with before you start. But sometimes no one admits there's documentation issues, or they just don't know, so even then you can be thrown in the deep end.

There's not a great deal else you can do unfortunately.

I've never come across anything unfixable though, I have had to re-write things from scratch, but always found a solution eventually. It's what I was tasked to do. Developing methodology to troubleshoot and deal with these situations is more productive in the long run.

Answer 3

Pay attention during the interview process especially if you get a chance to visit the office. I've had interviews where attendees had to "put out fires" during my interview. Others showed up late, rescheduled and basically showed how chaotic their world was. Some will tell you this is normal. Everyone is busy and working 80 hours a week, blah, blah, blah - nonsense.

Good managers run the interference and create an environment where things can get done. If they don't show they're organized especially during the hiring process, other areas are probably a mess. Amazed at how over-worked teams don't make time to hire people and wonder why they're over-worked.

Ask about how requirements are gathered and documented. Where do they track requests and projects? Do they have any established methodology or are they "kind-of-sort-of-agile/waterfall."