I know it can feel like an inescapable situation, but have faith - it can change!
Know the Market
First point is to realize that companies and the overall hiring pool will change over time. When there's a lot of candidates in the market, interviews will get noticeably tougher and they will expect the latest and greatest technology because they can do that. When the market is hot, and candidates are hard to come by, the interviews tend to shift to looking for smart people who can learn and work productively with technology and practices that are new to them. So sometimes the answer is to wait it out while working on your skills. But it helps to know your area - how many people do you know who are easily finding jobs? Do they all have the latest skillset?
Even in a tough market, don't give up... but do ponder the idea that your primary focus may need to be improving your skillset.
Improving Technology Skills
Some skills revolve around the latest and greatest technical toolkit - in software, that's stuff like JEE, Ruby on Rails, Eclipse - basically any tool that either is used as a component in something or is used to make something. These tend to be the areas that change most rapidly over time, and the area where an existing project is most likely to fall behind as inventing a new widget is far easier than integrating it into an existing product.
The good news is, in a market where there are more jobs than people, this is the first area to get leniency. In the meantime, if these are your biggest weak points, I highly recommend taking the extra time and working on an unpaid personal project in your off hours. Open source or something related to a personal passion are both good drivers.
Or - if you really need guided training - conferences, bootcamps or college courses. Conferences will put you closer to the bleeding edge, but they won't offer as much guidance or structure. College courses offer the deepest learning experience over many weeks, but they tend to be a bit behind the cutting edge, as it takes time to develop the curriculum. Bootcamps hover in between.
Also - find out what your company will pay for. If you have the respect of your current boss, you may be able to sell getting training in newer technologies in order to have some experience to bring to innovation within the company - as long as you select coursework that somewhat relates to the work you are doing.
Improving Process and Practice
Things like "agile development", "test driven development" and other best or recommended practices fall into this category. Some of these would require a conversion of your entire team to implement - for example, it's hard to have a scrum by yourself. However, others may be options you can try in a small way on the job. For example, in many places, you can concoct your test before you build the solution - that's test driven development.
In some cases, these are the most critical skills - when a technical industry develops a dramatically new way of doing things, the change for individual workers can take a serious learning curve. A hiring company is likely to prefer that workers made the transition on their last job. Fortunately, these major changes don't come along that often - I'm thinking of things like object oriented development and agile methodologies.
Many of these can be implemented regardless of the current technology being used at your job. Also - you may be able to advocate for the option of taking a small part of the project and trying a new practice in the interest of improving your efficiency/quality.
New practices can be picked up at conferences and courses, but the best way to learn them is to practice them. Open source or other big team volunteer efforts can be a great way, as the ideal approach is to work with others who know how to use these practices better than you do so you can get guidance and tips as you go along.
Lastly - Interviewing
Regardless of where you are in terms of up-to-date skill sets, when you go to an interview, don't focus on what you lack - focus on what you have and how to sell yourself.
You're right that saying you pick up things fast is really more of a promise than a demonstration of your skills. But having some points of reference for things you've learned recently and how quickly you picked them up is useful to reference.
Also - don't focus on the weakness of your current practices - spend some time in your current company trying to figure out why they are the way they are. Do you, for example, have long standing customer relationships that make your requirements gathering meetings less risky? Do your customers have the commitment required to be part of an agile process? If not, then you might better off with the current approach.
For example - reading the query above - "How can you ensure you are getting proper requirement from clients?" could be answered as follows:
It's our current practice to gather requirements in customer meetings.
It's how we've done it for a long time and we have our customer's
trust after a long history of good performance. Because we know it's
risky to do a waterfall development process, we do everything we can
to vet the requirements up front - for example - if there's GUI
involved, we send prototypes as diagrams for customer feedback during
high level design. Also - if a question comes up during
implementation - here is how we resolve it...
Yep - it's an old process to gather requirements this way, but at least your answer is thoughtful and seeks to balance the faults in the process with some extra effort. If you are a part of requirements gathering and you see flaws in the process, then this the time when you should be talking to your boss about ways to improve the way your team does work. You don't need a whole new technology suite or best practice to make small improvements in your day-to-day work. And showing that kind of initiative is good on both your current job and in any interview you go to. Because this answer is even more impressive:
We used to just have a quick meeting with the customer. It worked
well enough, but we noticed that there were a lot of bugs later on
when the customer saw the implemented GUI. Since I work in that area,
I talked to my boss and he let me change the process - now, before we
design the GUI, we shoot the customer a few diagrams of our intent.
This has cut down on bugs by 50%.
If this was your answer, I would totally want you on my team - because no matter how bad your company's process is, I can see you are an agent for improving things. So chances are, you're going to make the processes on my team work better, too!