How to become a senior in elixir?

The title of this topic may sound silly at the first glance. But why I trying to ask you guys is how to go to the next level?
I am currently working for 3 years and a half at company and I don’t know how to evolve more.
When I started elixir I was working with 2 teammates but there was not much guidance from them and since last year I am alone on the elixir project and I feel like I cannot surpass a certain level.
I had a few interviews but I managed to fail almost all of them.
I like learning, in general but without guidance related to what a interviewer wants from you at the interview and then later on the job it’s hard to go to the next level.
I would love to go to a new company were I can level up my knowledge while keeping at least the same salary.

The elixir community it’s great, and I hope I will get some good answers from you guys that will help me go forward in assessing my level and formulate a plan for the next step.
Also this may be helpful for others like me.

Thank you,
Michael

11 Likes

Head up, man, you are not alone in that situation. I feel exact the same, but with ruby. What i’m doing: just “doing”, learning and trying. And what will help you(i’m just sure) is this one - https://www.algoexpert.io. Check it out. There are no elixir tests, but no one can stop you from building your solutions outside their platform. After a couple of months you WILL be skilled enough to find a job. Just come back in a couple of months and tell :slight_smile:

5 Likes

thank you for your answer!

2 Likes

I’m not proficient enough in Elixir to give you specifics, but how about some general advice?

It sounds like you’ve hit a plateau, and the solution is the same be it weight lifting, programming or your career. The important thing is to switch things up. Don’t create the same kind of solutions to the same kinds of problems over and over, but challenge yourself by exploring new domains or new styles. For instance, if you’re not comfortable with OTP now’s a good time to time to work on that. Or if you’re only creating web backends, try out some AI problems.

And don’t take interview results as a sign of anything. Interviewing often has nothing to do with the work you’ll do, and in many cases it’s just rolling dice or having to spend a lot of time on developing skills that have no relevance to the work you’ll be doing later. Getting good at interviewing is a different thing than getting good at Elixir or getting good at software development.

Oh and some practical advice for you: start to read code that others write and go through some books that might give you a different perspective. Try to put it in practice, and always ask yourself if there’s a way you could’ve made it even better.

18 Likes

very helpful, thanks a lot

1 Like

I am completely with @jonas_h here – failing an interview means almost nothing. At 41 y/o and being a programming polyglot with a very successful career, I still failed at least 5 Elixir and 3 Rust interviews in the last two-three years and all except one I “failed” simply because people expected and wanted another kind of human character as a colleague and not mine (the so-called blanket statement of “a cultural fit”), or, very often, they were not thrilled that I am not super-duper enthusiastic about their company – this you will likely go against, a lot. There was only one interview I actually failed on technical merits and I still slept quite well that evening because it was an algorithmic problem that I haven’t stumbled upon in like 10 years and because yeah, should I sleep with the “How to beat the coding interview” book under my blanket for my entire life?

Still, your situation gives you two potential vectors for improvement:

  • Diligently write down all the technical assignments you were given and chase them to perfection on your own time, post factum. If the assignments were confidential (they almost always are) and you can’t just post them on your GitHub then break them apart on smaller tasks and ask the community (ElixirForum, Slack, Discord) whether your code can be improved. Pretty sure that alone will get you quite far.

  • Get better at interviewing. First step: understand that people usually don’t care about what you can offer. They say they do but they are looking for certain keywords while you are chatting (plus trying to evaluate your character and/or look if you are excited). Instead of playing a guessing game, try to extract the following piece of information and to project the following message: “you guys tell me what you need and I’ll give you an honest answer if it excites me”. Mind you, don’t say that directly. :003:


Here’s a cliche: do many interviews. A lot of companies will waste your time and never even give you a single word of feedback (“ghosting”) so, you know, don’t lose your sleep over the fact that you could waste a few companies’ time. Open that camera, put those headphones, put a nice shirt, be well-fed (being grumpy because of hunger is real), and do that interview! You’ll learn a lot.

As for Elixir coding in particular… well, I am one of the people around here who absolutely loves helping people improve their code. Post a small GitHub project and ask for feedback. You can mention or DM me directly as well.

But if you need an entirely new set of problems to work on, I might not be the right guy. Hopefully others can chime in on that.

30 Likes

Thank you for your reply, your detailed answer it helps me a lot actually and I think I’m not the only one here. You gave me some good pieces of advice that I’ll try to follow. Thanks again for building such a good community.

2 Likes

Getting more Elixir experience with feedback will help immensely with your confidence, credibility, and ability to answer interview questions. A few ways to do that:

  • Find an open-source project, in Elixir, that gives decently thorough feedback on pull requests – that last bit will be difficult and tedious to check, but at least narrowing it down first to Elixir projects will help, and maybe some people (not me) can make recommendations.

  • Do the exercises on Exercism.io – and ideally also ask for mentoring there. Specifically ask your mentor on each exercise to be thorough – rather than a cursory “looks okay to me”, ask them to tell you what’s not quite “standard” idiomatic Elixir, what could be improved, what might be a more appropriate Elixir (or for that matter Erlang) function to use in various places, etc. If your mentor is very patient, perhaps even go “above and beyond”, extend the program into other related functionality, including writing tests for that, and ask your mentor for feedback on your additions.

  • On a related note, to get better at testing if you think you need that, when you download an Exercism exercise, don’t look at their test suite yet, just the README containing the “requirements”. Write your own test suite first, then “compare and contrast” with theirs, and try to make the code pass both yours and theirs.

  • Penultimately, the advice Bryan Liles gave me when I was trying to break into Ruby: blog! Yes you may be fairly new to it but there are others even newer, plus you may happen to stumble across, or even think up on your own, something particularly interesting.

  • Lastly, take that “educate the public” idea to the next level and speak at conferences. Again, you don’t have to be some big expert, you just have to know a little bit more than the audience, enough to make the talk worth their time, and then be able to convey that extra bit of knowledge to them. This has extra benefits of name recognition, cachet, and you might even get free (or at least tax-deductible, if you’re a freelancer) trips to interesting places. If you aren’t already confident of your public speaking skills, I recommend first Toastmasters International, and then specifically for conference-type talks (which are much longer and usually involve more visual aids than a typical Toastmasters talk), “TED Talks: The Official TED Guide to Public Speaking”.

7 Likes

I’m completely agree wih all of you, guys. Preparing just for interviews without knowing the core things is absolutely stupid. But this isn’t “I know not enough” case, this is “I think that i know not enough”, at least it was my case. It’s not easy to know “not enough for any interview” after a couple of years production experience with a language, especially with such an attitude to learning as dopomecana has. What he is really need is to structure all the knowledge and to understand that he knows more than enough, because holistic picture is what is really checking on interview(at least on adequate ones, in my opinion). Getting that holistic picture helps me a lot to understand why Elixir/Phoenix and their parts in particular made the way they are made. And it was extremely useful for my level as a programmer and for my confidence as well . This is just my expierence :slight_smile: But I think it is pretty close to dopomecana case.

2 ways:

  • get old
  • move to Spanish speaking country

:wink:


Jokes aside - senior is someone who knows language well (so is mid) as well as they are able to do architectural decision.

For me senior is someone whom mids will ask if they will have a problem with code.

5 Likes

That’s precisely what I need. I didn’t meant to say that I’m only need to know more in order to get a new job aka succeeding in a interview, but I meant to say that I want to learn more, to have that holistic picture for me, because I like learning, but I cannot do that since I’m all alone working on a project and the rest of my teammates are doing imperative programming.
So maybe because I work in an environment with an imperative programming mindset where processes are not that used as we do in Elixir makes me finding solutions that are not so Elixirish.
At my last interview I had to design an zapier clone, not implement it, just casually talk about how I can think about it. And both during and after our talk I got the feeling that what I described can definitely work but it’s not how an Elixir programmer would do it. The feedback was that I’m a likeable person but despite that my technical level it’s a little bit under what they are looking for.
And again it’s not only about the interview, if I could learn more by myself without needing to change my job I wouldn’t be unsatisfied with the money I currently make.
What motivates me it’s growing as a developer. Because I feel I reached a plateau like @jonas_h said earlier. And I’m not just posting here and complain about it. Right after the last interview I started reading more, I finished Adopting Elixir(I can’t believe I didn’t read this before) and now I just started reading Mastering Elixir. And not just reading, I’m watching more and more videos presentations about how other people are handling applications design in Elixir. And the reason I posted here is that I felt in the same time that is not enough and I need to interact with you guys and see how you would handle this if you were in my shoes. And I got some pretty good suggestions from you guys and there’s for sure value in both your technical advices and in your general developer/life advices that I couldn’t find in any book I read. thank you!
I created a new topic to see what I missed over that zapier design if any of you could drop a few lines I would be grateful: How would you build a zapier clone in Elixir?.
And again thank you for your advices, @davearonson listed some good ideas which I can follow next.

4 Likes

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.

6 Likes

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 Likes

Great point, thank you @LostKobrakai! Does anybody have any more recommendations like the ones LostKobrakai gave?

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 Likes

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.”

18 Likes

@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 Likes

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”. :003:

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 Likes