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.

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.

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

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.

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.

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