How can you get a job with a company with innovative tools & methods when your current employer uses older/less innovative techniques?

Question

In reality, there are two types of IT team/company. One type tries to follow every industrial standard and adopt advance technologies (such as J2EE, security and other stuff), while another has low standards and uses old technologies.

When I'm on an interview, the interviewers don't seem to like the fact that my current company does not use certain methodologies or practices. For example for a question: "How can you ensure you are getting proper requirement from clients?" my answer could only be: "We have a meeting to discuss it with them."

If my company doesn't use innovative methods and practices, then saying that I learn quickly doesn't really help. It seems that if you can't get the experience you can't get the job, and because you can't get the job you don't have the experience.

What should someone do in such a situation?

Answer 1

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!

Answer 2

First, there are parts of the job, that are totally dependent on you, so improve them. If we are discussing software development, it's your choice whether and how you write unit tests, what policies you choose and follow regarding new code you write. It may be tricky with legacy code but even then, you may develop some kind of guidance how to refactor it. It may be trickier if you have collective code ownership in your company but considering it is one of mature practices odds are this won't be much of a problem.

Second, there are lots and lots of sources where you can learn new things outside of your workplace. How many books you have recently read on areas you have in your mind when asking a question. Even if you can't really apply everything that is described in Clean Code you should likely know, at least in theory, how things can be done properly. In terms of managing requirements Dean Leffingwell's book is a good place to start. These are, of course, just examples; there are a lot of great sources in the internet which you can choose from.

Third, once you know the craft in theory apply it in practice. Convince guys in your team that you should try a couple of new things. As sad as it is, most companies that do mediocre job with how they do their work just don't know how to do better. In such case your colleagues should happily follow your lead in adopting new practices.

Fourth, don't be so focused on a specific technology. One thing it is unlikely to change unless you change the project. Another is, that a good developer shouldn't be so much attached to a single programming language or a framework. They change too fast. By the way: when I'm recruiting I expect that you know technologies you actively worked in very well and the rest of them -- not so much. I understand that you won't learn programming in a specific technology from a book -- you have to spend some time using it before you're fluent.

On a side note: if after an interview my impression is that you learn only things which you are told to do at work, that tells me something important about your willingness to learn.

Answer 3

Demonstrate outside work experience.

The nice thing about programming is you can easily demonstrate skills that are not related to your employment. If you want to work in new technologies, go work in those technologies, write about them, contribute to some open source projects, create a github account and post some code of your own demonstrating what you can do. Put all this on your resume. It'll show that despite your employer using old technologies (like J2EE), you are interested in and can teach yourself new technologies.

Answer 4

Instead of focusing only those companies that use tools you would like to use but don't have experince in, find some companies that are in transition, they have work that you are qualified for and work that you will need to learn the technologies for. So you get the job you are qualified for and then after impressing them with your general wonderfulness, it becomes relatively easy to move to a role using the newer stuff.

Also, consider smaller companies. They often pay less and thus have less choice in hiring so your lack of experience may not be as offputting, but they can help you get the experience you need for the job you eventually want.

Answer 5

First, you can use this as a reason to change jobs. Make sure you let them know that:

1. You are aware of these and have used them on your own time.
2. You are open to change and willing to learn new things.
3. You have a proven track record of being able to learn new technologies.

In some ways, there are going to be fewer candidates that have experience with the newer technologies. There is a point when the newer ones become more popular.

They need to know that you're not using the old tools because you are resistent to change.