The ultimate guide to senior engineering interviews. Strategies developed by FAANG engineers on Python concurrency, multithreading, monitors, and event loops. Prep faster for top company questions.

Concurrency in Python is one of the most complex and advanced topics brought up during senior engineering interviews. Knowledge of concurrency and multithreading can put interviewees at a considerable advantage. This course lays the foundations of advanced concurrency and multithreading and explains concepts such as Monitors, Event Loops and Deferred Callbacks in depth. It also builds simple and complete solutions to popular concurrency problems that can be asked about in interviews like the Reader-Writer Problem and the Dining Philosopher Problem. While prior knowledge of concurrency is not required to follow through with this course, familiarity with the very basic Python would be helpful.

Python Concurrency for Senior Engineering Interviews

<div class="card">
   # Asynchronous with Executors   
   <div class="ans">
<p>In the previous section, we wrote an asynchronous version of our service that used the same event loop to juggle between incoming requests and performing calculations. A long-running request made the service completely unavailable. One mitigation we can apply is to offload the calculation work to thread or process pools, same as what we did in our multithreaded approach. The changes required to our service are minimal. Instead of scheduling the prime number calculation on the same event loop, we handoff the work to either a process or thread pool. The changes are shown below:</p>
<b>

```python
class PrimeService:

    def __init__(self, server_host, server_port):
        self.server_host = server_host
        self.server_port = server_port
        self.executor = ThreadPoolExecutor()

    async def handle_client(self, reader, writer):
        global requests

        while True:
            data = (await reader.read(4096)).decode()
            nth_prime = int(data)

            current_loop = asyncio.get_event_loop()
            prime = await current_loop.run_in_executor(self.executor, find_nth_prime, nth_prime)

            writer.write(str(prime).encode())
            await writer.drain()

            requests += 1
```
</b>

<p>The rest of the infrastructure remains the same. The code widget below runs the simulation for a few seconds and the results are similar to what we saw in the multithreaded approach. The number of requests completed doesn't drop to absolute zero but are down more than 99% from before the long-running request gets submitted. Also, since we are using a thread pool, the <code class="mthd">sys.setswitchinterval()</code> will have similar effects on the number of requests completed as we saw in the previous multithreaded approach. The code in the widget runs without tinkering with the switch interval but feel free to change that value and observe the outcome.</p>

<p>The code in the widget below has slightly different syntax to account for Python 3.5.</p>
</div>
</div>


<div>
   # Asynchronous with Executors   
   <div>
<p>In the previous section, we wrote an asynchronous version of our service that used the same event loop to juggle between incoming requests and performing calculations. A long-running request made the service completely unavailable. One mitigation we can apply is to offload the calculation work to thread or process pools, same as what we did in our multithreaded approach. The changes required to our service are minimal. Instead of scheduling the prime number calculation on the same event loop, we handoff the work to either a process or thread pool. The changes are shown below:</p>
<b>

```python
class PrimeService:

    def __init__(self, server_host, server_port):
        self.server_host = server_host
        self.server_port = server_port
        self.executor = ThreadPoolExecutor()

    async def handle_client(self, reader, writer):
        global requests

        while True:
            data = (await reader.read(4096)).decode()
            nth_prime = int(data)

            current_loop = asyncio.get_event_loop()
            prime = await current_loop.run_in_executor(self.executor, find_nth_prime, nth_prime)

            writer.write(str(prime).encode())
            await writer.drain()

            requests += 1
```
</b>

<p>The rest of the infrastructure remains the same. The code widget below runs the simulation for a few seconds and the results are similar to what we saw in the multithreaded approach. The number of requests completed doesn't drop to absolute zero but are down more than 99% from before the long-running request gets submitted. Also, since we are using a thread pool, the <code>sys.setswitchinterval()</code> will have similar effects on the number of requests completed as we saw in the previous multithreaded approach. The code in the widget runs without tinkering with the switch interval but feel free to change that value and observe the outcome.</p>

<p>The code in the widget below has slightly different syntax to account for Python 3.5.</p>
</div>
</div>


In this lesson we introduce executors within an asynchronous program and examine how the right choice can significantly improve performance.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Asynchronous with Executors

Asynchronous with Executors