Search This Blog

How to Get a Haskell Job

Over and over again I have seen people ask how to get a full time job
programming in Haskell. So I thought I would write a blog post with tips that
have worked for me as well as others I know who write Haskell professionally.
For the impatient, here's the tl;dr in order from easiest to hardest:

IRC

Local meetups

Regional gatherings/hackathons

Open source contributions

Work where Haskell people work

First, you need to at least start learning Haskell on your own time. You had
already started learning how to program before you got your first programming
job. The same is true of Haskell programming. You have to show some
initiative. I understand that for people with families this can be hard. But
you at least need to start. After that, far and away the most important thing
is to interact with other Haskell developers so you can learn from them. That
point is so important it bears repeating: interacting with experienced
Haskell programmers is by far the most important thing to do. Doing
this at a job would be the best, but there are other things you can do.

1. IRC. Join the #haskell channel on Freenode. Lurk for awhile and follow some
of the conversations. Try to participate in discussions when topics come up
that interest you. Don't be afraid to ask what might seem to be stupid
questions. In my experience the people in #haskell are massively patient and
willing to help anyone who is genuinely trying to learn.

2. Local meetups. Check meetup.com to see if there is a Haskell meetup in a
city near you. I had trouble finding a local meetup when I was first learning
Haskell, but there are a lot more of them now. Don't just go to listen to the
talks. Talk to people, make friends. See if there's any way you can collaborate
with some of the people there.

3. Larger regional Haskell events. Find larger weekend gatherings of Haskell
developers and go to them. Here are a few upcoming events that I know of off
the top of my head:

The first event like this that I went to was Hac Phi a few years back. Going
there majorly upped my game because I got to be around brilliant people, pair
program with some of them, and ultimately ended up starting the Snap Web
Framework with someone I met there. You might not have a local meetup that you
can go to, but you can definitely travel to go to one of these bigger weekend
events. I lived a few hours away from Hac Phi, but I know a number of people
who travel further to come. If you're really interested in improving your
Haskell, it is well worth the time and money. I cannot emphasize this enough.

4. Start contributing to an open source Haskell project. Find a project that
interests you and dive in. Don't ask permission, just decide that you're going
to learn enough to contribute to this thing no matter what. Join their
project-specific IRC channel if they have one and ask questions. Find out how
you can contribute. Submit pull requests. This is by far the best way to get
feedback on the code that you're writing. I have actually seen multiple people
(including some who didn't strike me as unusually talented at first) start
Haskell and work their way up to a full-time Haskell job this way. It takes
time and dedication, but it works.

5. Try to get a non-haskell job at a place where lots of Haskell people are
known to work. Standard Chartered uses is Haskell but is big enough to have
non-Haskell jobs that you might be able to fit. S&P Capital IQ doesn't use
Haskell but has a significant number of Haskell people who are coding in Scala.

Comments

Great post! Thanks for this topic and the tips you shared. For the past few months I've made it a goal of mine to learn Haskell. The steps I've taken are as follows:

1) Complete all the http://exercism.io/ problems in Haskell. I've been dedicating 1-2 hours each morning before work on this.

2) I've been going through reading "Haskell Book" and practicing by going through the programming exercises.

I have a few questions:

Q1) I think it would be a good idea to have a pet project to work on. There were a couple of ideas I had:

1) Sudoku game solver2) Machine Learning Algorithm to solve given a sample dataset (Ex. Calculate future population of United States based on historical data using Linear Regression algorithm)3) Todo list web app

What are your thoughts on these ideas? I want to choose something that is an easy win yet something I will learn from, yet not be too challenging at first.

Q2) I think it is a good idea to niche down in a particular aspect in Haskell. I was thinking of Machine Learning in Haskell. Is that a small enough niche or too broad?

Of those three projects, I'd recommend the web app because the other two are much more narrow in scope. The web app isn't necessarily larger or harder, but it will demand that you learn a larger set of things that are closer to what you will typically need to use in real world development.

As far as the niche goes, I can't really say. I'd focus on doing something that motivates you a lot and that also has real world value.

Popular posts from this blog

On a number of occasions over the years I've found myself wanting to generate realistic looking values for Haskell data structures. Perhaps I'm writing a UI and want to fill it in with example data during development so I can see how the UI behaves with large lists. In this situation you don't want to generate a bunch of completely random unicode characters. You want things that look plausible so you can see how it will likely look to the user with realistic word wrapping, etc. Later, when you build the backend you actually want to populate the database with this data. Passing around DB dumps to other members of the team so they can test is a pain, so you want this stuff to be auto-generated. This saves time for your QA people because if you didn't have it, they'd have to manually create it. Even later you get to performance testing and you find yourself wanting to generate several orders of magnitude more data so you can load test the database, but you stil…

Think of a time you've written tests for (de)serialization code of some kind, say for a data structure called Foo. If you were using the lowest level of sophistication you probably defined a few values by hand, serialized them, deserialized that, and verified that you ended up with the same value you started with. In Haskell nomenclature we'd say that you manually verified that parse . render == id. If you were a little more sophisticated, you might have used the QuickCheck library (or any of the numerous similar packages it inspired in other languages) to verify the parse . render == id property for a bunch of randomly generated values. The first level of sophistication is often referred to as unit testing. The second frequently goes by the term property testing or sometimes fuzz testing.

Both unit testing and property testing have some drawbacks. With unit testing you have to write fairly tedious boilerplate of listing by hand all the values you want to test with. Wit…

As almost everyone with significant experience managing production software systems should know, backwards compatibility is incredibly important for any data that is persisted by an application. If you make a change to a data structure that is not backwards compatible with the existing serialized formats, your app will break as soon as it encounters the existing format. Even if you have 100% test coverage, your tests still might not catch this problem. It’s not a problem with your app at any single point in time, but a problem with how your app evolves over time.

One might think that wire formats which are only used for communication between components and not persisted in any way would not be susceptible to this problem. But these too can cause issues if a message is generated and a new version of the app is deployed before the the message is consumed. The longer the message remains in a queue, redis cache, etc the higher the chances of this occurring.