Becoming an intermediate elixir developer

Hi

Forget about Elixir (it’s just another programming language).

Forget about landing another job (it’s just another job, you won’t be happy).

Read everything and study 24/7, stay curious so you can create opportunities for yourself. Good luck!

As to the questions…

1. The SQL vs NoSQL question makes absolutely no sense without context (traffic level, structure or structureless-ness of data, concurrency model, etc) and a proper architect would study the actual underlying problem closely before providing a solution.

2. I’d probably use a bunch of processes and model each door and each carriage separately, as a starting point. Could model riders too.

LOL! That’s very true though, being terse requires more thought.

Ha, thanks. I’ve always been a fan of this quote from Mark Twain:

“I didn’t have time to write a short letter, so I wrote a long one instead.”

I should probably pay you to teach me how to express myself so concisely.

I was about to say almost the same as you but mine would have been 3x bigger…

One thing that could be useful to do with toy projects is to load them with tons of data and see if your original design decisions continue to hold true. Just seed your database with a million entries of each type and see what impact it has on performance, memory, UX, etc. Then try to make it better. You’ll learn a lot!

I should preface that I am not at all a fan of interview questions like the ones you posted. Those questions fall into the category of “depends” where you could write a short book explaining all the options and rationale for each (as many have). Often, those questions have less to do with testing your knowledge, and more to do with whether you think like the interviewer. Some are even “gotcha” questions there to inflate the interviewer’s ego.

To answer your question about gaining experience, my personal experience has shown that biting off way more than you can chew is the best way. Jump into the deep end on something. Doesn’t really matter if it’s a toy project, a startup where you’re given way too much responsibility, a premature promotion, etc.. They all serve the same purpose. Books are fine for reciting academic sounding answers, but you need real-world, in-the-trenches experience with things like OTP to know how to really use it.

When you are back-end engineer, database knowledge and when to apply which kind of database persistence technology (e.g. key value store vs graph database) is absolutely crucial. To answer your immediate questions:

1. When to use SQL vs NoSQL depends on the data and its properties regarding transactions, consistency, schema and I would add the maturity of the database architecture with relation to its web architecture.

Use SQL: If the Data needs to follow ACID properties, requires strong consistency and there is a strong need to maintain relationships (e.g. JOINS etc.), you should use a SQL database aka a Relational Database (RDBMS) e.g. financial and banking transactions. Examples of common SQL databases are PostgreSQL or MySQL.

Use NoSQL: If the Data does not need ACID properties or follows BASE properties and can work with eventual consistency and does not have any apparent schema or relationships (this is typical for startups where they don’t know even know their data schema for anything including transactions) a NoSQL database like MongoDB would fit here nicely.

I will argue now, there is now a 3rd category called NewSQL or Distributed SQL which kinda of marries both the good parts of both SQL and NoSQL databases e.g. Google Spanner, Yugabyte and FaunaDB. Yes I can have my cake and eat it at the same time thanks to NewSQL. However, as I am learning the hard way, lots of teething problems with this kinda of technology.

If you like to learn more about these concepts, I recommend this course: Scalability & System Design for Developers - AI-Powered Learning for Developers

If you look past the apparent bias of the course author’s towards Java and Node.js you will be fine and you will gain a 50,000 feet of all web architectures (monolith, micro-services, and hybrids versions of them).

2. For your second question, its about capturing state and transferring it back and forth and the best resource that I have found is the ElixirSchool content to gently introduce the topic and then jump into the book ‘Designing Elixir Systems with OTP’. In fact, OTP is so foreign to most software developers. For example if your interviewing in a non-BEAM/Elixir/Erlang shop, they may ask you explain it.

Always be ready to white-board anything and if you don’t understand during your interview. Be fearless and ask them to repeat it and talk aloud about your process for answering it loudly. Sometimes the method is more important than having the actual answer in hand. Anybody can google and get the answer but alot of problems you will not be able to google it and have to apply some kind of reasoning behind it.

P.S. I am hiring a backend engineer for my current business if you are interested.

Yep, this circles back to the observation of some of us around here that most seasoned Elixir devs are “refugees” from other technological stacks where they got very painful schooling and learned their lessons.

I’ve been listening to some Elixir podcasts (and other software podcasts, too) in my free time and I’ve noticed that the topics, while related to the language, are usually about software engineering in general. The Elixir community has a lot of smart people in it and hearing some of their experiences really exposes you to new topics that you’d otherwise only hear about further in your career.

This doesn’t replace actual experience, of course, but I feel like it’s a nice addition to my efforts.

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.