Ask to see a current project-plan for an active development project. They should be able to walk right into the other room and just print one out from Microsoft Project or its equivalent. If not, ask: “Why not?”

Uh .. I don't necessarily agree with the whole "Everything's got to be in MS Project" concept. As long as management and developers are talking and there's agreement that things are moving in the right direction and targets are being met, things are fine.

Look the interviewer squarely in the eye and ask him or her how many times a year anyone has been required to work overtime. If the answer is a number greater than one, ask: “Why? What went wrong?”

Yeah .. that may end the interview on a bit of a downer. If you've been on the operations side of software support, you know that unexpected things happen and overtime is required. It's probably better to ask an open question like "How do you deal with overtime?" or "How busy are you right now?" than it is to ask a closed question such as the one you suggest.

Overtime gets compensated -- my deal at $work[-2] was that I got double time off for a support call, so that a one hour call gave me two hours off, and if the call interrupted my sleep, I would just sleep in, have breakfast and get to work whenever I got to work; my employer was fine with that. If you're talking about development overtime, then I expect that, after the rush, the company would tell the developers to take a few days or a week off and go home and sleep.

But these days I can't believe that managers think they're going to get 50% more quality code done by getting their developers to work 50% longer hours. I think research has shown that after eight hours developers start to make mistakes, then have to spend time to fix those mistakes -- so you're not really any further ahead, and you may even be further behind if some of those mistakes were bad design decisions.

If you find yourself in such a hole, look for ways to inject organization and planning into the process any way that you can. Start by organizing yourself. Keep a diary and a time-log. Turn off the e-mail and check it only at 9, 12:30, and 4. Get a calendar scribble-pad for your desk and actually scribble. With practice it will begin to become habit, and sometimes habits spread (in a good way) to other people around you.

I started keeping a log book a few years back -- it was something my colleague Mike Stok did, and it's fantastic. Now when someone asks me something, I flip back in the book and read out the command I typed. That's way better than "Oh, I think I typed in ..". I can also pin-point, to day anyway, when I actually did something a few weeks or months back.

Some days I cover half a dozen pages with notes -- and those notes are extremely valuable. Without those notes I'd have to go ask some people questions that I asked them a month ago -- that's not professional, that's just plain dis-organized.

But if they don't... feed the monster, roll the dice. And next time around, ask those “awkward” questions!

I've also heard that personal connections, or networking, actually produce 60-70% of jobs, and the web sites that you mentioned work about 1% of the time. I put more faith into a site like LinkedIn myself. I found my last two jobs through personal connections -- it works for me.

Good points, talexb; especially re the log and personal connections.

Two minor nits (which is, I suppose, redundant, but I call it "emphatic" with the emphasis on "minor"):

• As I read the OP, the ref to M$ Project was more by way of example than a global requirement. (Heaven help us if it wasn't.)

• And re your "But these days I can't believe that managers think they're going to get 50% more quality code done by getting their developers to work 50% longer hours."

  Certainly some -- perhaps even "most" -- managers have learned that lesson, but to paraphrase a famous observation, "Nobody ever went broke underestimating the managerial skills of some managers... but one may go broke by overestimating their willingness to buck their bosses."

Certainly, some kind of "interview counterattack" to learn whether the manager is among the enlightened will have great value.

Overall, though, a heartfelt "++"

Regarding the MS Project reference, you're quite right -- although I detest this product, it's more because it's the embodiment of 'some guy wearing a suit, sitting in an office telling me what to do because of some damn chart'. When you get down to a GANTT chart that's down to the level of spending half a day writing one specific routine, that's the time to start a new career as a musician .. or something.

Again, an opened ended question goes a long to probing gently about the employers attitude, in this case, towards developers doing overtime. The whole job interview thing is a conversation that's really a negotiation. You have to explore, question, examine, with the understanding that both sides want to get as much information from the other side as possible, so as to make a fully informed decision on whether This Is The One.

Hearing someone describe a job interview as 'self-flagellation' tells me they're not comfortable in their own skin yet. Or maybe it's the jacket and tie -- hey, if you're not comfortable in it, ditch it and wear something comfortable. Think about it this way -- if you're going to wear a suit every day, then wear one to the interview. If not, not. I wore black jeans, nice shirt and sweater to my first interview at $work[-1] and I was probably the best-dressed in the room. I dressed down (ditched the sweater) for the second interview, and it was (as the kids say) all good.

And thanks for the vote of confidence. ;)

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

I started keeping a log book a few years back

And I had a comment on that, but I decided I was wandering too far afield. Time for a new Mediation: Work practices: log books, notes files...

I agree with your general sentiment, but I don't agree that they should necessarily be able to produce a "project plan". In fact, I'd be worried if they had a highly detailed project plan, because in software development, those are rarely kept to (your comparison to the building industry doesn't hold a lot of water in my opinion. It's possible to do deterministic planning in building - what you plan is pretty damn close to what you build. It's very rarely the case that that's true with software).

Still, I'd hope they had some documentation about their project. A well shaped product backlog would be a good start in my books.

Cities and major-contractors require so much planning and organization that it is often the case that companies have several staff members dedicated to that effort.

Smaller contractors, on the other hand, are extremely slipshod. Many of them get by just fine anyway.

I think that's an important point. I don't expect a startup to have a great deal of organization, but enthusiasm and general competence can make up for a lack of formal processes. Microsoft Project is for companies that have people who don't really want to be there.

I respectfully but entirely disgree.

The folks that you demurely say “get by just fine anyway” eventually give-up and go to work for a company that's big-enough to support more than one person...

Ahem.

“There is no shame in being self-taught,” as long as you actually learn.

If you find yourself five-years-on “employed” by a “company” that is still able to support no more than its founder, and at a level no more than “getting by,” then you have merely been u-n-e-m-p-l-o-y-e-d for a remarkably-long period of time! You Are Doing Something Fundamentally Wrong. Deal with it. Change. Grow.

Excellent advice and could be expanded with more tips for subtle prying... I will give it some serious thought the next time I'm headed into an interview. I must add that in 20+ years of diverse employment my favorite job, far and away, was the one where I had to sleep under the desk a couple of times. Fortune 500 company so "always fails at everything" is a bit too strong. :)

The trick would be trying to figure out ahead of time what on Earth might indicate it's a place you'd enjoy the odd 80 hour week.

Personally, I'm okay with working overtime, as there are some jobs that are simply cyclic in nature, and you have periods where things come up that need to be dealt with. At my current job, I submit papers and posters for conferences, and so I end up working longer hours both to finish the presentations / posters and to get the software done to that I'm going to be talking about.

I'm also not so keen on the project plan aspect -- some of the best projects I've worked on have been done without planning, because we got it done under the radar without management getting their hooks into it and trying to make it more than it really needed to be.

...

That being said, I think that what it comes down to is that we have to remember that as part of the interview process, you need to size up the potential employer to determine if they're the type of place that you'll want to work. If you're miserable at the job, it doesn't do you or the company any good; but every person has their own pet peeves, and what may be a great job for one person may be hellish for someone else.

The last two interview I had were rather odd, as the last one was for my own job (long term contract, but a new company won the contract), and the time before that it was for a government agency and my first question was "where's the job?" and I didn't see a point in continuing after they told me. For the last one, here are the questions I had typed up to ask them, that were primarily based on areas where I had run into problems in the past:

Mind you, anyone who is in the business of doing anything else ... building houses, for example ... has a rigorous process for planning and estimating and tracking contract-progress. (Cities and major-contractors require so much planning and organization that it is often the case that companies have several staff members dedicated to that effort.)

Yeah, and when was the first time their schedules had any relationship to reality either? Boston's more than the name of a band.

“I'll be more than happy to sign a non-disclosure agreement. And, I'm not asking to keep the document, nor even to study it closely. I'm asking that question because I believe that my business-value to your organization will be greatly impacted ... one way or the other ... by the management practices that are applied here.”

Look them straight in the eye, steadily but calmly. If they respond with a buzzword that looks like it was salvaged over a cup of espresso at a bookshop (then left on the table ... the cheapskate), you've got your answer.

How an interviewer answers that question is as equally important as the specific answer that they give. Some interviewers do not expect to be the subject of tough questions, and if you are not looking the other way at the time you can read all you need to know from a passing-glance. Other interviewers will rise to the occasion and will readily accept the position of being “the one who is now answering.” Their body-language will also reveal much, again in the first few seconds.

Bear in mind that they're also reading you...

Your goal, of course, is not to put a person on-the-spot about their own organization. You need to know if there are problems, of course, but you also might be able to position yourself as a real potential change-agent. (“Maybe this person can help us with a whole lot more than just Perl code.”) Asking this question in a confrontational way merely fingers you as a troublemaker. Presenting it in an insightful way, doesn't. If the person lobs the ball back at you with “what might you suggest,” without doing so as an outright cutoff-smash, the interview could enter a whole new dimension and you can start to appear to be senior.

If you find yourself in, say, the second-or-third “job which sucks,” staring once-again at the night sky outside your office window while your spouse goes out to dinner without you, it could well be that you are blowing the interview. Getting the job, yes, but blowing the interview.

How an interviewer answers that question is as equally important as the specific answer that they give.

I agree. Keep in mind that the people you're going to be working with and reporting to are sometimes not those doing the interview. I've been on interview teams before where I felt the urge to apologize for one of the other interviewers and say, "Please don't make your decision to work here based on that nitwit." Of course, I never did that but you get the idea. The probing can be used on any interviewer but the reactions matter more from your prospective direct manager and team mates than an HR drone.

On that note I recommend asking about indirect reporting structures. I got hosed by this before. I liked my manager pretty well and he was generally supportive but 95% of the work I did was for another group which had much more influence in the company and they were atechnical (if I may), disorganized, and sometimes dishonest leading to duplicated work and stupid mashups with clients. If I'd know that was going to be my real management, I could have taken something else and avoided a lot of pain.

But the one about over-time is a good one to remember. As for project plans, I've worked in enough places where they didn't have project plans, and were still nice to work at - and vice versa. As for the monster - last time I left a resume there was in early 2002. Recruters are still calling because of it.

Interesting comments, Monks. I think that the general thrust of my comment was seen to be, as it was of course intended to be seen, as “somewhere in the middle of the usual two extremes.”

In way too many cases, computer software development devolves down to “we're making this thing up by the seat of our pants ("but of course it's gonna be great... no guts no glory..."). Dead soldiers had plenty of “glory”: it was the generals who screwed up.

No amount of dollars can pay you back for sitting in a hospital bed clinging to life after a heart attack, nor for walking into a divorce court with a man or a woman who's decided that you really do love your work most. (Neither one of which has ever happened to me, and this is why.)

And furthermore, these highly destructive work practices don't result in “better software.” I think they make our work-product much worse.

In my 25-odd years in this business, I've written a lot of great programs on paper. I've developed HTML prototypes using nothing more than a good text-editor, and thrown them away dozens of times in dozens of meetings. (That's what they were for...) I've written documents, and felt the same mental processes churning through my head that I've always felt when writing source. The idea took shape in my head and poured-out onto paper, and when sometimes-serious problems inevitably showed-up all I had to use was the “strikethrough” tool.

This is, I very-flatly assert, a distinctly better way. The software that results is much better. The work is completed faster because you land three-wheels-down on the correct runway and don't slide off the tarmac. Other workgroups complete their part of the task, in parallel to yours, because you've created an environment in which that sort of thing is possible.

Other “construction trades,” in fact all of them, routinely succeed in doing what the software development profession routinely fails to do. I think they're on to something. I think that when we run around bantering strategies with funky-but-upbeat sounding names like “agile” and “extreme,” all the while claiming that such things properly belong only to our storied ivory tower ... we're ... well ... we're just plain wrong. It's just not true. We're putting ourselves in harm's way by accepting it, and delivering inferior work. Literally, a “lose-lose situation.” I'm saying that what they're doing, and how they're successfully doing it, absolutely applies to us in every respect.

In my 25-odd years in this business, I've written a lot of great programs on paper. I've developed HTML prototypes using nothing more than a good text-editor, and thrown them away dozens of times in dozens of meetings. (That's what they were for...) I've written documents, and felt the same mental processes churning through my head that I've always felt when writing source. The idea took shape in my head and poured-out onto paper, and when sometimes-serious problems inevitably showed-up all I had to use was the “strikethrough” tool.

I learnt to do it that way too, 30 years ago. But then I realised that editing on screen is far more efficient that doing it on paper, so I gave up the paper. Then I discovered that prose was horribly misinterpetable. On paper I'd often used Wernier-Orr diagrams for bits of the design, but they were hard to draw and maintain, even in an editor, so I started using a form of pseudo-code; a hybrid of several I'd studied and various languages I'd used.

After a while of that it dawned on me that if I actually used real code, instead of pseudo-code, I could mock-up the lower levels quite quickly and then get the lanaguage compiler or interpreter to verify what I'd written. It would point out inconsistancies, typos, mismatches in parameters. Stuff like that.

And that led me to making the lower levels return mocked-up, but feasible return values. Then I could actually run the upper levels very early on. Demonstrate them, Test them. Show them to clients/stake holders.

With a little more effort in adding a few sleeps or loops calculated to approximate the time taken by the as yet unwritten lower levels, I could even get a feel for what performance might be like. Measure it at a very early stage and track it as development went along. Show to the clients and get feedback on their impressions of whether it was good enough for their purposes.

Often the first cut of the higher levels would show up some inconsistancy or other and I'd throw it away and start again in the knowledge of where it had gone wrong. Invariably, the second cut was better and came together more quickly than the first.

After a few years they invented a name for this process. It's called RAD.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

After a few years they invented a name for this process. It's called RAD.

Yeah, but would you build a building with it?

Other “construction trades,” in fact all of them, routinely succeed in doing what the software development profession routinely fails to do.

By "all", of course, I assume you mean "none" -- otherwise I'd have to question whether you've ever actually seen anything ever constructed, let alone been in a building. I've worked construction myself, and I have a couple of friends who do HVAC design and sheet metal contracting. For every building ever built without a stack of change requests piling up the day after bid approval, I can show you a space shuttle software project at NASA (and there's only one of those).

I think that when we run around bantering strategies with funky-but-upbeat sounding names like “agile” and “extreme,” all the while claiming that such things properly belong only to our storied ivory tower ... we're ... well ... we're just plain wrong.

We call it software for a reason. Okay, Fred Brooks calls it "pure thought-stuff", but that's still at least somewhat different from the thirty story townhouse tower they built downtown here. You know, the kind where they have to dig a really big hole first, then sink pilings, and if they decide they need five more stories as they're hanging drywall inside, they're stuck thanks to the inexorable laws of physics and material science from their civil engineers. Meanwhile, we add a few lines of code and maybe another stick of memory.

Is this not a fundamental difference?

Nope, it's not “a fundamental difference.”

I have been working on a project without such planning and yes it is a nightmare! If I had known what I was getting into, I would have walked away I think. That said I have enjoyed "working under pressure".

The "what went wrong?" comment struck home, the whole overtime is expected for normal delivery is bad IMHO. If there is overtime it should be because of an unforeseen "challenge".

Great post!