Sobit Akhmedov

Amazon software engineer interview

Fri, 08 Jul 2016 00:00:00 UTC

I was recently contacted by a technical recruiter from Amazon. The company was hosting an interview event for software engineers to join a team in their Berlin office.

The whole process from being contacted to signing the contract took two months. I would like to share my experience on how it went in general as well as what I believe helped me pass it successfully.

If I failed to mention something important in this article, feel free to start a discussion in the comments section. There I will try to be as detailed as possible.

April 27: First contact

I was contacted by the recruiter via LinkedIn. She told me they were looking for software engineers to join a team in their Berlin office and asked me to send her an updated resume if it sounded interesting for me. I always tend to keep my resume updated, so the next day I sent her an email with it attached.

She responded with some general information about the role and the interview process. The first step was to conduct a technical exercise via Hackerrank, which I received a link to separately on the same day.

The exercise was limited to 120 minutes and the recruiter requested that I finish it before May 5th. I decided not to rush and waited for the upcoming weekend.

May 1: Prescreening

Hackerrank has its own interview platform called Hackerrank for Work. That was the tool I landed on when I clicked on the link in the email. It has a built-in timer, a web editor with some sort of autocompletion for Java, problem statements and the ability to try your solution with various test cases including your own.

It was never communicated which languages the coding test would be limited to before I started it. Those I could choose from were C, C++, Java and a couple of others, which ruined my plans to use Go or PHP - the languages I was the most proficient in. So I ended up choosing Java.

The test consisted of three problems which could technically be solved in no particular order.

Problems

The first problem was related to an object-oriented design. I was provided with a few classes and their methods' definitions to solve the problem in the most efficient way while maintaining clean, readable code.

The second problem was an algorithmic one. Here I will give you some advice which helped me personally: before you start thinking about which data structures and algorithms to apply for a particular problem, solve the problem manually and visualize the solution - that will help you get wider picture. I did it on paper, realized how easy it was, and transferred my solution into the code.

However, a mistake I made was trying to further optimize it and make the code as beautiful as possible. I already had all the test cases passing and should have instead used the remaining time to finish the last problem. Bad prioritization. Lesson learned.

The third and the last problem was about analyzing complexity for the solution given in the previous problem. I was supposed to explain it as well as justify why I thought it was best from my point of view. However, I covered only the main aspects due to the lack of time.

May 4: Phone screening

The day after I received an email from the recruiter congratulating me on passing the technical test. She asked about my availability for the week to schedule a phone call and review my technical skills before she could invite me to the on-site interview. We agreed on May 4th.

Brushup

I only had two days so I brushed up on the essentials in algorithms and data structures. Specifically, I focused on the following:

Sorting: bubble sort, quicksort, merge sort
Search: linear search, binary search
Data structures: linked list, hash table, array, tree, binary search tree, stack, queue

Of course, you need to be able to argue about the complexity of algorithms and common operations on data structures. I personally found Wikipedia to be a great resource for this kind of analysis.

Phone call

The recruiter was very friendly during the call: we started by talking about completely unrelated topics, like the weather and city life, before moving on to the actual skills evaluation. We touched on almost everything from the above list and I also received a few questions about dynamic programming and recursion. A couple of times I struggled with properly naming some terms and operations. Recruiters usually cannot dive deeply into technical topics, but she was very open to discussing the reasons I used to name them differently.

Finally we discussed a few situational questions. I didn’t have anything prepared, so had to remember and come up with matching stories for each question right there.

She then expressed her positivity about my skills and we ended up the call. At the same moment I ordered an interview preparation book (listed in the References section). And I ordered it on Amazon, by the way.

June 2: On-site interview

Shortly the same recruiter contacted me with two emails: one had interview preparation tips and resources while the other was an application form to fill in. The questions were mainly about my current status, how Amazon could help me with relocation (if needed at all), current job conditions in terms of salary and perks, and the preferred day and time for the on-site interview.

I filled it in and sent it back, and four days later I received a confirmation of the day and time of the on-site interview. It was a new recruiter from the Berlin office. A week after she sent me a detailed schedule along with the interviewers' names and titles. At that point it was helpful for me to look at their profiles on LinkedIn to get an idea of whom I was going to talk to.

Preparation

In total I had a little less than one month to prepare for the interview. I knew I wouldn’t be able to finish the interview preparation book completely, so I decided to solve three exercises from each section. The whole thought process as well as iterations over solutions were translated onto paper and then compared to the answers at the end of the book. Black-color pen was used to write solutions, while red-color pen was used to mark errors. The idea was to have less red with every following exercise.

Another good source I found for practicing coding skills was LeetCode. As a coincidence, a friend of mine decided to brush up on his skills too, so we dedicated two hours of each Thursday evening to work on LeetCode problems together.

Two weeks before the date I started writing stories for the behavioral questions. Most people tend to underestimate them and focus mainly on the technical side. This is wrong! Interviewers want to know you as a human being and understand if they want to work with you on the same team. What I found useful for myself was writing each story in a STAR format. I worked on following situations: challenging problems, mistakes and failures, conflict handling, leadership examples. As advice, try to focus your stories on yourself and not on a team you cooperated with. That way, it will be easier for your interviewers to properly assess your contributions.

You should know exactly why you want to work for Amazon. If you don’t, think twice about whether it’s the right place for you. Interviewers will know if you’re not honest with them, and it will be a waste of time for all parties. After all, why would you spend precious years of your life on something you’re not truly passionate about?

Make sure you can talk about yourself. That includes both your story, which ideally covers your education, motivation, and highlights in your professional career, and your strengths and weaknesses. You might also want to prepare all the questions about the company or the teams you will be working with in advance.

Interview day

Candidates were asked to come in 10 minutes earlier to register at the welcome desk. I had to bring a passport and sign an NDA. One of the employees then welcomed me and took me to an interview room.

There were four 50-minute interviews in a row with a 10-minute break between them, and 15 more minutes before the last one. Each interview contained 40 minutes of problem-solving and 10 minutes of behavioral questions.

For the first interview I had to solve an object-oriented design problem. I had to build an interface that client developers would use to build libraries on top of. It starts off easy and as you progress, the interviewer adds more requirements and problems to solve. It was followed by the behavioral question on how I dealt with a failed deadline.

The most important advice at this point - do NOT start solving problems until you fully understand them. Think of these interviews as brainstorming sessions - talk to your interviewer, ask him questions, discuss your solutions, and when you know exactly what you are supposed to do, go ahead and do it.

Another important advice - if you’re stuck, do ask for a help. The worst thing you can do is quietly stare at the whiteboard having no idea of what to do next.

For the second interview I was asked to solve a product-focused algorithmic problem. I needed to find the right approach, identify appropriate data structures and algorithms, and write a code to get the problem solved. In the last 10 minutes we talked about the situation where I had a conflict with my teammate.

For the third interview I was building a system design for various product use cases. I was drawing system components on the whiteboard, explaining how they communicate and what they are responsible for. As a situational question I was asked if in my professional experience I had worked on something without getting approval from my manager.

The last interview was a purely technical, algorithmic problem. It was relatively easy, so I started by asking whether I should provide the basic solution or start with an optimized one right away. He asked me to do the basic solution first followed, of course, by its optimization. We iterated several times on that before we ran out of time. The interviewer then asked me to tell a situation where I would have done something differently from what I actually did.

When you get out of the interview, you have a feeling that you failed completely, since you couldn’t get any problem to the point where interviewer would have said, “Great! Now that’s the perfect solution!” Let me assure you - that is fine! You are not supposed to find it. Interview problems are designed exactly in this way, where you won’t be able to provide a complete solution in 40 minutes. Instead, interviewers want to see how far you can get and what your thought process looks like.

June 16: Offer

It took Amazon eight days to make a decision. A recruiter from the Berlin office sent me an email on Friday evening saying that I was selected for the position. We discussed details on Monday, and three days after, on June 16th, I received the final offer with the numbers.

Following day we clarified a list of questions I had as well as a few others I needed for my resignation process at my current company. Shortly after an official YES was sent to Amazon.

References

Acknowledgements

Anton Popov mentored me throughout the hiring process and discussed drafts of this post together with Sherzod Abdujabborov and Umed Khudoiberdiev.

The article was translated and published in the following languages:

It has also generated some interesting discussions in the community:

Go from PHP engineer's perspective

Thu, 25 Feb 2016 00:00:00 UTC

As a PHP engineer, have you ever asked yourself whether you need to master other programming languages?

PHP has been the language of choice for building a full-stack monolithic applications for many companies and many years. Furthermore, in the last 5 years frameworks (Symfony, Laravel, Zend), tools (Composer, Monolog) and rapidly growing community (PHP-FIG) helped many engineers to build enterprise level software applications. Many companies, such as Facebook, Yahoo!, Wikipedia, Wordpress, Tumblr, had pure PHP in their early days, and that didn’t hold them back from becoming successful over the years.

However, a successful business grows, so grows the number of engineers it needs to support the growth. Organizational structure of the company indicates that the existing monolith is better be split apart. At some point the strategy stabilizes and teams now focus on independent services instead.

In this article we will try to evaluate how far can PHP alone take us and where Go can step in and solve problems we will face down the road.

PHP and microservices

As a PHP engineer, you know that if you manage to get initialization time on every request down to 30ms in a large monolithic application, that’s great! Add 50-100ms more for the actual request processing, and you have an amazing overall response time.

Since we plan to break our monolith apart, what will happen if we stick to the same setup for our services? Simple calculations, and we have 300ms of just bootstrap time if services interacted 10 times with each other during the same request. What a bad user experience!

While PHP shines in WEB development, its capabilities in microservices architectures are rather immature. Essential terms, such as timeout handling, health checks, metrics collection, bulkheads, circuit breakers, are often unfamiliar to a PHP engineer. Most of them you will find in a variety of frameworks in many other languages out of the box. Support for them in the PHP ecosystem is very poor, if exists at all.

Meet Go

From Wikipedia:

Go (often referred to as golang) is an open source programming language developed at Google in 2007 by Robert Griesemer, Rob Pike, and Ken Thompson. Designed primarily for systems programming, it is a compiled, statically typed language in the tradition of C and C++, with garbage collection, various safety features and CSP-style concurrent programming features added.

Go was developed at Google. It was not a fun 20% project, neither it was to achieve something that others could not do. It was simply created out of the frustration of dealing with the complexity generated by very large teams working on very large pieces of software written in languages with large feature sets.

While it has great features like easy concurrency or fast compilation, the main feature that makes it special is extreme simplicity. On a related note, the list of keywords counts to 25 compared to 67 in PHP.

Go appeared on the market roughly at the same time when PHP received the support for namespaces (2009). In just 6 years there’re already dozens of great projects, among others Docker, Kubernetes, etcd, InfluxDB, and tons of companies like Cloudflare, Google, Dropbox, SoundCloud, Twitter, PayPal that build their backend systems in Go.

Back to microservices

Let’s walk through the problems we talked about previously and see what we can benefit from using Go.

Go applications quickly compile to machine code. Many people claim that compiling time is so fast that by the time they switch to a browser and hit “Refresh”, the application is already recompiled, restarted and serves the request. Even with large codebases there’s a feeling that you’re working with an interpreted language, just like PHP.

Traditional “Hello, World!” API is written in 10 lines of code and responds in less than a millisecond. Multi-core capabilities allow engineers to run heavy pieces of their software in parallel. The ecosystem allows to choose any transport protocol such as JSON over HTTP, gRPC, Protocol Buffers or Thrift. Requests are easily traced in Zipkin. Metrics are exported from statsd to Prometheus. Enforce incoming or outgoing request throughput with rate limiters and protect client-service communication with circuit breakers.

More about Go

Language

Go is a strictly typed language, which requires that you specify the type of the variable during its initialization:

var name string = "sobit"

Variables can infer the type of the value on the right hand side. The above code is equal to its shortened versions:

var name = "sobit"

// or even better:

name := "sobit"

Now, let’s remember how we swap values of two variables in PHP:

<?php

$buffer = $first;
$first = $second;
$second = $buffer;

And here is the equivalent in Go:

first, second = second, first

This is possible due to the ability of multiple return values. An example of a multiple return values function:

func getName() (string, string) {
    return "sobit", "akhmedov"
}

first, last = getName()

In Go code you won’t see so commonly used foreach, while and do-while. They are unified into a single for statement:

// foreach ($bookings as $key => $booking) {}
for key, booking := range bookings {}

// for ($i = 0; $i < count($bookings); $i++) {}
for i := 0; i < len(bookings); i++ {}

// while ($i < count($bookings)) {}
for i < len(bookings) {}

// do {} while (true);
for {}

While Go doesn’t have something called “class” or “object”, it does have a type that matches the same definition of a data structure that integrates both code and behavior. In Go this is called “struct”. Let’s use an example to illustrate it:

type rect struct { // define a struct
    width  int
    height int
}

func (r *rect) area() int { // define a function on struct
    return r.width * r.height
}

r := rect{width: 10, height: 15} // initialize
fmt.Print(r.area())

Sometimes it can be useful to define a complex structure as well. Here is an example:

type Employee struct {
    Name string
    Job  Job
}

type Job struct {
    Employer string
    Position string
}

// and to structure it
e := Employee{
    Name: "Sobit",
    Job: {
        Employer: "GetYourGuide",
        Position: "Software Engineer",
    },
}

There are tons of other features I’m eager to talk about, but that would have me duplicate the great Effective Go document from the official website and producing a never-ending article. But I would like to take a little moment to introduce you to the concurrency in Go, which I find to be one of the most interesting topics about the language. Before we jump in, two things you need to know about concurrency in Go - goroutines and channels.

A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. When the call completes, the goroutine exists, silently. Simplest examples is to create a heartbeat function that will print the “I’m alive” message to the terminal every second:

func heartbeat() {
    for {
        time.Sleep(time.Second)
        fmt.Println("I'm still running...")
    }
}

Now, how do we run it so that it executes in the background and allows us to do other things in parallel? The answer is easier than you might think of, just prefix the call with go:

go heartbeat()

// keep doing other stuff

The approach is similar to “fire-and-forget” events triggering. But what if we don’t need to forget and are interested in the result the function produces? This is where channels come to play:

func getName(id int, c chan string) {
    c <- someHeavyOperationToFindTheName(id)
}

func main() {
    c := make(chan string, 2) // allocate a channel

    go getName(1, c) // trigger
    go getName(2, c) // don't wait and trigger again

    // keep doing other stuff

    fmt.Printf("Employees: %s, %s", <-c, <-c) // combine
}

To summarize, we just triggered the same function twice and let the application execute them in parallel, and asked to give us back the results at the point where we actually needed them.

Tools

Go was designed, again, with the simplicity in mind. Authors took a rather radical approach to solve common activities engineers do all day long. Say “Goodbye” to the endless “space-vs-tab” battles, code standards from community groups who are trying to somehow simplify the way engineers share code. Go brings the go fmt tool out of the box which takes care of styling your code. No more sharing of IDE configuration files, no more attempts to remember if the opening brace should go on the same or on the next line.

The documentation of the package source can be read using go doc, while go vet will help finding potential problems in the code. Installing vendor libraries is as easy as running go get github.com/[vendor]/[package], and tests are executed by triggering go test [package] command. As you can see, most of the tools that engineers include to every application in every language is already here, out of the box.

Deployment

Deployment is a mandatory action no matter which language you choose or what you’re building. Being a PHP engineer, how many Capistrano or Envoy configurations have you written in your professional life? How many manually changed files have you transferred over FTP to your hosting provider back in the days?

This is how the most common and simple PHP deployment process looks like:

Checkout the latest code on the target server into a new release folder
Copy cached dependencies and install updated ones
Copy environment-specific configuration files
Run all the scripts to warm the application up
Point the current release symlink into the new release folder
Restart PHP-FPM

Some teams can take this process into a more advanced level like:

Checkout the latest code on the build server
“Build” it (install dependencies, warm the caches up, etc.)
Create a distributable “artifact” (an archived tar.gz file)
Transfer the artifact to the target server
Unarchive into a new release folder
Point the current release symlink into the new release folder
Restart PHP-FPM

Of course, besides that you need to make sure your target and build servers have at least PHP-FPM and PHP installed, and they better match their versions between each other as well as the version engineers use for local development.

And now let me introduce the deployment process of a regular Go application:

Checkout the latest code on the build server
Build it (note the absence of quotes)
Transfer the artifact (again no quotes) to the target server
Restart the running application

And that’s it. The only difference between potentially simple and advanced versions is whether to have a standalone build server for that or not.

The beauty is that you don’t even need to have Go installed on your target servers, and even if they are running different operating systems or based on different CPU architectures, you can still prepare artifacts for all of them (even for Windows) from a single build server or any other machine.

Conclusion

It was never recommended to decompose a system into microservices while it is not mature enough. While small, a business has to be flexible and react quickly to the opportunities in the market. This is not an ideal environment for building microservices, and more benefits can be achieved by having a monolith instead. PHP with its ecosystem perfectly fits into this strategy.

When the organization stabilizes and it is easy to identify its bounded contexts, building microservices in PHP to complement them may be painful. Various tools and techniques exist in many other languages to support such architecture. You may put yourself into risk to either build your own tools or refuse them completely - both can be costly for your organization.

On the other hand, building microservices in Go is worth considering. The language is easy to write and understand, its learning curve is not that steep as with Java or Scala, and the performance is not far behind C. The compilation time keeps engineers efficient, while the support for multi-core or networked machines makes it possible to write powerful applications.

Additional resources

The best place to land for a new gopher is probably the learning section on the official website. It includes an interactive introduction to Go to try it out in your browser as well as the best practices document that will help understanding how to write clear, idiomatic Go code.

If that feels not enough, there’s a collection of community-driven initiatives to help sharpening newly acquired skills.

If you’re the same fan of JetBrains IDEs as I am, check out the excellent Go plugin for IntelliJ, which is developed mostly by the same JetBrains developers. It can be installed on almost any of their IDEs, including PhpStorm. For other IDEs and text editors, visit wiki page.

When you feel like ready to build your first production-ready microservice in Go, I would encourage you to look at Go kit. It is a programming toolkit that strives to solve common problems in distributed systems to let engineers focus on the business logic.

Least important, but worth mentioning, is the possibility to build client side JavaScript applications using GopherJS and entirely native or SDK applications for iOS and Android.

The topic was presented at GetYourGuide’s internal tech talk with these slides:

Cracking Hackerrank - Encryption

Thu, 18 Feb 2016 00:00:00 UTC

As a friend of mine loves to say, “The best way to learn a programming language is to start writing algorithms in it”. While that most probably won’t make you the language expert, there’s a high chance that you will face most of the data structures it provides as well as feel the power of it’s unique language constructs.

There’re lots of good resources to help you get started, but I prefer to spend my spare time on Hackerrank. It’s free, has pleasant user interface and a solid selection of algorithmic problems conveniently broken down into categories and difficulty levels.

After solving each problem, the whole analyzing part is usually getting thrown out. And that pointed me to the idea of writing the way of thinking into blog posts. Always good to look back and see how good you were and how bad was your English. So let’s get it started!

Our today’s problem - “Encryption” (link to the challenge).

Step 1. Detect the grid size

The problem defines a handful of conditions to detect the grid size:

floor(sqrt(L)) <= rows <= columns <= ceil(sqrt(L))
rows * columns >= L

If multiple grids satisfy the above conditions, we will choose the one with the minimum area, i.e. rows * columns.

Let’s use the sample input and output provided by Hackerrank for the sake of clarity in the decision we will make. More concrete, the string haveaniceday should produce hae and via ecy.

To have some base for the manual calculations, we are going to start by resolving the conditions:

L = len("haveaniceday") = 12
sqrt(L) = sqrt(12) = 3.46
floor(sqrt(L)) = floor(3.46) = 3
ceil(sqrt(L)) = ceil(3.46) = 4

By placing these values into the first condition,

{% highlight text %} 3 <= rows <= columns <= 4 {% endhighlight %}

we get the idea of the grid sizes available to us. Let’s analyze each of them in the ascending order:

3 * 3 = 9 - the condition rows * columns >= L is not satisfied
3 * 4 = 12 - the condition is satisfied
4 * 4 = 16 - the condition is satisfied, but the area is larger than the one of the previous grid

Based on the knowledge we’ve got, let’s write our solution to the first step:

1. rows = columns = floor(sqrt(L))
2. if rows * columns < L then columns = ceil(sqrt(L))
3. if rows * columns < L then rows = ceil(sqrt(L))

And the actual code in Go:

func detectGridSize(l int) (int, int) {
    s := math.Sqrt(float64(l))

    f := int(math.Floor(s))
    if f * f >= l {
        return f, f
    }

    c := int(math.Ceil(s))
    if f * c >= l {
        return f, c
    }

    return c, c
}

Step 2. Populate the grid

Using the values we calculated (rows = 3 and columns = 4), let’s represent our initial string in the form of a grid:

have
anic
eday

Populating the grid is fairly simple:

1. iterate i from 0 to rows
2.   iterate j from 0 to columns
3.     if i*N+j is less than string length, equal G[i][j] to S[i*N+j]

And the code in Go:

func populateGrid(g [][]byte, s string) {
    for i := range g {
        for j := range g[i] {
            if k := i * len(g[i]) + j; k < len(s) {
                g[i][j] = s[k]
            }
        }
    }
}

Step 3. Print the grid columns

The remaining piece of the problem is to display the resulted grid. The first column constructs the first word, followed by a space, followed by the word constructed from the second column, and so on:

1. iterate j from 0 to columns
2.   iterate i from 0 to rows
3.     if G[i][j] is set then print G[i][j]
4.   print " "

The code implementation:

func printGridColumns(g [][]byte) {
    for j := range g[0] {
        for i := range g {
            if (g[i][j] != 0) {
                fmt.Print(string(g[i][j]))
            }
        }
        fmt.Print(" ")
    }
}

Getting everything together

package main

import (
    "fmt"
    "math"
)

func main() {
    var s string
    fmt.Scanln(&s)

    m, n := detectGridSize(len(s))
    g := make([][]byte, m)
    for i := range g {
        g[i] = make([]byte, n)
    }

    populateGrid(g, s)
    printGridColumns(g)
}

func detectGridSize(l int) (int, int) {
    s := math.Sqrt(float64(l))

    f := int(math.Floor(s))
    if f * f >= l {
        return f, f
    }

    c := int(math.Ceil(s))
    if f * c >= l {
        return f, c
    }

    return c, c
}

func populateGrid(g [][]byte, s string) {
    for i := range g {
        for j := range g[i] {
            if k := i * len(g[i]) + j; k < len(s) {
                g[i][j] = s[k]
            }
        }
    }
}

func printGridColumns(g [][]byte) {
    for j := range g[0] {
        for i := range g {
            if (g[i][j] != 0) {
                fmt.Print(string(g[i][j]))
            }
        }
        fmt.Print(" ")
    }
}

Further steps

The solution we have already passes all the test cases prepared by the Hackerrank team. But can we do even better?

It’s easy to spot how inefficient last two steps are, as both of them are iterating through all the elements inside our grid. Do we really need to do it twice? Do we need to have the grid populated? Do we need to initialize the grid at all?

If you answered “No” to all of the questions - fantastic! And let’s see what our optimized solution looks like:

package main

import (
	"fmt"
	"math"
)

func main() {
	var s string
	fmt.Scanln(&s)

	m, n := detectGridSize(len(s))
	encodeString(m, n, s)
}

func detectGridSize(l int) (int, int) {
	s := math.Sqrt(float64(l))

	f := int(math.Floor(s))
	if f * f >= l {
		return f, f
	}

	c := int(math.Ceil(s))
	if f * c >= l {
		return f, c
	}

	return c, c
}

func encodeString(m, n int, s string) {
	for j := 0; j < n; j++ {
		for i := 0; i < m; i++ {
			if k := i * n + j; k < len(s) {
				fmt.Print(string(s[k]))
			}
		}
		fmt.Print(" ")
	}
}

And now it is almost twice as fast with 16 lines of code saved. Isn’t that great?