Keep moving
The harsh reality is that in the tech world, companies prefer to hire young, inexperienced, engineers.
This is the first statement given in article "Silicon Valley’s Dark Secret: It’s All About Age". The author also gives advices "to those whose hair is beginning to grey", where main of them is:
Move up the ladder
Move up the ladder into management, architecture, or design; switch to sales or product management. Build skills that are more valuable to your company, and take positions that can’t be filled by entry-level workers.
As I think this is an honest advice, I don't consider it the only advice. If you are passionate about your technical job you can keep up as long as this kind of job is needed - and that fully applies both to testing and programming.
More specific to testing, I want to note the following.
- Build and consistently demonstrate ability to accomplish more in less time. Maybe you can't always stay at work 60 hours a week but you will be able to get the job done in regular hours, if you practice time management, risk assessment, and problem-solving heuristics.
- Learn from projects you work on. Whether it's content management system, an online banking application, or back-end VOIP cluster, learn and consciously integrate into your expertise both domain-specific knowledge and "soft", transferrable, approaches.
- Learn about and try practicing technologies you work with. Use collaboration opportunities, talk with other passionate specialists - they will love to teach you.
- While developing technical skills build big picture vision as well. Technologies come and disappear, problems and problem-solving techniques remain.
- Stay passionate.
My approach to testing is as follows…
Eric Jacobson recently posted his excellent analysis of resumes he's been reviewing since his team is hiring. Here's a short snippet:
However, the candidate would have probably gotten an instant interview if they had included any of these:
- My approach to testing is as follows…
- See my software testing blog for my opinions on how to test.
- My favorite testing books and blogs are…
- I enjoy testing because…
I really like the first one. I suspect that for some, it's a challenge to write that in a short format (like what I think you'd see on a resume). But there's no reason you couldn't summarize something in a paragraph on a resume and provide more details in a cover letter (perhaps tailoring your approach a bit for the prospective hiring company).
Does your resume include any of those points? I agree with Eric, it should.
Getting a report card
A lot of people struggle with figuring out ways to get better at software testing. An additional challenge is to figure out some way to measure progress. There are a lot of bad metrics out there for measuring tester effectiveness. However, in a recent post on the software-testing list, Cem Kaner had the following insight that I thought was too good not to share:
Figure out what types of tasks you are responsible for. Figure out the attributes of those tasks. For example, what makes a good bug report? What makes a good risk analysis? What makes a good test plan? Develop your lists with colleagues who you respect.
Have a colleague you trust and respect review samples of your work against your criteria. (Do the same for her.) That review is your report card.
This doesn’t provide a tidy number. But if you’re trying for continuous quality improvement, this probably gives you more and better information.
Update your resume on a monthly or quarterly basis
It's difficult to look backwards and reflect on all the work you've done. If you've been working at the same place for 3+ years, I suspect you can't remember half the interesting things you've done. While you don't have to actually drag our your resume and make regular updates, you should create a log file of some of the interesting things you've done. Keep regular notes on tools, technologies, new techniques, recognition and awards, conferences/workshops/training, and other accomplishments. When the time comes to actually update your resume, you'll have a wealth of information to look through to help you build different resumes targeted at the opportunities you're interested in.
Only list the technologies you’re fluent in on your resume
Only list the technologies you're fluent in on your resume, or make it clear what your skill level is if you're listing things you've had exposure to in the past. I use to add qualifiers to my resume; like beginner, intermediate, and advanced when I listed a tool, language, or technology. Now I don't list very many technologies at all, since most managers I've interviewed with have been less concerned with technology and more concerned with skill. I think that's natural as you get more experience under your belt. But I could be wrong.
When you're pulling together your resume, only list tools and technologies that you actually know. Don't list the stuff you've had "exposure" to. If I can't ask you an interview question on it (like, write code in language X, or tell me how you would configure Y, etc...) then you either don't want to list it, or make it very clear that you've only had exposure to it. When looking at resumes nothing turns me off faster than seeing a laundry list of tools and technologies without context for how they have been applied by the candidate.
For me, it comes down to trust. In an interview, I'm trying to figure out what you can really do. If you get my hopes up by listing Java, Ruby, or some other techno-widgit I'm really looking for, and you can't actually do it, I don't know what else you can't really do that you're telling me you can. Even if you're really good at all the other stuff, once I feel like you've falsely represented your skills, it's hard to dig out. On the other hand, if someone has all the right skills but is missing the techno-widgit, I'm likely to hire them. I can teach someone Ruby.
For me, loosing the interviewer's trust isn't worth the eye-candy of listing all the technologies.
