One of the biggest language learning apps in the world, Duolingo is serving hundreds of millions of users every single day. Most of the app’s backend was written in Python, yet the tech team has decided to rewrite one of Duolingo’s core features in Scala.

With this article, you’re going to find out:

Want to learn more? Let’s dive in:

Duolingo before Scala

If you’ve never learned a language with Duolingo, here’s a quick summary of how it works:

As you can see, the app’s users learn through short lessons consisting of different types of exercises. 

Here comes the question: which exercises, and in what order, should the users see? 

Duolingo’s Session Generator is the module that makes these decisions for the users creating adequate educational sequences. 

This core feature has been around since the very beginning of Duolingo. The startup, as we already know, was gaining popularity pretty fast, thus growing rapidly.The hectic pace was both a blessing and a curse. Duolingo’s tech team had to act fast and didn’t always have the time and resources to optimize all the processes accordingly. And this led to significant technical debt

For instance, the Session Generator’s architecture featured many hard dependencies. This means that if any of those failed, the whole module would stop working. In other words, many features of the module affected the performance of other features. As you can imagine, this makes potential bugs much more likely. 

Because of that, the Duolingo team decided to redesign the module’s architecture and eventually rewrite the Session Generator. Here’s how they decided on the language:

Moving to Scala

As in many companies, Duolingo’s backend was originally written in Python, one of the world’s most popular programming languages. It’s a common choice, as it’s easy to understand for developers with different kinds of experience. 

There are, however, some challenges that come with Python, one of them being the speed. 

This language tends to be visibly slower than Java or C, while Java is also considered rather slow and verbose. What’s more, Python’s dynamic typing can be the cause of many runtime bugs. 

To avoid these issues, the Duolingo team decided to move their product to Scala. Contrary to Python, Scala is a statically-typed language. It’s widely used in other complex big data apps like for example Kafka that was developed by LinkedIn and is used to handle real-time data feeds. Not surprisingly, it turned out to be a good fit for Duolingo’s Session Generator as well. The team claims that they were looking for a more modern programming language. They also think that Scala is very mature in the back end so it fits the bill.

Implementing Scala in Duolingo

JVM and Functional Programming 

There was no need to reinvent the wheel. As Scala is built on the Java Virtual Machine, developers could use existing Java libraries. One of the biggest changes was the shift towards functional programming. Andre Kenji Horie, Duolingo’s senior software engineer, is a big fan of this solution. According to him, around 99% of Duolingo’s codebase is functional. He claims that it makes things much easier to debug, much easier to maintain.

Many developers have the impression that Scala seems to have learned from the mistakes of other languages. Here’s how the Duolingo team perceives it:

  • More concise – While Java is known for being elaborate and rather slow, Scala does a lot to make the language less verbose. Thanks to it being a functional language, the developers can use simple one-liners in many cases too.
  • Less prone to bugs – As we’ve already mentioned, Scala’s static typic makes it easier to catch bugs with a compiler. Less verbosity makes the work smoother, too. Contrary to Python, Scala is much less prone to runtime bugs.
  • Saves a lot of time – Andre Kenji Horie has stressed that writing code in Scala is significantly faster than programming in Java. In the same amount of time he’d use for coding alone, he can also write unit tests for Scala. This makes the developers more confident about the quality of their work.
  • Easier maintenance – When compared to Python, the development speed is similar, yet Scala’s maintenance is much faster. Andre mentioned that after moving to Scala he suspected that refactoring would take him around an hour, like in Python. To his surprise, it only took around one minute.
  • Efficient performance – As you already know, Scala is running on a Java Virtual Machine and is doing very well in a multi-threaded environment. In other words, it means that it can do a lot of things at once. Scala’s efficiency also means that Duolingo can use 10 times fewer servers to handle the same amount of traffic, which again is a huge saving. 

Of course, there were some challenges along the way. The team has described the two main pain points:

  • Java integrations – Some of the integrations were not compatible with certain Scala-specific features.
  • Documentation – As Scala is a rather new language, finding some of the libraries required extra effort. 

Scala learning curve

What’s more, many people claim that Scala’s learning curve is quite steep. In this case, improving readability and optimizing the product’s maintenance process was far more important, and here’s where Scala is doing really well. When asked about the learning curve, software engineers from Duolingo say that it was actually a lot easier than anticipated. It proves that even though the language is new, learning it is not an obstacle. 

To sum up, the team is happy with Scala despite the tiny downsides. Andre Kenji Horie has said in a Software Engineer Daily podcast that There are some small things here and there in the language but […] it is not a big deal. He claims that pain points didn’t come with Scala itself but were more related to changing from one language to another. For instance, when they had a function that was used in Python but not in Scala, they needed to find a workaround. 

Note that this is only related to the onboarding phases. In general, the team appreciates how Scala offers a lot of useful features that are not present in Python or Java. 

Duolingo and Scala: the results

The service turned out to be much more robust after the rewrite. It’s easiest to see in the speed test results. The latency before the rewrite was 750 milliseconds, while after implementing Scala it went down to as little as 14 milliseconds. Quite impressive, isn’t it?

To top it all off, the rewrite proved to be significantly more stable. With the old infrastructure, the average downtime was around 2 hours every quarter. After switching to Scala, the first few months boasted zero downtime. Obviously, it probably won’t last forever, yet it still looks very promising.

The team claims that Scala meets their needs as it’s very mature in the back end and, as we’ve mentioned before, makes a great fit for big data applications. 

Last but not least, the shift to Scala has improved morale among developers. They feel more confident deploying the code, as they don’t have to fear they’ll break the entire app. The improving testing suite that is used in Scala makes their work much more pleasant. Considering unit tests are prepared by developers who test individual code before integration, issues can be found at an early stage. Thanks to that, they can be resolved without impacting the other parts of the code. 

Scala as the right choice for your business

Does it sound like Scala could be the right fit for your product? If you’d like to learn more about implementing Scala in other global companies, you’re sure to enjoy this Zalando case study. Of course, if you have any questions about implementing Scala,we’re always happy to help, as we’re of the biggest Scala development companies. Feel free to get in touch via live chat on the website!

The article is based on the following sources:

A growing number of big companies have swapped cumbersome monolithic applications for distributed systems. And in virtually all cases, they’ve boosted customer satisfaction, reduced costs, and increased revenues.

Read more

The ultimate guide to do great on your next technical interview (Questions, Answers & more)

Common stereotypes show that in the IT industry, effective communication skills are not strong points in the profile of a typical programmer. They need only to have solid technical skills to help them accomplish specific tasks and to create particular products. But it turns out that nothing could be more wrong.

In the long run, when it comes to matching a new person to a team and making the right employment decisions, soft skills (communication skills, teamwork, creativity, etc.) are often more important than technical skills. 

According to specialists from a Linkedin team in the report “Global Talent Trends 2019”, bad hiring decisions and parting ways with employees are in 89% of cases caused by a lack of soft skills or deficiencies in both areas. Only 11% of partings were caused solely by problems with technical expertise.

In the opinion of Deloitte’s  “Soft skills for business success”, in 2030 as many as 2/3s of job offers on the market will require candidates to have specific soft skills.

Why we care about it at Scalac

At Scalac, our employees have the perfect combination of soft skills along with robust technical expertise, because as a company, we try to be as professional as possible when consulting with our clients. We always make sure we advise our clients, explain why any given solution is the best in our opinion and the pros, cons, opportunities, and threats of our proposals.

As a Scala development company, and experts in our field, we have to be able to express our opinions and knowledge professionally so our clients can be 100% sure that their cooperation with us was the right choice.

In this article, we would like to share this practical knowledge with you to help you nail any upcoming interview. 

After reading this article, you will know: 

  • How to prepare for a technical interview
  • How to show and share your knowledge
  • What a technical conversation looks like and why it is needed 
  • Where you can find answers to technical interview questions (reliable sources)
  • All communication tips & tricks 

Tech job interview – is it indispensable?  

Essential knowledge

The primary aim of a technical interview is to check the most essential knowledge of the candidate. The interview usually takes about an hour. Scalac is a remote-friendly company, so in our case, we most often meet online. We try to look more widely at the candidate’s competences and ask about things that they were not able to show during the implementation of their technical task. Sometimes, the candidate has made a mistake, used an inefficient way of using a given technology, or simply recombined it with a complicated solution. The technical interview is the right time for the candidate to clarify any important issues – by answering questions or initiating their own clarification of the case in question. Interestingly, our experience shows that sometimes a candidate hasn’t done the technical recruitment task completely independently. During the interview, we can easily verify this and avoid any misunderstandings on both sides.

Point of view

Based on our experience, we like to regard this stage of the process as a joint meeting of experts and practitioners in our field. After all, we are all programming enthusiasts in the conversation, regardless of the side, we are on – interviewer or interviewee. The interview is also the time to ask about the perspectives of the other technical people in the company, know their points of view and experiences. Why are they working here? How are they working? What projects are they involved in? What technologies do they use? What tools do they use? It’s best to ask about these kinds of issues at the source, and the interview is an ideal opportunity.

Soft skills

Of course, this is also an excellent opportunity to check the candidate’s soft skills, such as communication, proactive approach, problem-solving, searching for solutions, flexibility, and much more. Our recruiters often say that they are looking for people who can solve problems and the challenges they face. This is the most important to them. The data provided by Linkedin also confirms this – the most desirable soft feature on the labor market is creativity, which, contrary to popular belief, is not only reserved for the creative professions. Recently, this has evolved into a feature that allows you to solve problems in an original, unconventional, and at the same time effective way. Having this kind of competence turns out to be crucial in the face of very dynamic tasks and a rapidly changing reality.

Based on the Linkedin data, the most appreciated – and therefore desirable – soft features on the labor market are creativity, persuasion, collaboration, adaptability, and time management.

In the era of technical development and automation, the demand for social skills will continue to increase until 2030, because it is a feature whose machines, even with using the artificial intelligence, are not able to take over and replace so quickly (McKinsey Institute, “Skills shift automation and the future of the workforce”)

How to prepare for a technical interview

Technical competence is practiced every day and improved continuously because programmers use their practical knowledge when doing projects and programming new functionalities as part of their professional duties. However, sharing knowledge with someone else, – especially not in any specific practical case but also theoretically – can be more complicated and require more communication and persuasive skills than it may seem.

What questions are asked in a technical interview? Scala technical interview questions – (Scala Programming Language interview)

As Scalac is a Scala development company the leading technology we use is, not surprisingly, Scala, which is why most of our technical recruitment is for Scala Developers. Below, we’ve also collected some valuable content on typical Scala technical questions.

There are plenty of sources on the web where you can find sample questions, so not wanting to discover America again, we have decided to combine our own questions with the best ones on the web, revised by our developers. Now you have all the best questions (with answers) in one place! Scala development company tested.

How can I pass a technical interview? 6 Tips from our developers

Some time ago, our developers prepared a few rules to send to candidates before a technical interview to prepare them for what it will contain. So it  will not be  too stressful, below are some tips that you should consider if you want to be well prepared for the main points of an interview

  • Before the technical interview, make sure you have your solution from the previous stage to hand, so you can open it if needed. Or just make sure you remember your solution. Sometimes technical recruiters will want to ask you about something you did in your task. 
  • Some concepts might be easier to explain with code than with words, so make sure that any app for presenting your code works fine on your device. It could be a simple “online text file” so you can share what you have in mind. This practical way of explaining is sometimes easier and shows your practical knowledge and experience off better.
  • Sometimes, it could happen that a technical recruiter will ask you to do some “live-coding” during the meeting. This can be helpful to convey meaning. The idea is not to write compiling the code. 
  • Even if you have a lot of experience and knowledge when describing a topic, it is better to come up with an answer that covers the main points as briefly as possible. If you explain something for a long time and it turns out that this is not the best question for you, you will have less time for another question which could be better and more comfortable for you.  
  • It’s always good to spend some time refreshing your knowledge because sometimes it’s hard to recall how something works if you used it a year or more ago.
  • From a practical point of view, before the call, remember to check whether your Internet connection, microphone, speakers, and camera are working correctly so you can talk without any disruption and delay during the meeting. To feel comfortable, you can always ask your recruiter about any “dress code” for the interview – not to be overdressed or too informal.

6 pieces of advice on communication from a professional interviewer 

From a typical communication point of view, it is worth remembering the following issues so you feel by the end of the interview that both sides have the right information necessary to make further decisions regarding the recruitment process.

  • If the interview is online – everybody knows that sometimes the connection quality can be lacking, freeze, or something – so do not hesitate to ask for clarifications or to rephrase anything – it’s perfectly fine!
  • If anything wasn’t clear  – feel free to ask for clarification, explanation, or to repeat it – this is completely natural, -we should always strive for the best understanding from both sides.
  • Remember that the technical person is there to also answer your own questions about the company you are applying to.  Don’t be afraid to ask – if everything goes well you will be working together in the same team anyway. 
  • Remember one basic rule – “I don’t know” is sometimes a good answer.  It shows your maturity and openness – so do not hesitate to say it if necessary It is better to admit you don’t know than to try to figure out a response when you actually don’t have any idea about something.   
  • Make sure you know how much time you will need for the technical interview and make some time in case it needs to be prolonged. You can always ask the recruiter about the probable duration. 
  • It’s perfectly fine to ask your recruiter what the interview will be about and what it will consist of. Remember, you can tell the recruiter about your previous experience to let him be aware of your strengths. You can also mention which topics you feel the most comfortable talking about and which specific topics you feel you are expert enough to show off your best side.

How to answer tech questions to show them you know what you’re talking about 

It sometimes happens that technical teams in IT companies may have direct contact with clients, as well as with their technical and business units at the stage of determining a project’s requirements. Scalac is a Scala development company and since 2013 when the company was founded – staying in touch with the client side is an integral part of our work. That is why sharing knowledge is essential, and we make sure to this when talking to the candidates.

Using The Feynman Technique to boost your communications skills

When it comes to preparing for the communication aspect of an interview, and showing off your knowledge, a good example to follow is the theory of Richard Feynman, an American Nobel laureate in physics. This technique

“involves using a simple analogy or metaphor to explain any issue. Although its main purpose is to identify questions that you can’t answer, thanks to which you find gaps in your knowledge, and you can get to know what you are learning.”

Feynman suggests that a perfect method to prepare and, assimilate your knowledge, and to realize any possible deficiencies, is to clarify an issue in simple words to reach the recipient, imagining it is a 5-year-old child. This simple way of communication is excellent in interviews especially on complex, technical topics, in which, at the same time, we have to demonstrate our understanding.

By explaining the issues,  both in-depth and in simple language, we can show off our practical knowledge and the fact that we know what we are talking about. At the same time, do not try to hide certain areas of ignorance behind a veil of complicated, theoretical expressions and words. That’s why it is worth relying on examples and, if possible, share completed case studies from previous personal experience.

Isn’t simple language too simple for a tech talk? 

Technical knowledge should of course be at an advanced level in the case of a typical professional interview, especially for regular and senior positions. But even in these cases,  sticking to simple, direct sharing of your knowledge is important. Not least precisely because it happens sometimes that business clients are not technical people. Explaining to them project assumptions, technical offers, main challenges, risks, and normal activities in a programming project may require more of a practical, pictorial, and transparent approach to prove our expertise and knowledge of a given issue. 

What you’ve learned – you know.

Remember that every experience you have had can be a lesson which you can always draw conclusions from and make good practices for the future. That’s why it’s worth bearing, in mind that there are no stupid questions.

As a well-known Polish proverb says “who asks will not go astray” – you can confidently ask questions during the recruitment process. Ask for any clarification if you do not understand something, or simply ask for a reminder of any issue already raised to ensure everything is transparent and understandable. Go ahead and feel free to ask about any typically technical aspects you can talk about with a technical recruiter, such as “what technologies are most often used in your projects?”, “What is the scope of the work in the project?”.

During the discovery interview with the HR team, any questions regarding work culture and company operations are also welcome. A recruiter who is interested in real dialogue with a candidate will be happy to answer any issues.

What can you learn from feedback? 

It is also vital to make sure you understand well any technical feedback provided – regardless of whether it may cause a further stage or delay the end of the process. You can always get valuable information and suggestions in feedback, which you could use to improve your skills and be able to present yourself better in the next stages of the recruitment process. We should always get the best out of feedback and regard it as an opportunity for development in areas that may require further work, and which will allow us to spread our wings in the future.

To sum up

After taking into account the above points, getting acquainted with the research we have quoted, and observing the labor market, we can confidently say that a technical interview is necessary in the recruitment process. That is true from ’ the point of view of both sides of the recruitment process

From the employer’s perspective…

considering the predicted increase in the importance of soft skills in the labor market, it is right that companies should develop their recruitment processes in this direction to make the right recruitment decisions.

From the candidate’s point of view…

the technical interview allows you to present yourself at your best, to explain your thinking and defend your arguments. It is also an opportunity to obtain additional, valuable, and technical information from other developers, already working in the company you are applying to.

It is worth noting that currently, soft skills are gaining value. We, therefore, hope that some of the above tips showing how to prepare well for a technical interview will prove useful will give you an advantage in the labor market and will help reduce the stress that often accompanies the recruitment processes.

Thank you for reading the article!

I hope that after reading this article there will be no doubt that technical interviews make sense and you will need to prepare for them not only in terms of typical programming knowledge, but also in terms of communication skills.

I can do nothing more than to keep my fingers crossed for the success of each of your future recruitment interviews and hope that we will meet at some stage of the recruitment process at Scalac ;)

What are your experiences regarding technical interviews in the companies you have applied for? Do you think they were useful and valuable? Do you now understand how necessary soft skills are in your job?

See also:

Scale fast with Scalac – Scala development company ready to solve all your challenges.

As a tester I often get to test functionalities in which the approach to the subject plays a key role. In a previous article, I have already written about how to approach manual testing on mobile devices generally. But here I would like to talk about one of the most interesting functionalities I have had an opportunity to test. Namely the testing of advertisements in different time zones. 

The assumption of the functionality was that a banner placed on an advertisement on a given day and time could be displayed anywhere in the world, making it possible to promote movie premieres or sales promotions. The creator of the advertisement would be able to set the day and time strictly in the “User time zone” but would also be able to enter the time zone manually. 

Why 590 timezones?

Initially, the programmers wanted to use UTC to divide it into and cover 24 time zones. Then all the creator would have to do, is simply enter the country and the program would automatically add the time zone.

However, after initial tests, it turned out that this solution has one main disadvantage, namely, there is no provision for summer and wintertime, which change in virtually every country.

After consultations, they decided that the best solution would be to use the moment.js library, which is based on times in Wikipedia. With this solution, the user could enter any destination region into the field regardless of the current time. The most up-to-date solution was divided into 590 regions (TZ database).

What devices did we have to check? 

This functionality was supposed to work on both desktop and Android devices from 5.1.1 version to the newest (it’s now 10.0) and for iOS from 9.3.5 to the newest (13). There were 13 versions of both systems to cover and 590 possibilities to check. I and a second tester had a maximum of just two days to plan and conduct the tests. So we had to come up with a manual testing approach that would give us sufficient test coverage but in this very limited time. 

Manual testing 590 timezones devices

How to approach manual testing when you have 590 Time zones and 2 days

Finding common ground

We started by listing all 590 zones and finding common features, i.e. the same UTC. For example, times in Europe / Astrakhan, Europe / Samara, Europe / Saratov, Asia / Dubai, Asia / Muscat, Asia / Tbilisi, Asia / Yerevan all have UTC +04: 00 in summer and wintertime so there would only have to be one test for all of these regions on all of the devices. After these merges, according to the UTC, there were 54 zones to check. However, 54 zones is still a lot, so we had to find another elimination factor. 


The next step was to take all of the 54 available zones and check which ones have high priority, which medium and which did not need to be tested at all.

High importance in our case meant that the timezone was important from a business point of view. For example, the zone in which a large part of Europe is located, i.e. +01: 00 in winter and +02: 00 in summer. Medium priority was given to those that were less significant for business or less used, such as the zones in which the Azores or Egypt are located in.  But also parts of Australia, for example,  because Australia has 5 different time zones and some were more important than others. Zones on smaller islands, practically uninhabited, such as the zone in which Fakaofo is located, i.e. an archipelago from a group of coral islands with just 265 inhabitants, were also considered not important from a business point of view.

Testing timezones
Testing cases for timezones - manually tested

After counting and analyzing the highest priority zones, we managed to reduce it to 25 must-haves and 11 nice-to-haves that would also be checked eventually if time allowed. You should also remember that some of these zones would need to be divided into summer and wintertime as well. So let’s keep that in mind. 

How to change time zones on devices. Preparing for the manual testing

Each of the devices being tested had to have a different zone with each test.  The largest available city was selected from each time zone, and the times were changed based on that. 

Changing the time zone on a specific device is not difficult, you just need to know where to look. I will show how to do it on macOS, iPhone, and Android devices (in this example Sony Xperia).

First device: MacBook

To change the time zone and Date & Time we have to press the date in the upper right-hand corner. Then press “Open Date & Time Preferences” and then go through 4 steps:

1. Unlock the possibility of changes

2. Turn off automatic date updating

3. After going to the Time Zone tab, turn off the ability to automatically load locations

4. Choose the location around the city or by clicking on the map

Second device: iPhone

On the iPhone we have to go to Settings -> General -> Date & Time and disable the option “Set Automatically”. Now we can change the time zone by entering the city name and change the date and time. 

It is important that when you want to test the application on iOS, you need to first download the applications on the phone (from Xcode). Then change the date/time zone because in the reverse order you will not be able to upload the application in the future date (on Android there is no such dependence).

Third device: Sony Xperia

On a Sony Xperia phone (there are no major differences on other Android devices) we go to Settings. Then we go to Date & Time and disable the automatic date and time zone settings.

Test cases

After preparing the test environment and time zones, we could then start on the test cases. After going through the simplest cases of playing advertisements at a given date and time, we also had to check whether everything was working properly in any given summer and winter time. 

A good way to do this was to check the wintertime by setting the date in December or November. Because in October the time changes around the world, but it is worth giving yourself a safety buffer. And then test summertime at the end of May. 

It’s also worth checking testing zones at the end of the day.  This is to check the disappearance of the banner at 23:59 and its appearance at 00:01 the next day. The disappearance of the banner and appearance in two weeks, only on certain days or vice versa was also checked.

Some of the more interesting issues that came up during the whole manual testing process were:

  •  when we changed the orientation, the banner did not appear.
  • Another thing was that when a given advertisement was fired by the user, the hour was not read in real-time. For example the banner was to appear at 17:00 and the user started displaying the advertisement at 16:59, the banner did not appear.


Thanks for reading the whole article! As (I hope) I have shown you, manual testing of time zones can be quite simple and interesting. You just have to make sure you clarify the most appropriate approach from the beginning. 

In this case, after the feature went into production, we didn’t have to test it any further. If, of course, the tests were supposed to be repeated regularly, it would be necessary to devise a strategy for writing automated tests. A little spoiler alert… We were able to devise the test approach and do the testing itself in just two days! It was a lot of hard work, but the outcomes were totally worth it. 

See also