It's hard to tell from your question what kind of experience you have past the technologies you've listed. So I'm going to assume you're fairly junior. If that's wrong, please forgive me. But it's my assumption that if you have ten years of programming experience, you're likely not going to ask how to be more marketable in that space.
I'm not sure that working in Perl or Unix creates any liabilities for you as a developer. In fact, my experience has been that a working knowledge of Unix is a big plus to the resume. And I'm a big advocate of everyone knowing a lightweight scripting language to help with everyday tasks. Perl surly fits that bill. So let's focus less on liabilities, and instead talk about what might be missing and what you might highlight.
If you're serious about becoming a better developer, I'd worry less about tools and more about technique. Most places you'll interview, won't care as much about languages as they will about the way you solve problems. You'll likely want to know at least one of the mainstream languages Java, .NET, C/C++, etc, but I wouldn't worry too much about which one. That is, unless you have a passion for one of them. You might do a bit of research to see which language is typically associated with the type of development you want to be doing.
Going back to solving problems, I think it's important for you to be familiar with some of the basics of computer science. If you don't have a firm grasp of concepts like data structures, common algorithms, common architectures, object orientation, design patterns, etc... then you might not get very far in the interview process. Basic things like sorting and traversing trees come up in interviews, but they also reflect an understanding of deeper issues that come up on the job. You don't want to have to look up the basics when you're doing the work. You want to have command of those aspects. Save the internet surfing time for language specific questions.
After making sure you've got the basics down, if you really want to be more marketable do some actual development work. When I see resumes with contributors to open source projects, I do to things. First, I read the rest of the resume again which I don't normally do unless something catches my eye. Second, I go see if I can find some code online that you've written. Your code speaks for itself. That can be both good and bad. But if you're looking for an entry level programming position, likely it will be nothing but good. For entry level work, a hiring manager is more interested in your passion and drive than your technical prowess. If you have some, great. But elbow grease goes a long way at that level, and contributing to an open source project in some significant way shows that kind of initiative.
Another thing to think about is playing to your testing strengths. Make sure you're doing a lot of unit testing for your own code. Experiment with new tools and practices related to code quality. You have a leg up on most programmers in this space, because presumably you know how to test. That's not always the case. Just because you can write a unit test doesn't mean you know how to test. Focus on that and build on it.
More Articles on Developing in Perl and Unix
Perl taint mode can help prevent buffer overflow vulnerabilities
How Perl's taint mode can help you find insecure code.
Read Full Article
Measuring code quality provides unexpected benefits for Raymond James
Using CAST's Application Intelligence Program (AIP) -- an automated code inspection system -- Raymond James Financial is able to improve its code quality as well as facilitate main...
Read Full Article
Dig Deeper on Mobile Application Testing Techniques and Tools
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.