Positioning for Scala or Lift jobs

Question

I'm starting to understand Scala and I like it a lot.

How can you position yourself to get a paying job as a Scala developer (assuming those become more common)?

• What parts of the Scala ecosystem have the best job potential (Lift, Actors?).

• How can you gain credibility with a prospective employer without being able to point to Scala work experience (maybe experience on open-source projects?).

(The above questions are hopefully of somewhat general interest to Scala folk. If you want to factor my particular situation into your response, here are a few details about me: longtime developer (mostly Java) with a Computer Sci PhD; not currently working; I'm tied to a non-cutting edge location (Rochester NY), so I may be limited to remote work.)

---

Update 2010/07/30:

Thanks for the responses. I'd like to crank up the emphasis on the location issue. I'm tied by family to a location that probably won't have Scala work locally for a long time. Are there realistic prospects for getting remote Scala work, and if so how do you position yourself to get remote work? (A modest amount of travel would be doable, but not a full-on road warrior.)

Also, I was wondering about leveraging my teaching background. Would teaching a Scala class at a local university make a big difference in one's marketability as a developer, or just divert more effort than it is worth?

Answer 1

Take your current job, and implement resume driven development. Just claim that xyz can't get done on schedule without Scala, and then use it. After that, take your project to success and either work elsewhere, open your own business, or continue developing Scala apps at your own company.

It worked for Dick Wall, so it should work for you. :)

Answer 2

I think your best bet is to get good at Scala and to get visible in the Scala community. These are not necessarily the same thing but luckily they are very closely related in the Scala community. Once you do this there are definitely opportunities to use Scala for fun and profit, whether as a consultant/contractor or as a (remote) full-time employee. As part of getting better and more visible I would recommend becoming active in one of the existing communities (Lift, Akka, ScalaNLP, you name it) or even going out in the wilderness and hacking away to solve a common problem, even if it's just making a native Scala alternative to a popular Java library (e.g. squeryl and Dispatch maybe weren't necessary but they're awesome).

I guess what I'm saying is that contributing to any good, useful Scala code will be good experience and I think the ecosystem is so young that there's no need (or benefit?) to specializing in only one part of it. Of course, if there's a specific subject that Scala is useful for and/or a specific field that benefits from Scala that jumps out to you, direct your attention in that direction.

Answer 3

Having had two full-time Scala jobs at this point, I'd say that the most important thing to do is learn the type system and the standard libraries inside and out. The individual technologies can then be picked up with relative ease.

Also, start using Scala (specifically Specs and ScalaCheck) for testing in your current project, today, if you possibly can.

Finally, as pr1001 said, get visible in the Scala community. Contribute to a project, interact on the mailing list, hang out in #scala on freenode, answer questions where you can.

Answer 4

Pure Scala position:

Finding a pure Scala position is not very easy, but it is getting easier and easier. I am going on my first pure Scala job interview in a few days.

I hope we will see a lot of new systems being written entirely in Scala, and I think these systems will be mostly back-end, heavy duty systems. These systems will be using Scalas less error prone functional style to reduce bugs. I think Akka, SBT and Specs will be important frameworks for the Scala developer (this is not much of a prediction since they are already important).

If you do not find a pure Scala position:

Your credibility comes from your time with Java. Most big companies have heaps of Java code that must be maintained and developed. If it is your job to babysit the old Java code, and as an old Java guru, you should have some say in how this should be done. The first step is to change the Maven setup to allow mixed Java/Scala environment. Moving to SBT is probably your best choice. This is a one time investment you have to do or else you can not proceed!

• If you work independently you could probably replace Java with Scala whenever you feel like, most likely when you have to re-factor some old code. Talk about Scala as a "framework" for Java (this is technically a lie) that boosts productivity when speaking to the non technical project manager, this might calm their worrying minds. In the end it will be your responsibility to see to it that Scala indeed integrates with Java. But since Scala does this very well it is not much of a problem. Actually, maintaining old legacy code is not a dream for anyone, so PMs are usually happy if they find anyone who would do it for more than 3 month. Management will probably put up with you rebellion.

• If you work in a team it is a bit more tricky. In this case you have to teach the team Scala, or else they will not be able to understand your code. You have to persuade your PM to set aside resources for Scala training (might be hard). When you introduce Scala to a team, start small. My experience is that it takes a while for a Java dude to learn Scala, so this is not done overnight. Therefore, ignore everything that is "hard" when you teach Scala. When the team grasps the basics, start with writing tests in Scala (thank Davetron5000 for this tip), continue to use Java for programming in the application (the production code). Hopefully the team will learn and enjoy Scala and after that, well, it is all downhill from that point.

Good luck!

Answer 5

If I was hiring at the moment, I can tell you right now what questions I would be asking and they would be about the language. It is a hard language to understand at a deep level, even if it seems easy to use and, as a consequence, you might be expected to understand code written in a large number of different styles.

Knowledge of libraries (Akka and Lift being the obvious ones) the sbt build tool is great but it is an extra. I would want to know that you understand:

• a bit (well, a lot) about the type system (and higher-kinded types)
• something about the typeclasses approach
• implicits and the pimp-my-library approach
• good scala style (i.e. idiomatic scala)
• recursion
• the actors approach to concurrency
• the standard libraries
• functional programming

If you understand the language, you'll pick up the libraries with no problems, I'm sure.

Other libraries:

• scalaz for functional programming
• scalala for numerical programming (linear algebra etc)
• scalaj for interacting with Java