[sheepdog]

I'm a young guy, but this presents an interesting question: what's the best path to modernize your skill set?

Imagine being a Cobol or dBase III developer. You recognize that some new technology (say AWS Aurora) is in demand.

So you study a whole bunch during your off time. You do tons of courses, hobby projects, and even take the applicable certifications.

Here's my question: then what? You have textbook knowledge of this new skill, but no actual production experience. What's the best way for these re-skilling workers to make the jump from learning to earning?

[clevernapkins]

Take a job with a lesser title / pay but in exchange get exposure to the new tech you want. Do that for a year or two and the next position you'll be back on par.

[armchairhacker]

Depends on what specifically interviewers are looking for, but:

- You do have production experience, just not with the new software - You know the new software, and especially if it’s new, you probably know it as good as most other developers - Your prior coding experience won’t 100% transfer over to new tasks, but it won’t 0% transfer either. For example many programming languages are very similar, if you’re familiar with one general-purpose language you’re ~almost~ familiar with all of them (C++, Rust, C#, Java, Scala, Kotlin, Swift, TypeScript, etc.)

[commandlinefan]

> but no actual production experience

Ok, so it would be unethical for me to suggest that you lie and imply that you have actual production experience but... there's really no way for most interviewers to realistically check whether or not the company you worked for did or didn't use (say) AWS Aurora in some internal projects. That's why they do technical screens and ask you trivia questions about things.

[val314159]

If you're working in software development already, all decent employers should encourage you to constantly learn, even if it isn't directly related to the job at hand. If this isn't the case, it's a huge red flag.

[mbrodersen]

It’s simple: Every year find out what the most in demand tech is for getting a job. Then learn what you don’t know already. Repeat. That’s it.

[mbrodersen]

Eh? Why the downvote? That’s what I have always done and it works.

[kleiba]

I didn't downvote you, but I could imagine it is because your comment does not actually address the point made by the OP: which is that you can learn new tech that is not applied in your job only on a theoretical level, but you will not be able to claim applied knowledge of it on your resume.

I think though that there's other ways to apply new things you learn than just in your job. Open source projects come to mind, of course.

However, that raises a related point: if our field one where it's a necessity to spend a substantial amount of hours in addition to your day job (for both studying new tech and finding ways to apply it) just to stay relevant for the job market?

[mbrodersen]

Well I disagree with that. The skills you learn in your spare time are 100% applicable to the job you are after as long as you make sure you solve “real” problems when learning it. Otherwise logically it would be impossible for anybody to get a first job since they (with no previous job) doesn’t have any skills :) I more than once have gotten a job based on skills I learned outside of work. I just made sure I could clearly demonstrate that I had the skills.

[kleiba]

I know what you mean but keep in mind that the kind of jobs you can score as a newbie are - for that very reason - also quite limited.

But just to be clear: no-one claimed that you cannot learn any new skills outside you work. The point was really more about the difficulty of demonstrating that you actually have said skills, and not just say you do.

[Dove]

The easiest transition is to learn a new skill applicable to what you're already doing. Tell your employer that your Cobol project is ultimately unmaintainable and they will have difficulty hiring Cobol engineers in the future. This is true and you both know it. Propose rewriting the system in Java (or whatever you want to learn, so long as it's a reasonable choice from an engineering perspective). They'll often go for it. Improve your odds by finding a small piece of the system to replace as a pilot project, where success on that small piece would offer immediate benefits like new automation options or the elimination of legacy equipment. If it's a small risk, they'll usually let you try, and if it works out, they'll often let you keep going. They don't want to be stuck with a project they suddenly can't maintain, and you're the best person to replace it -- not because you're a Java expert, but because you're an existing system expert. Find a low cost, low risk approach and it becomes a very good deal for them. They usually take you up on it (and are delighted by the opportunity), if they can spare the time and expense. Sometimes they really can't, and the answer for that is to be patient. And there's room here for going rogue and doing it without permission - I have done this many times in my career, and finding an opportune moment to say, "by the way, I had a slow week a while back and used it to make this more efficient and modern alternative for us" is almost always received well, especially if it just happens to be helpful with this week's painful problem. Skills used to tackle the same projects you already know how to do are both easy to move into, still take advantage of your experience, and are often easy to weave into your professional life. Boom, Java experience. The real beauty of this is that for your next job, they don't know you only have six months of Java experience. They see you worked at Corp for 5 years, you did Java there, and you can clearly do Java now. They don't usually ask too many questions.

A harder (but still pretty easy) transition is to work on something other people at your company are doing, but which you aren't. Perhaps there's a group doing big data and you want to get into it but you've never done it. Learning the skill on the job can be a hard sell, but it isn't always impossible. It's worth asking. Employers like working with smart people they already know, and can see it as a better bet to teach a known good guy a new skill than hire someone with the skill who turns out to be a terrible engineer. Some places will actually send you to school to get the certificate or whatever. However, this route often doesn't work because they genuinely can't afford to train you. Your odds of success go way up if you're willing to learn it on your own time. They improve even more if you can get pretty good at it. It helps further if the people on the team respect your intelligence and capability. The killer strategy is to make your preferences known, keep doing excellent work on your old system that no one else is willing to do, build up karma that way, get really good at the other thing on your own time and talk shop to the other team about their work, wait for a good time for the company. . . . your odds of eventually getting in are excellent. Boom, data science experience.

For something totally unrelated to what your company does, this is a lot harder. You have to both learn the skill and demonstrate competence on your own time. Your best bet is to build up a portfolio of accomplishments and side projects that you can share. This isn't the same as professional experience, but professional experience demonstrating you're capable, properly socialized, and people will actually trust you with stuff for years on end -- all of this still puts you ahead of total newbies, even if the specific skill is new to you. The truth is that talent is in such desperate demand (especially if you chose your new skill wisely) that interviewers are usually much more interested in whether you can actually do the work than they are in what your resume says. So just make sure you really can do it, and you really can prove that. Some employers really will insist that you have those 15 years of Haskell experience the job req says they want. But most of them will see solid general engineering experience on your resume, see during the coding portion of the interview and by looking at your public work that you really can do the job, and they'll decide you're probably the best bet they're going to get to fill the position anytime this year, and they really do need the help. Don't take "X years of Y experience" too seriously. If you really can Y, your odds are excellent.