If anyone refused to answer questions like this in an interview I was running, I would ask them to leave and tell them they wouldn't be hearing from us. I don't care what your qualifications are, if you are an asshole who will not take directions, then I don't want you in my department.
My current employer said that they did not like to even offer interviews to anyone who was currently unemployed because there was probably a reason for it and they didn't want people that couldn't keep a job.
Knew I would be graduating in May of '08, so I started sending them out around Jan-Feb of '08 (4-5 months ahead). I got interviews in Feb-March and had my job offers by the end of March.
Graduated May of 2008 - Sent out 10s of resumes - Two interviews (not a great GPA) - got offers at both - took the slightly lower pay one because it had a better job description and was in a more convenient location. It has worked out very well for me.
As someone who works on the pricing system for a distribution company - this article may apply to retail, but it definitely does not apply to everything. Our suppliers try to screw us at every turn by making us deal with complex cost side, so we have to have an incredibly dynamic and flexible system to deal with an international customer base.
It really depends on how your departments runs. A lot of times the gathering of requirements for BAs is by far the hardest, most time consuming, most frustrating task on the project. They have to travel, deal with users / clients, play political games, etc. If the programmers are more of code monkeys in the organization: in that they get tech specs with pseudo code and just transition it to real code, then they do not necessarily deserve to get paid more.
I have been a support analyst, programmer, software architect, and BA (and worked with several PMs). You really can't have one blanket generalization in this area because it completely depends on structure and job responsibilities.
If they are worried about user experience and that is the main reason they do not encrypt - then why not at the very least use a version of encryption that the site can decrypt? Sure, the people who grab the data can run some cryptography programs on it and eventually come up with the algorithm, but it is a hell of a lot safer than plain text.
I think you need to define dead. If you are saying it is dead in the sense that there is no new development being done on it and/or it is not in high use, then you are completely mistaken. I would say the best "dead" definition for it is: any company looking to implement a new system would not choose COBOL as their language. In that sense, it is technically dying, but definitely not dead.
I started at a company 2.5 years ago as a COBOL programmer and am now a Software Architect for the company. I would say that COBOL still runs a very large percentage of business systems (especially banking). Our system does even implement GUI and we are starting to use a form of MVC for new development.
While I think most companies that have COBOL systems want to get rid of them and move to a newer language, doing so is going to take a very long time. My company has wanted to move from COBOL to a higher language for over 5 years now and never been able to prove the business case. The language will be around, at least in maintenance if not development for at least another 20 years imho.
The big problem that companies are having is that the majority of COBOL programmers will retire in the next 5 years and new college grads don't have experience with it and don't want to learn it because it is considered "dead" by mainstream CS. That means those that actually know the language stand to make a very large amount of money in the coming years helping big banks convert their systems, when they have nowhere else to turn.
With the job market the way it is and not having the best GPA in the world, I don't really have any other options right now. Also, I already signed a 6 month contract. So, as much as I would like to do some python coding for Google, I am kind of backed into a corner at the moment.