I have been a backend elixir developer for about 3 years now. I have been mainly working on simple CRUD applications.
Context
As of last year I have been applying for elixir backend position; however, I have been unsuccessful in landing a job. After having been interviewed, I think I realize what I am missing: making architectural decisions in a complex system.
Its best if I provide a couple of interview questions to showcase what I mean in my above statement:
When should one use sql vs nosql? What are the pitfalls of each technologies? Are there any performance difference between the two?
You are tasked with creating a elevators as a service. Each elevator can go up, down or stop. Now how would you design this system using OTP? What are the pitfalls of the decision?
Those were some of the architectural questions I came across. Having a solid understanding of OTP I was able to provide a single high level implementation detail for the #2. But I was stumped when it came to determining the pitfalls of my decision. Furthermore, when pushed to answer similar questions I didn’t know how to answer it.
Question
What should a junior backend elixir developer do in order to gain experience to be able make architectural decisions in a complex system?
One thought that came to mind was, I should try to implement the system asked in #2 interview question. Even then I am not sure what I should put my focus on in order to gain the experience I need to land a job.
I apologize for the rant but I am stuck in my growth to become an experience backend elixir developer!
There’s no easy answer. To gain experience you need to spend time experiencing multiple situations. The experience you gain with side projects that aren’t really “in production” is helpful, but not the same as working for a company that has production systems.
This is a great talk @gregvaughn! A great showcase of what OTP is capable of.
You are correct here. At the moment any actionable advice is appreciated. With that being said, I able to extract the following advice from your response:
Watch more elixir conference video which discuss OTP and understand the reasoning behind the presenter’s idea and code. Furthermore, try to reimplement my own solution for the talk. E.g your elevate talk and the source code.
Indeed there is no easy answer but for me at least Erlang/Elixir’s main value proposition is the OTP (Erlang) and metaprogramming / macros (Elixir).
Invest in those. I am yet to read the “Metaprogramming Elixir” book (I have it) but I only hear good things about it. There are 2-3 really good books about Elixir + OTP in particular as well and I have one of them (I think by written by @JEG2).
It’s important to know your own learning style. Do you prefer the conference talk style, or a tutorial video, or would you prefer to read a book, or do you jump into a coding project and learn what you need as you go? Any of those can work.
One thing that I have consciously done in my career is to gain some understanding of the layer below where I’m actually working. For example, if you’re working in any web framework, you ought to know something about the HTTP protocol. If you’re working with Ecto.Changesets then it’s helpful to have an idea of what data is stored in there. Knowing these things help you gain intuition of what is easy/possible/impossible and help you have a mental model for when things don’t go as expected and you have to debug.
Making architectural decisions is just the how. I always start with why. Why do you have this particular problem that you are tasked to solve?
Why does the business want a new elevator service? Are the current solutions too slow? Is the problem actually optimizing elevator dispatch?
Similarly, understand the business can help choose between sql and nosql. Nosql or document databases are very flexible and works great for nested relations. Is that what the business data look like?
Also, design docs are necessary evil. You may or may not like them, it’s a tool for communication.
Sorry if all that seem too vague. I guess my point is you want to think like an engineer, so you have to understand requirements as well as the limitations.
Meta programming is also something on my list to review as well.
I believe you are referring to this book by @JEG2. I have read that book. It was one of those books that helped me become a mature developer. Helped to think through an application from data to GenServers.
You often needs to fail to learn some lessons. I even encourage trying to fail if possible
Listening a great talk or reading a great book - they are also essential eventually, but without tackling an actual problem they would remain an advice, not become your knowledge.
I agree with this. The question then becomes what kind of projects should one tackle in order to grow?
For CRUD application there are countless examples beginner developers can create in order to learn: To do list, blog website, restaurant and etc… There aren’t too many project examples for intermediate developers to practice on.
The first thing I tried to write in Elixir was an auction application for my fantasy football league. I built it such that it could support multiple auctions going on in different leagues concurrently. That felt like an intermediate introduction to Elixir and especially OTP. Since then I have worked on a charting library and a little toy Phoenix app that demonstrates that library.
From all of that, the advice I would give for a learning project order would be:
Pure functional library
Project that uses OTP (if it needs a database, just use ETS)
Project that uses Ecto
Project that uses Phoenix (these last two could be reversed. My Phoenix project doesn’t use a database and that has made it much simpler)
I think not starting with Phoenix made Phoenix much easier to understand at an intermediate (as opposed to “I know who to write a CRUD app with it”) level once I got to it.
You may do toy projects (such as elevator example from the interview), or try to do different approaches at work even you already know “some” pros/cons already.
Of course it may be a little bit difficult to find right sized project ideas. You may explore them by tech (e.g. OTP) or by domain (e.g. real-time game) if you don’t have enough opportunities for experiments at work.
Typically you can learn a lot even at work by doing under/over-engineering
The answer very much varies from company to company. Just keep trying and get feedback from the interviewers. Learn what they where looking for and why did they think you wouldn’t provide it instead of focusing on specific questions and answers.
Discuss with other people in team. Such decisions shouldn’t be done authoritatively by anyone (doesn’t matter how much “seniority” they have). So if you want to have “real influence” on architecture, then discuss with the people who are making these decisions right now. At the beginning questions like “why?”, without any additional input, are good as well for 2 reasons:
Sometimes it isn’t obvious that this approach isn’t the best, and good question “why?” can force small rethinking.
If there is good reason “why” then they will tell you, so you will gain more knowledge for yourself and you will make small step towards being the one answering instead of asking.
Build the Game of Life without using any processes. Try to minimize the cells processed in each new generation.
Build any moderate sized project while pairing 100% of the time. Trade driving so it’s 50/50.
Build a chat application using only what ships with Elixir (and Erlang). The app should be able to “Host” or “Join” an IP that’s currently hosting. Make sure I can receive messages while I’m typing one.
It’s funny, when learning elixir and backend I went the opposite direction of your recommendation. Which I think is okay. But now if I want a more solid understanding of OTP I agree with your ordering. With your response, @chulkilee and @JEG2 I believe I have the example projects to tackle.
My personal strategy for growing quickly was to always pick the hardest problems/tickets that were available. Always jump into the deep end, but have a lifeguard around i.e. a more senior developer who can help you if you get stuck. It’s hard to grow if every problem is familiar to you.
