elixir interview questions

CTO at Curiosum Micha Buszkiewicz was a guest on Krzysztof Kempiski’s podcast POIT (“Porozmawiajmy o IT”/”Let’s talk about IT”). Although the interview was conducted in Polish, the topics covered during the meeting were so fascinating that we decided to make an English transcription for you.

We disprove the notion that functional languages are more challenging than object-oriented languages. Read on to see if Elixir is a good programming language to start with for your project!

Greetings! My guest today is the co-founder and CTO of Curiosum, a Poznan-based software company. an authority on the Phoenix framework, the Elixir language, and related technologies Prior to this, he had mastered the art of designing Ruby on Rails applications and had a passion for creative solutions. Ruby, Rails, Git, SQL, JavaScript developer trainer. Currently, inside Curiosum, he trains Junior Elixir Developers. Michał Buszkiewicz is my and yours guest.

I just realized that I left out from this introduction the fact that you also have a sizable portion of your business as a conference speaker and a podcast guest.

Yes. Being present at the recent ElixirConf EU in Warsaw was a wonderful experience. We talked a bit about debugging the application. As you mentioned, I really liked how the presentation generally demonstrated a bit more unconventional approaches to the topic. I’m glad we succeeded and had the chance to get together after two years because the response was overwhelmingly positive, even from those who had previously disagreed with these methods.

It will be even more enjoyable to talk to someone who also finds themselves in this stack because the Elixir we will be discussing today is a technology, or should I say this branch of technology, that I have been working in for about three years.

Okay, lets get down to business. There is a predetermined item on the agenda at the beginning, i e. a question for the guest. Do you listen to podcasts, Micha? If so, do you have any recommendations for us?

I must admit that I tend to enjoy reading and feel at ease when I do. Sometimes I listen to podcasts that are typically focused on Elixir, like Thinking Elixir, in which I have also previously participated, Elixir Mix, or podcasts that appear to be a little more forthright about programming, like Running in Production, for instance.

However, I really enjoy everything that top newsletters send me when it comes to reading resources, which are somewhat more my style when it comes to finding content, such as ElixirWeekly. These are the things that reach me the most frequently when it comes to such ongoing sources of knowledge.

Sure, I get it. I have podcast listeners who only experience the show by reading transcripts, so I completely understand that everyone has different preferences. Some people prefer to listen, some prefer to watch, and some prefer to read.

You know what, in my opinion, it also involves being able to maintain concentration on a single issue for an extended period of time. I have to admit that I occasionally struggle with this as well. And it often seems easier for my mental functioning to receive the read material in a format where I read an article fragment somewhere, then another, then another.

You co-founded the software company Curiosum, as I mentioned in the introduction, and you put a lot of emphasis on Elixir because it is the most important technology for your industry. However, you go beyond the projects you work on; you are also involved in the community, maintain a blog, and as you mentioned, you recently spoke at ElixirConf EU.

Whatever the case, Elixir is not the most popular technology among software houses, and certainly not in Poland, so I wonder where this choice came from.

The fact that we are likely the first software house in Pozna, and possibly also in Poland, to have from the start concentrated heavily on Elixir without switching to this technology from any other has never been the most important fact for us, but after a while, we’ve realized it. This is crucial because it allows us to claim that we are experts in this field and prevents us from concentrating on unimportant details or devoting our time to technological endeavors that we do not fully support.

On the other hand, with such expertise gained from our prior professional work in developing web applications for numerous industries, we are fully aware of the limitations posed by the technologies we have used up to this point in terms of scalability or the ability to handle simultaneous connections that can reach the number of hundreds of thousands, or in some cases, millions. We recently discovered that the languages that are typically associated with developers’ joy at work and the ease of entering data and building applications with their assistance are simply not suited to parallel and quick data processing.

All of this leads to infrastructure scaling costs in the future that startup founders and investors are unaware of during the early stages of their product development. When this application moves past the MVP stage and becomes much more robust, we chose to tackle it with a technology that is both effective in the application itself and prepared for the challenges faced by a startup.

Sure, got it. It was therefore a deliberate decision, defined by the technological issues you had previously dealt with and a strong wager on Elixir.

OK. I now want you to provide some background information on the language itself. Because the language itself is not very old in terms of years on the market, but it is based on solutions that have already been in use, where did it come from, and who made it? Could you please explain what this language is and how it was created?

Brazilian José Valim, who has been closely associated with the Ruby language’s ecosystem and environment for a long time, is the primary creator of this language and, in fact, the idea’s originator. His interest has grown in tools and languages better suited to the performance and scalability requirements of modern applications.

He was particularly enthusiastic about the Erlang virtual machine, which was developed by Ericsson and has been widely used in telecommunications to address such issues since the 1980s.

It turns out that these issues are mostly back, and it has been realized that this is actually a very relevant issue.

José’s lack of Erlang in terms of syntax or usability is due to Elixir, a sort of superstructure above this VM. It also draws inspiration from other functional languages, i. e. Haskell, Clojure, and syntactically from Ruby. He took the idea for pattern matching, among other things, from the first one. The second one gave rise to ideas for the organization of the code and various syntactic sugar, and the third one is actually a syntactic stylistics.

It is common to market Elixir as being similar to Ruby, which is quite, I would say superficial, if not nonsense. As such, when comparing it to natural languages, I would compare Ruby and Elixir to languages that have, let’s say, similar spelling but completely different grammar.

Yes, it is also a result of the community here somewhat overlapping. The Ruby language’s creators were also connected to it and made significant contributions to the growth of its ecosystem. There are numerous coincidences and hardly any real connections to be found here.

If you can call two technologies brothers, which I believe they are, they are actually quite different solutions. José Valim, who was a core member of Ruby on Rails at the time, was looking for a solution to the concurrent computing problem when he looked at other languages and discovered Erlang, as you mentioned.

He later admitted that while he loved everything about this virtual machine and Erlang, he also detested what was missing, i e. The ease of writing code, which, let’s use Ruby as an example, de facto defines the entire language Therefore, he made the decision to draw on some of his Ruby programming experience to develop a new language that would run in a virtual machine and allow the execution of Erlang code.

OKAY. Many similar languages go unpublished, some disappear as soon as they are developed, but Elixir has managed to surpass and still stands out. What requirements does Elixir meet? It should therefore be assumed that it actually satisfies the need. Could you mention something similar regarding Elixir?

This can be summed up in the shortest amount of time and strikes a balance between productivity, coding simplicity, and the caliber of work output. There are a lot of reasons, in my opinion, why we chose Elixir over other functionally purist languages like Haskell, which is sort of making its way into the mainstream.

Elixir, in my opinion, addresses the age-old issue of startups initially choosing technology known for rapid application development, developer satisfaction, and time to deliver but ultimately having little to offer in terms of further scaling the applications. Of course, the use of the appropriate technology, i. e. Elixir in this context is not a guarantee of anything because many projects are poorly executed and use it without full awareness, but because of the features of the language and this toolset, it opens up more possibilities and produces better solutions.

Let’s briefly discuss the construction of this language now. Please provide some clarification on the language’s structure and the runtime’s architecture.

Let’s start with the tools shared with the Erlang language, or BEAM – a virtual machine, which is a component of the OTP, or Open Telecom Platform, which is just a collection of standard tools libraries for the Erlang language. And this is the foundation that guarantees scalability and fault tolerance, which are two additional key characteristics of both Erlang and Elixir. Applications written in both Erlang and Elixir are compiled for this virtual machine.

The characteristics of this virtual machine are unquestionably more significant than those occasionally cited as significant in the context of Java virtual machines, i e. some cross-platform etc. When it comes to e, the situation is not so promising. g. running code that has been compiled for one platform on another, but this isn’t the most crucial part and it’s not what we concentrate on.

However, given that much of the essential language structure is created using macros, a key feature of the language itself is that the tasks of its own compiler are relatively few. e. functions that take certain data and return code. For instance, the word “def,” which makes up the function, is also defined as a macro. You can see exactly what happens when defining the function, how it is registered, etc., in the language’s source code. whose subsequent macros, i. e. our code-generating functions are expanded to a state where further development is not necessary. In a Kernel Special Forms module, everything we see is made up of creations that have been handled directly by the compiler. And this character, in turn, is already compiled to bytecode.

In a nutshell, this is how Elixir appears, and you can say that it is a feature that is quite significant because it has a significant impact on how some DSLs, such as bookcases, are created when they are required. Of course, the entire metaprogramming aspect is also crucial.

In fact, it’s a fascinating fact that a significant portion of Elixir is written in Elixir.

This is a fun thing. You claimed that compiling Elixir into a bytecode and running it on a virtual machine was equivalent to standing on the shoulders of giants. We rely on the decades-old Erlang virtual machine and are adding something new to it that makes writing software more enjoyable, simple, and approachable. I believe that a comparison to Scala and the Java virtual machine might be more relatable to this audience. It’s a similar concept at least.

As you mentioned, Elixir is based on a functional paradigm, which is similar to the language’s fundamental paradigm. Whatever the case, although this paradigm is still a niche, it is starting to gain some popularity. When it comes to contemporary programming languages, object-oriented programming unquestionably takes the top spot.

I think it’s unfortunate that this is somewhat influenced by the perception of functional programming as being very difficult, mathematical, even scientific, marked, and full of such a theory when it comes to general opinion. Is this what functional programming looks like in Elixir? Do you deal with something like this?

Elixir differs significantly from features that are actually more associated with purist languages like Haskell, Elm, and possibly F Sharp. Some ideas from these languages simply weren’t intended to be transferred to Elixir. Elixir has dynamic typing, whereas these languages frequently use static typing. This presents a real challenge for programmers who would use Elixir but have previously used Haskell. Elixir has a “let it crash” philosophy as opposed to strict error catching during compilation, e. g. in Haskell. Elixir will therefore not appeal to functional language purists who also have a strong theoretical bent.

Here, I treat functional programming as a paradigm that focuses solely on converting data from one form to another. This, in my opinion, is the most crucial feature of functional programming in Elixir, and it’s also the most user-friendly, even for a pipe operator.

Returning to all other languages, we can say that Haskell, which is adored by everyone who is very passionate about this mathematical aspect of functional programming, will probably continue to be a fantastic language, but will only be used in specific projects to achieve a specific goal, consciously. The future of Elixir, on the other hand, includes a wider range of applications.

In comparison to object-oriented languages, its virtual machine has some advantages and a certain degree of simplicity, to which, you could say, some declarative or functional programming elements are very important. Basically all languages that are currently known to us have such elements. As strange as it may sound to someone used to OOP, the data’s complete lack of objectivity and mutability is by far this situation’s greatest advantage because it makes it very simple to reason about interactions between modules and, for example, to transfer code in both local and distributed environments.

Yes. I think its also practical and pragmatic. However, Erlang as a telecommunications language must have been very pragmatic, and here I get the sense that all the functional programming ideas present in Erlang and in Elixir are also meant to serve this purpose. Here, we want to build something that will actually work in production rather than just speculate about it.

While we’re on the subject of production and these particular applications, may I ask you which of the most popular frameworks, libraries, and specifically Elixir applications are the most significant and noteworthy?

It is undeniable that whenever we discuss Elixir applications online, we frequently refer to the Phoenix Framework or one of its components. It is a framework that is comparable to Ruby on Rails, but it is unquestionably more modularly built, making it much simpler to disconnect each of its component parts from the rest of the framework, give up some of them, etc. Furthermore, the developers of this framework have repeatedly stated in the open that they drew on the experience of frameworks like Ruby on Rails, that some of the design solutions employed there were simply incorrect, and that they had learned from their own or others’ mistakes.

The Phoenix LiveView, which is somewhat reminiscent of React but not yet in the 1x version, is quite an intriguing feature, though it is a comparison that should actually be covered with many stars. To manage the state of the web application interface, in fact, to our server, which maintains a connection with each user server for each user who, for example, displays a given page, we use the Erlang virtual machines’ capacity to process hundreds of thousands of processes at once. Actually, a separate process that keeps track of the state and communicates it to the client, i e. Phoenix also excels at WebSockets, which is another one of its strengths.

Additionally, there are frameworks that are frequently used in conjunction with it, such as Absinthe for GraphQL API construction, which is also a very cool thing. Not to mention all the other libraries required for the majority of apps, such as Ecto for databases, which takes a unique approach to mapping tables to structures in our language because, of course, we are not dealing with an object-oriented language, so it cannot be an object relational mapping. Ecto strives to adhere as closely as possible to purely SQL concepts. And in comparison to many other ORM frameworks, this takes a slightly different approach.

There are numerous libraries that enable interaction with well-known cloud services, such as AWS, so there’s no need to break down barriers or invent the wheel. There are numerous different HTTP clients that enable us to communicate with some APIs that we must use in a more organized manner. Generally speaking, there are libraries for all of the most prevalent problems that we deal with in web applications.

And, moving away from the web a little bit, there is also Nerves, which is a framework for creating Internet of Things applications, primarily at the level of hardware like the Rasberry Pi. Sometimes when I’m looking for completely different things for completely different applications, I find that there is, for instance, a framework for two-dimensional user interfaces called Scenic. Or a toolkit like Kitto for creating visually appealing dashboards while also utilizing React

So there are many applications here. Elixir is a language that strongly emphasizes such harmonious development, so many libraries that were created, for example, a few years ago but are not developed until today, work without any issues. It is currently a closed language for features from the initial backlog. They have all been implemented, with the exception of a few deprecations that won’t be removed until Elixir 2 is released. 0 is released. In general, it is difficult to predict where the language will be in terms of development after version 1. 12 to 1. 13 there won’t be any fundamental changes; for the time being, it’s just their policy. And thats cool because there are fewer surprises.

Yes, it is undeniable that Phoenix, with its excellent support for WebSockets, Pub / Sub, and Live View, where we actually query the backend through a WebSocket and update that interface in real time rather than rendering anything with JavaScript, is currently the most powerful Elixir application. Here, even a few animations are produced and sent to the browser via WebSockets, minimizing the use of JavaScript to almost nothing.

But aside from that, in a sector like the Internet of Things or embedded devices, there are also applications that might not immediately come to mind but have a real place in specific contexts. For instance, in the case of boat navigation, where the boat spends months at sea, the navigation must not fail there, it must operate continuously and predictably.

It turns out that a company exists that creates such sophisticated solutions and once boasted about graphs of e g. memory consumption, CPU consumption, etc. This is a very predictable technology in that the virtual machine starts up, the application starts running, the resource consumption reaches a certain level, stays there for months, and there are no fluctuations.

Additionally, on such boards as, for instance, the Rasberry Pi, Arduino, etc. – Elixir can be used to run a virtual machine there in a very, very slimmed-down form, and everything boots up very quickly. So there are also such applications.

I briefly discussed this reliability, and you and Micha brought up the possibility of running such code in a concurrent and distributed fashion. Are concurrency, some scattering of this code, and features like reliability, in your opinion, the main selling points of Elixir?

Yes, I believe that using this technology is a good idea for systems that currently require or may require a high level of concurrency in the future. For example, Elixir incl. Discord was able to manage 5 million parallel client connections using Erlang’s virtual machine. Later, it was slightly enhanced with Rust, but it is still a result deserving of respect.

And as I previously mentioned, we frequently use the “let it crash” strategy here. This is made possible by the Virtual Machine’s (VM) extremely effective management of processes and their resources, which cleans them extremely efficiently when a process crashes in a controlled manner. Of course, this philosophy does not mean that we want users to see every error; rather, it means that we expect these errors at the server level and deal with them during the process design phase.

The fact that we have an actor model and interprocess communication via message passing rather than data sharing makes concurrency processing reasoning very simple, in my opinion. And as I mentioned, the absence of stateful objects from OOP definitely makes it easier to implement all problems relating to sending code between nodes so that some functions can be run remotely.

Yes, José Valim is the author of this language. As far as I can recall, Elixir first appeared in some form in 2012. How is this technology currently evolving, and who is currently in charge of it?

Yes, José is currently a member of the 6-person Elixir Core Team. On the other hand, the language is of course supported by a number of businesses that support and contribute to the most widely used frameworks, including Phoenix and Nerves, as well as the major libraries. Naturally, the Core Team works to ensure that, on the one hand, the community’s voice is heard as clearly as possible when it comes to functionality and development directions. José said at the previous ElixirConf that if it were up to him, some language components would look entirely different, but the society would be the deciding factor.

On the other hand, it is wonderful that the language’s Core Team ensures that it does not acquire too many functions that are not required by the entire community to be built into its core. These types of things are under such intense pressure that they start to function as separate libraries and as though they were engaged in competitive trade.

Okay, so tell me from your perspective how popular this language is in the market right now. Of course, we can look at the TIOBE index or other indices, but I’m referring to here, for example, the availability of developers, which may be a big deciding factor for businesses when deciding to adopt this technology. Additionally, businesses that employ Elixir in their production applications

Beginning at the end, it is true that more and more top-tier businesses are using Elixir in their day-to-day operations. One such company is Pinterest, which was able to reduce the number of servers it needs and write 10 times less code in some areas of the application. Moz, which greatly reduced disk usage and accelerated its API. Lonely Planet, Financial Times, Toyota, Bleacher Report, Discord ….

PepsiCo, exactly. You can connect WhatsApp here because, despite the fact that it is based on Erlang, it obviously uses the same infrastructure. Since there are increasingly more of these businesses, I believe that this is the best evidence that this language has a lot to offer. Although a slogan like “Ruby on Rails” is a kind of trigger, an obviousness that is immediately associated with some benefits known for years, Elixir or Phoenix are still something that you need to actively market in a typical startup environment.

But I hesitate to characterize this as a specialized technology. Maybe less obvious when it comes to selecting it for particular purposes. As I previously stated, however, more and more major web players not only brag about using Elixir, demonstrating the language’s ground-breaking power.

However, it cannot be denied that it is challenging to enter the workforce again. Most programmers migrate from other languages to Elixir at a level of, say, Regular. As talented developers quickly find employment, the market for them is relatively small. It can be said that the supply and demand are not balanced, and this is evident in both software companies that use this language and independent startups. You must take this into consideration because it can occasionally lead to a slightly unhealthy race, which leads to unsuccessful hiring, both in these more product-focused companies and software firms.

On the other hand, another tactic that we successfully employ at Curiosum is hiring young, talented programmers who, frankly, aren’t infected with object-oriented programming. We then train them internally using our proprietary methods and successfully entrust them with the responsibility of creating commercial projects while being guided by more senior coworkers.

And these juniors pick up on the art of creating tidy, organized, and effective application architectures very quickly. As it turns out, this language’s learning curve makes it unnecessary to employ a developer with extensive background to be successful. Of course, we expect every programmer who works on one of our projects to adhere to the standards we set, so the CV of a particular developer working on a particular project is less significant than simply working with us and having access to our knowledge base and expertise.

Of course. I’d like to ask you how to start, where to look for materials, and what to use first as we learn this language.

There are many books on PragProg, incl. Learn Functional Programming with Elixir is a lovely book that connects Elixir itself to functional programming generally. In the later stages, it is also beneficial to read books in this language that cover some more specialized subjects. For instance, Chris McCords’ book on Elixir’s metaprogramming has taught me a lot about how to do it in a way that is very different from how other languages do it.

Regarding the other resources, I personally learned the language from the ones on his website, though only to a very basic extent and they are not very extensive. At the time, I was a programmer of other languages and felt quite at ease with learning new things, so knowing the fundamentals was sufficient.

Additionally, there is the Elixir School, a free online course that covers it in more detail. On occasion, we also suggest courses and videos on Udemy that offer a wide range of Elixir-related topics. Generally, there are a lot of these materials. Perhaps not as much as with some conventional languages like Java, for example. however, I believe that they are generally of a higher caliber and that there is undoubtedly something to be learned from this.

Sure. Perhaps I would add Exercism. Io to that is a system for honing your programming abilities in a variety of languages, including in Elixir, where individual tasks of increasing difficulty are solved. Naturally, we can check our solution locally. However, we can also send it to this platform and rely on the feedback there to check our solution in such a welcoming setting. This is also a fun way to train yourself or begin learning by performing daily cuts and tests.

You mentioned, for instance, that you hire or accept individuals that you train for Elixir I have more experience with people who switch from other programming languages to Elixir because they typically have some, sometimes even a lot, of object-oriented programming experience. Do you think it makes a difference that someone already has a lot of experience with object-oriented programming but wants to switch from it to Elixir even though they actually have a workshop?

Of course, it makes a big difference. And it all depends on whether this transition is made by a skilled programmer, a solid developer who recognizes the distinctions between paradigms and is prepared to avoid blending them intentionally, or whether it is made by a coder out of necessity who is then thrown into the deep end without having any prior knowledge that PHP or another language exists. There are numerous instances of functional language programming done by individuals who are completely ignorant of this paradigm. Therefore, a lot depends on a person’s abilities.

On the other hand, I brought up a commonly held belief that Elixir and Ruby are similar, and I’m now going to talk a little bit about people who make this kind of transition, just like me. You must take care to prevent someone learning Elixir or considering learning it from doing it any harm, as doing so would be similar to saying that Turkish and Polish are similar just because they share alphabets.

The next most significant difference is the approach to metaprogramming because both languages are extremely flexible but in very different ways. Here at Elixir, we have a complete non-objectivity and mutability of data, and this is the most significant difference. In Ruby, classes and methods can be defined however you like, and practically everything can be patched at any time during run time.

By design, monkey patching is virtually impossible in Elixir, and the previously mentioned macro mechanism generates magic code during compilation. In essence, once an app is compiled, its modules are closed to any Ruby extensions you might add at any time. When you are an expert at developing DSLs in Ruby as a Senior Developer, for example, and suddenly find yourself in front of a language like Elixir, where you need to understand how AST, Parser, and other macro issues work to embrace meta-programming, this is a very significant difference. And this is the factor that, more than simply switching from the object-oriented paradigm to the functional paradigm, has likely caused the most issues.

Now that we’ve got that out of the way, I want to ask you: in your opinion, what are the issues or gaps with this language or this ecosystem?

Because I won’t discuss completely extra-linguistic issues here, let’s say that the issues we encounter when it comes to the language itself sometimes involve inadequate documentation of some widely used libraries. Perhaps their creators sometimes lack the enthusiasm to maintain it. Sometimes all you have to deal with is the READ ME at the end of the documentation. It is true that there are times when the development of the libraries themselves lacks enthusiasm. For instance, correct me if I’m wrong, but the Arc library that many people use to upload files is still not maintained by its original creators.

Other drawbacks? I recently gave a presentation on debugging at ElixirConf, and I’m generally searching for such a neutral tool for checking the code for errors that occurred in it. So there are some shortcomings. Since the API we’re discussing is well documented and you can easily create a good HTTP client for this purpose, it is really a less important thing. I won’t even mention the instances where I see available libraries consuming some API for other languages and their lack of support for Elixir.

The Elixir team has been working very hard on compilation times for at least a few versions, and it is a subject that occasionally comes up in general conversation. There is a real improvement over what was e. g. in Elixir 1. 8. It primarily concerns some specifics regarding the tracking of module dependencies, such as which dependencies should trigger an automatic recompilation of a specific module, etc. However, I can see that there has been such steady improvement that eventually these flaws will be corrected, and the compile time will undoubtedly get better. When it comes to providing solutions to these kinds of issues, this place is excellent.

• What is Elixir? …
• Explain the advantages of Elixir. …
• What is the latest version of Elixir? …
• How many types of data types does Erlang provide? …
• What is Open Telecom Platform (OTP)? …
• How is run time error handled in Erlang? …
• What are the modules?

José Valim and friends answer most searched Elixir questions at Code Elixir LDN

Interviews for Top Jobs at Elixir

Accounts Receivable Coordinator Interview

Software Developer Interview

Top 15 Basic Elixir Interview Questions

Answer: Usually, a competent applicant enumerates and describes the following benefits of the language:

High fault tolerance. Elixir is loved by developers because of its safety mechanisms – a robust failure alert system and the independence of application elements. Even if there’s a system failure, the components of an app hosted on a different server will run errorlessly.

Question # What are some of the best Elixir error handling questions?

Answer: Although there is some wiggle room with this query, it’s helpful if you want to hire a developer. It will amply demonstrate the candidate’s commitment to upholding established norms and desire for continuous improvement.

Developers can mention the following beneficial procedures in the interview:

Question # What data type categories are there in Elixir?

Answer: developers classify Elixir data into two broad categories: