What makes a strong Elixir engineer beyond Phoenix experience?

Chat & Discussions Chat / Discussions
1

I’m relatively new to the Elixir ecosystem, coming from a Ruby on Rails and JavaScript background, but over the past few months, I’ve built around 8 production-ready demo projects with Phoenix and LiveView, all going beyond simple CRUD, with real architectural considerations.

One thing I’ve noticed is that Elixir hiring signals seem a bit different from more mainstream ecosystems, so I wanted to get a sense from people working in the field:

When you’re evaluating Elixir candidates, what tends to matter more in practice: strong personal projects that demonstrate OTP and distributed systems thinking, or contributions to established open-source projects in the ecosystem?

More broadly, what actually differentiates someone who “uses Phoenix” from someone you’d consider a genuinely strong Elixir engineer in a hiring context?

4 Likes
2

Nerves experience. Ash experience. Membrane experience. At least 5 years of Hologram experience

jokes aside

In the current market my impression is that people hire almost entirely on trust and relationships. These are best established by having worked with people. When that isn’t applicable open source contributions are a very decent proxy to many people. Demo/hobby projects are way better than nothing but also doesn’t say a ton, especially in the last year or two with LLMs being able to do so much.

I’d take significant contributions over apps you’ve built any day because contributions require interaction with other people and I could look at the back-and-forth or a larger history of work exchanges. Collaboration, communication and feedback processes are pretty important.

15 Likes
3

Thanks, this is genuinely useful advice.

The point about open source being a proxy for trust and collaboration makes a lot of sense, especially the ability to see communication, reviews, iteration, and long-term contribution history. I hadn’t thought about it that way before.

Do you have recommendations for good Elixir/Phoenix open source projects that are welcoming to contributors? Especially projects where someone can realistically grow into meaningful contributions over time.

4

GitHub - bartblast/hologram: Full stack Elixir web framework that intelligently compiles Elixir client-side code to JavaScript · GitHub is still “fresh” but well-established, the creator is very welcoming and encourages contributions as code as well as consults the community here on the forum to help shape the direction. Plus, it’s nice to look under the hood of compilers. If the framework’s stance on the web stack resonates with you I’d say it’s a perfect project to contribute to.

4 Likes
5

This depends so much on what type of effort is more satisfying to you. Phoenix has open issues you can find and address and Steffen who does much of the Phoenix work came in just fixing assorted LiveView stuff and grew to where Chris is pointing to him as the de-facto primary maintainer of Phoenix now. A project like Phoenix doesn’t break a lot of new ground, it is way more about maintenance.

A project like Hologram is continuously breaking new ground. Then there are things where you can build up more niche skillsets that really distinguish you from the overall crowd of web devs. Membrane is all about the media domain and while there is a lot there there are way more elements that could be built out and either contributed towards the main project or offered as separate additions.

Nx is pretty quiet currently but Paulo Valente is pushing it along and there is definitely stuff that could be done all over the place there if you have the skillset or inclination to learn it.

Nerves is steady but there are always new areas to cover. BEAM Bots is brand spanking new so that’s about breaking new ground and stabilizing the current patterns through actual use.

The more niche stuff is a balancing act. People can decide you are overqualified or don’t know the usual web/SaaS stuff because you are doing embedded or whatever. But it also means you are in a different pool when applying for positions.

This all to say. There is no easy answer. You have to care about the thing you are contributing to in one way or another to make it worthwhile. The exchange rate between open source contributions and job offers is incredibly weird, vague and uncertain. But it is also the case that many of the people who are known contributors, who show up for conferences and who collaborate in various ways around the community tend to stay employed in the ecosystem. Your contributions and collaborations build up fibers and those fibers can become your network over time.

6 Likes
6

I would also strongly advice to not use LLMs to write posts, PR descriptions, comments, CV, cover letters, etc. People really really don’t like that and it’s very noticeable.

9 Likes
7

I like when the dev knows how to solve a DBConnection error output in test environment, because that tells me they know message passing.

Another example is when the developer tests a genserver by spinning off an isolated one for each test case, instead of using the process hooked to their supervision tree, so that their tests can be async false.

When they use CaptureLog in an async true test, I already know they aren’t senior in elixir. The amount of async false tests someone writes is also a great metric of how bad elixir developer they are.

2 Likes
8

can you remind me what’s the problem there? I’m probably deeper than most in the topic of testing loggers, but I don’t immediately recall what’s wrong with CaptureLog.

1 Like
9

Logs are global state (due to being being output on a shared canvas). Very easy to produce flaky tests asserting on them.

I had to replace at least 50 test expectations with proper assertions all over our system because a year ago somebody wanted to just code a feature and move on.

So I’m with @alexandre here. To me relying on logs in tests is a negative signal about the dev who produced the code.

3 Likes
10

Interesting.

11

I’ll echo with others that my first stop is to see if any of my former colleagues are looking for work, and then if I see people on LinkedIn that are former colleagues of other former colleagues, I’ll check to see if they’re good and then maybe encourage them to apply.

I’d say that maybe 10% of the time that it works out that way.

The majority of the time it’s a job post, hopefully here on the forums or on slack. Maybe sometimes on one of the aggregating sites that are Elixir specific.

What makes people stand out in those first rounds is obviously experience, and yes, having experience with using OTP concepts is better than just Phoenix, but I’m generally looking for scenarios where it’s obvious that they know when to use a GenServer or Task and when to not use them without planning, since then you have to solve for consistency/distribution concerns.

Generally, I’m just looking for a signal in their resume that they’ve done something more complicated and done it well. If they’re a contributor on a well-known package that indicates they have some particular knowledge along those veins then that’s great. If not and they have side projects or something that they have done that illustrates they understand the nuances of OTP, or know how to model a very complex domain either at the operational layer or at the persistence layer.

If I had to choose between deep knowledge of OTP for deep SQL understanding and importantly when to NOT write a gigantic query or over normalize, hey julia, I think I would probably choose SQL/persistence.

If I’m hiring someone who’s a senior, I’m expecting decently deep knowledge on both sides and in that case I would probably defer to how complex the thing I’m building is.

If I’m building something with an integration engine and a generalized schema where most of the domain modelcomplexity is going to be in mapping so that the define their own level of complexity with the mapping, then I almost certainly want someone with a lot of OTP experience.

If I’m building a product company where there may be integration pieces but for the most part I am trying to make it easy to model the business domain, I’m going to go for SQL experience. Nowadays I would probably also go for Ash experience as a proxy for this, but I would want to make sure that they understood why Ash is a value-add in that space. This one’s important because I’ve seen too many companies get hamstrung by an early employee’s overeager and overnormalized modeling of concepts that leaves no room for easily migrating away and no abstraction layers. So everything becomes way too intertwined, and you end up with really complex Multis, or 300 line queries, or worst but sometimes easier to fix, no transactional integrity. And no good way to isolate the different parts.

So to stand out, I’m generally looking for evidence that you’ve solved a hard problem and you understand the different complexity trade-offs, and that you were able to preserve flexibility in whatever the solution was.
Just open-source for open-source’s sake is not something I would expect to see on someone going for a senior or higher role unless the open source they’re doing is an extremely high level library in something that they are very good at.

3 Likes
12

The best way is to inject IO, through a function or a module, and assert or refute it was called. Unfortunately, I haven’t seen anyone do it besides me.

13

But it’s quite easy to do?

The reason I am not doing it is that I am not interested if our code logs something during its work; I test the desired results and side effects. I could probably add mocked logging in the very few places where the code goes through recoverable errors by design and is supposed to Logger.warning something but that seems over-zealous and just increasing code coverage % for not much gain.