Forem: Alex Gascón

You are not worse when you are rejected

Alex Gascón — Sun, 14 Jul 2019 22:53:59 +0000

Tomorrow I'm starting a new job as a Software Development Engineer at Amazon. It's a step in my career that I would have considered completely unbelivable a few years ago, and maybe even a few months ago.

Since I got the offer, I've been thinking a lot about how I got to that point. Of course, a very important part about it is preparing for the interview adequately, but there are hundreds of articles talking about the Amazon interview process, or about how to pass interviews at Big 4 or other great software companies; probably I will write one myself in the future, because I think that it may be useful to someone in the same way that the articles of people that interviewed with them before were useful to me. However, there's another part of the process that it's not often mentioned, and that really made a difference in my case: simply, being lucky.

It's not a mystery to anyone that has been looking for a job that in most of the positions you apply to you won't get an answer, or if you do it will be to let you know that you have been rejected. That happened to me too: I also tried applying to lots of other companies, like Shopify, Stripe or Airbnb; and in all of them, I got rejected before even getting to the interview process.

At first, all those rejections made me reconsider if I should even keep trying: if all those companies were rejecting me before even interviewing me, maybe I wasn't good as a software engineer. Maybe my experience wasn't enough, or maybe it was the lack of open source contributions. However, in the end I was contacted by Amazon, I entered the interview process, and ended up receiving a good offer from them. I tried to analyze what I did differently to reach further in the process, but the problem was that I couldn't compare that situation to the others, because on those I didn't even had the chance to prove my skills.

Then it's when I realized one of the most valuable lessons I've learned in this interview process: the "me" that got rejected from lots of companies is the same "me" that got an offer from Amazon. My experience was the same, my skills were the same, my potential was the same. The only difference between those two days, is that one I was more lucky than the other: maybe that version of my CV highlighted exactly something that they where looking for or maybe it's simply that Linkedin search results showed me on the second page instead of the tenth. I'm not sure what may have been the root cause, but the consequence was that it allowed me to get to the interview process, where the outcome depended only on myself.

Getting rejected is hard, because we tend to think that we've done something wrong and that there's something about ourselves that we should change. But it's important to realize that sometimes the reason for being rejected was completely out of our control, and that what we have to do is not to get discouraged and stop, but to keep trying until you get a chance to actually show what you're worth.

Regret minimization

Alex Gascón — Sat, 15 Jun 2019 23:26:51 +0000

Lately I've been reading One Click: Jeff Bezos and the rise of Amazon.com, a book about Jeff Bezos and how Amazon came to be the internet giant that it is today. I'm still at the chapter 5/17, but what I found most curious so far is the fact that every time Bezos made a decision, not only about the business but also about his personal life, he took an incredibly analytic approach and studied all the possible outcomes and aspects that may influence the result.

One of the ways in which this manifested was through what he called the "Regret Minimization Framework". Basically, it's a tool that helped him choose between a set of options by analyzing which one will be the one that he may regret less in the future. In the book, it's presented when he had to choose between continue working on his (really) high-paid job in a financial software company, or leaving it and start an Internet business.

"I knew that when I was eighty there was no chance that I would regret walking away from my 1994 Wall Street bonus in the middle of the year. I wouldn't even have remembered that. But I did think there was a chance that I might regret significantly not participating in this thing called the Internet, that I believed passionately in. I also knew that if I had tried and failed, I wouldn't regret that"

I've had to make a big personal decision myself lately (switching to a new job and moving to another country, or continue at a job that still was a really good opportunity), and even if I didn't named it that way the "regret minimization" was definitely the most important factor that influenced my decision. If you think of it, it's probably the best way to make a decision because it forces you to think not only on the instant gratification that you will get from each option, but also on its long-term consequences.

A detail that may seem insignificant but that for me it's one of the most important parts of the framework is how he considered both the good and the bad outcome. In the end, it's obvious that things will not always go as expected, and making sure that you won't regret a specific decision even if it goes completely wrong is probably one of the factors that you need to consider the most when you make the choice.

Decision-making is the skill that will have the biggest impact in your life, and having a clear set of steps to follow during the process will undoubtedly help you get the best outcome from it. Are you comfortable to make that decision now, even considering that things may go wrong? Will you be able to change to another option if you think better about it in the future, and will there be any consequences? And, most importantly: will you be able to accept that decision 10, 20 or even 50 years from now?

CPython, Cython, PyPy... An introductory guide to the different Python variants

Alex Gascón — Sun, 20 Jan 2019 12:24:36 +0000

If you're into Python programming, chances are that you have heard the words CPython, Cython, Jython, PyPy... However, what are they exactly?

In this article we will do a small introduction to some of these Python variants, so you can at least understand what they exactly refer to if you see them in any other context.

CPython

CPython is the original Python implementation, the one you will probably use daily and that you can download officially from python.org. Its name comes from the fact that the Python code is compiled to bytecode using C.

Jython

Jython is an alternative implementation that uses Java, instead of C, to obtain the bytecode. This enables this bytecode to run in the JVM, the Java Virtual Machine, like other languages such as Kotlin, Scala or Java itself.

As Jython its just another implementation, the syntax remains unchanged: you can take all your CPython code and run it on Jython without needing to change a single line.

Cython

Cython is compiler that enables to write C extensions for Python, usually with the goal of making it more efficient. Unlike the previous examples, is not a different implementation: it uses CPython to run the Python code. It can be considered a superset of Python, as it contains all its functionality and adds the extra C capabilities on top of it.

These extensions are written in a specific syntax, much similar to the one you'll use for writing the equivalent C code. Let's see this example (from Cython's Wikipedia site)

def sum_up_to_n(n):
    a = 0

    for i in range(n):
        a += i

    return a

cpdef sum_up_to_n(int n):
    cdef int a = 0, i

    for i in range(n):
        a += i

    return a

PyPy

With PyPy, we have another Python implementation like CPython or Jython. The interesting point of this implementation is that it is implemented in... Python itself (yes, probably this blew your mind, so keep reading to understand what we mean by that)

The core of PyPy is a Just-In-Time (JIT) compiler that it uses to compile the most repeated parts of your source code to the machine's native code (instead of bytecode, like CPython or Jython did). Running native code is more efficient than running bytecode, so this can result in great speed improvements even considering the time that will be used for compiling the code.

PyPy has a lot of detailed information about its advantages (and disadvantages) in its website, as well as some performance tips and advice on which cases may not be best suited for it, so I encourage you to check it if you're interested.

Summary

After this article, you should be more familiar with the concepts of CPython, Jython, Cython and PyPy. However, chances are that you are interested in learning more about them, so I've prepared a list of links that can be really useful if want to dive deeper into the topic. I hope you find them useful!

Useful links

Combining SQL queries with UNION

Alex Gascón — Sat, 24 Nov 2018 19:28:27 +0000

Introduction

Yesterday I was updating some Ruby gems on one of the projects that we have at my current company, and noticed one called active_record_union. I have to admit that I had never heard about SQL's UNION operation, so that gem generated a lot of curiosity on me. That's why I decided to get more information about it and write this learning!

SQL UNION

The purpose of SQL Union is to combine the results of several queries into a single one. For example, let's assume that we have the following table in our DB, representing Users.

UserID	Country	Age
1	United States	21
2	Germany	19
3	Japan	27
4	Spain	20

Let's assume that we want to search two types of users:

The users over 23 years old
The users located on the United States

In order to do that, you'll need the following two queries:

SELECT * FROM Users WHERE Country = "United States"
SELECT * FROM Users WHERE Age > 23

However, this will require two DB calls; usually you want to obtain your result using as few DB calls as possible, and therefore this won't be an optimal solution. Besides, using different queries requires a manual processing of the results to combine them into one (as each query returns a result set)

This is where UNION comes to play. Using UNION you can both two queries into a single one, and therefore obtain the same results in a single DB operation.

SELECT * FROM Users WHERE Country = "United States"
UNION
SELECT * FROM Users WHERE Age > 23

UserID	Country	Age
1	United States	21
3	Japan	27

By doing this, we will just need one DB operation, and also we will get all the matching users in the same result without needing to do any manual combination.

But, can't I just use OR?

Probably you asked yourself that question when you saw the previous section. And you're right: you could also combine both queries into one by using several conditions linked with OR, like this:

SELECT * FROM Users WHERE (Country = "United States") OR (Age > 23)

However, the key is in the performance of each operation. If you have indexes in the columns you're using to do the search, you will probably be better using UNION.

Using OR will make the SQL operation to use indexes just for one of the columns, or even not using them at all. On the other hand, using UNION resolves both queries separately, enabling the use of the most optimal query plan for each query, which probably means using the index of each of the columns if they have one. You can find a more detailed explanation about it in the following links:

Union over different tables

Also, UNION enables the obtention of results of several tables, instead of limiting to a simple one. For example, let's assume that now we have two tables: one for customers and one for suppliers:

CustomerID	Country
1	United States
2	Germany
3	United States
4	Spain

SupplierID	Country
1	United States
2	France

If we wanted to obtain all the customers or suppliers in USA, we could do something like the following:

SELECT 'Customer' AS Type, CustomerID AS ID FROM Customers WHERE Country = "United States"
UNION
SELECT 'Supplier', SupplierID FROM Suppliers WHERE Country = "United States"

And we would obtain something like this:

Type	ID
Customer	1
Customer	3
Supplier	1

Notice how we didn't even need to specify the column names in the second query! As the columns are in the same position, UNION automatically knows which column name has to be used.

(It's important to consider that this will only be possible if both operations returned the same number of columns, and if its types were similar).

UNION ALL

Something that I didn't mention is that, when combining the results of the queries, UNION does an extra operation to remove repeated rows. Going back to the first example, this would have been useful if instead of searching for those users older than 23, we would have wanted to search those older than 20: the user 1 matches both condition, and therefore he would have been present in both results. But to prevent us to have repeated data, UNION would have filtered the results and returned his row only once.

However, let's assume that we're completely sure that we won't have repetitions. For example, if we had a table like the following one:

UserID	Country	Continent
1	United States	America
2	Germany	Europe
3	Japan	Asia
4	Spain	Europe

This time, let's assume that we want to retrieve:

The users whose Country is United States
The users whose Continent is Asia

We are absolutely certain that there will never be a coincidence between those two groups. Therefore, letting UNION search for repetitions is a waste of time.

For those cases, we can use the UNION ALL operation: it also combines several queries, but without checking if there are repetitions in the result. Therefore, the following query:

SELECT * FROM Users WHERE Country = "United States"
UNION ALL
SELECT * FROM Users WHERE Continent = "Asia"

Will return as a result:

UserID	Country	Continent
1	United States	America
3	Japan	Asia

And it will actually be a faster than using a simple UNION (how much faster will depend on the size of your result).

However, it also requires you to be more careful about your operations,because if you combine two queries that can have repeated results...

SELECT * FROM Users WHERE Country = "Spain"
UNION ALL
SELECT * FROM Users WHERE Continent = "Europe"

UserID	Country	Continent
4	Spain	Europe
2	Germany	Europe
4	Spain	Europe

You will, in fact, end with repeated results.

Summary

The SQL UNION statement is a really useful resource if you need to search by several conditions and want to take as much profit as possible from the indexes associated to the corresponding columns. It is also really useful if you want to combine results from two tables that have a similar structure (for example, if you're using Concrete Table Inheritance and only need the common data).

However, it also has it's downsides: you need to be aware that the repetition removal step may slow down the query a little bit if you're retrieving a lot of rows; but the good part is that you can use UNION ALL instead to skip that part. Of course, then you need to be completely sure that you won't have any repeated data among the different queries. As Uncle Ben would say: "With great power, comes great responsibility"