At this point I’ll second another poster above – just go through the Exercism.IO track. You’ll even have to implement part of the Enum module. It’s a very good, hard, solid training in FP and Elixir in particular.
dimitarvp
6
LostKobrakai
The resources I’d suggest for learning how to design better with processes in mind are Elixir in Action, Building Resilient Systems with Stacking, The Hitchhiker's Guide to the Unexpected.
I don’t think coding challenges, like the ones found on exercism, do a particularly good job at teaching those things. This is mostly because the benefits are hardly in the ballpark of “code up a working solution”, but much more in the ballpark of “make it work (long term) under real world conditions where things will fail”. Many of the gained properties of a well designed system of processes are really tricky to “prove” by simple unit tests.
The only place I generally see where traditional coding challenges can benefit from using multiple processes is by making things parallel – for that Task.async_stream is usually plenty enough though.
9
dopomecana
Great point, thank you @LostKobrakai! Does anybody have any more recommendations like the ones LostKobrakai gave?
0
egze
What I am observing: It seems you are not at a senior level in the current company and the company does not have the means for you to grow as an engineer. So looking for a new company that has this capability to offer you a career path is a good start.
I would try to find companies that have a clear path. Example: Square https://assets.ctfassets.net/1wryd5vd9xez/6bDnTwb4H7bfiFvg55ldRR/b1cb8514f0afd0a4050991d35ccbac03/Square_Software_Engineering_Career_Ladder.pdf
It’s a good sign that you would get what you want (career growth).
Then when you find such companies, apply for a mid-level or junior position. You are not senior yet and you should prove it first that you are capable. If you see the career path from Square, you’ll see that knowledge of a programming language is not really important. Much more valuable is the collaboration in your team/group, ownership, ability to organise people around you, the way you behave and bring ideas across.
The language/technology is also important of course, but I wouldn’t put much focus on Elixir specifically.
4
jamesarr
Yeah, I’m mid-50s and find it ridiculous how some companies perceive themselves.
“Are you on the verge of curing all cancers?”
“No.”
“Are you about to crack cold fusion?”
“No.”
“Well, what do you do?”
“We’re the 21st century equivalent of someone selling fill dirt, but it’s digital fill dirt. "
“Oh, okay. That’s fine with me; I can help you with that.”
“Well, you don’t seem very EXCITED about selling the dirt…”
'That’s because I’m a reasonable person.”
19
Oliver
@dimitarvp has some excellent points, his post being shared in the newsletter brought me here.
Interviewing can fail in many stages, and different employers can have wildly different approaches. I was an absolute shoe-in for one position, both to their and my benefit, and then I bungled the money negotiation and they stuck with their low offer and it never happened. So each step needs some being prepared. Interestingly they didn’t do one of these silly “So, how would you code this?” interviews which I loathe. They wanted to see some github code that I wrote, so I showed them some Haskell I had written for a private project. It helps to have something to showcase for those who are more real.
But those were perfect conditions, and I bungled it. Now consider most interviewers, they are just a waste of time. What kind of skill is it to have immediate solutions for random algorithmic problems in your head? Some companies are truly beyond the pale here, and it’s just bloody stupid. When you get one of those interviewers, just know they have no real ability to assess you, and unless you want to join “coding leagues” in your spare time, see it as a lottery: You either know what they ask you and can implement it in short order, or not. It’s like a random test for some college level material without having had a course before or knowing which will come up.
I had an argument with an interviewer once over what OOP was. Turns out my definition was matching up with Wikipedia, but he did not hear a word he wanted to hear. The whole interview was dominated by his false assumptions and by the end of it I didn’t want to hear from them again.
Going away from the weirdness and arbitrary nature of interviews, here’s how I got senior:
I try my best to keep my code short and readable, and if I find myself writing too much code I look for ways to fix that. So this led me through most of the Enum, List, Map, and Stream APIs, higher order functions, eventually macros, and writing code that generates elixir files for compilation, etc. The actual human-maintained part of my codebase has only grown by about 10% in two years although we keep adding features, and the generated code is many many times bigger than the human-written one.
elixir is an incredibly capable and fast string processing language, for example, I’d never have guessed. And there’s a lot of tools for code generation, including compiling code on the fly. In OTP20 I used macros to create functions that return constant terms so they would go into term storage and be looked up in constant time. This would compile at runtime. In OTP21 they introduced a key/value API for accessing the term storage safely and with concurrency-safe deletion if you need it, and I replaced all my code because this solution had more capabilities and was shorter. Yes, I deleted some cool code. But the project didn’t need it, nobody would have to maintain it anymore, so out it goes.
That is very vital IMO: When you learn to do better, refactor your code base to be better. I was the first person to code elixir at my department, others learned along. They had gotten the hang of recursion and were comfortable with it when I finally understood how OTP works. It was really back-to-front for all of us - until we got it, of course - now we can hardly remember working any other way. I realized how much the OTP callback module pattern cleans up code, and rewrote eventually everything to make use of it where it made sense, which met some resistance from coworkers, but we were all better for it in the end. For comparison: Another department more on the research side we got into touch with later couldn’t figure out OTP and gave up on the whole of Erlang even though it fit our domain perfectly…
If you see a better way, keep applying it until you find the next better way. So we went from writing our own recursions to OTP and List/Enum/Stream, then on to get_in/2 and update_in/3, we redid the way we work with conditions and case/if/cond and &&/|| statements many times, we eventually used more function captures where it didn’t affect readability too much, and most of all, I tried to pipe everything and optimized a lot of code for that.
I recently wrote a specific framework for state machines in our project because I wanted this part of the code, the actual tests in a testing system, to be more declarative. While I like gen_statem I didn’t like what it did for readability in those parts of the code, and I probably have had four implementations by now for receiving multiple messages in one join state because I wasn’t pleased yet.
That’s how I got “senior” (the term has no real meaning in my company, I just felt that at some point I definitely crossed that mark for elixir). I never settled, code-wise. I want code to become more readable, shorter, reasonably efficient. I want computers to do repetitive work instead of me handwriting code over and over again. Sometimes that means reading elixir source code from the language itself, which has some constructs I always find make the code obscure, but it teaches you a lot.
5
dimitarvp
Yeah, I heard that probably 100 times during my career. But I think we all know “excited” is a code word for “you don’t seem to be completely brainwashed by our half-arsed propaganda about why you should work harder than ever while working for us”. 
For some reason employers are terrified by professionals who are reasonable and don’t immediately fall in love with their product / business / team just from 1-2 interview mettings. Likely because they realize they aren’t offering a fair deal and are afraid that you’ll realize this and leave early?
But seriously, how am I supposed to get excited by being exposed to the outside layers of your company for an hour? It just ain’t happening and at one point I got tired of pretending that it is.
I definitely am getting older and more cynical but all of these are empirical observations that have been true exactly 100% of the time during my 19.5 years of career with and about 10 employers and contracting customers, plus 40+ of them I chatted with and interviewed for.
2