Trust Wallet

My Experience Interviewing at Trust Wallet in August 2023 for the Position of Backend Golang Developer. The entire process took me about 20 days.

About the Company

The company develops a multi-wallet for cryptocurrencies and is a subsidiary of Binance. This is the first cryptocurrency-related company where I have ever interviewed. I am generally skeptical about the reliability of companies involved in cryptocurrencies, but Binance and Trust Wallet inspire much more trust in me than others.

The company hires employees globally, offering the opportunity to work remotely. Communication between employees can be asynchronous in chats.

Preparation

Since I am already a user of their product, I did not need to learn details about the company’s activities. I read reviews and information about interviews on Glassdoor, but I didn’t find anything very useful there. There were almost no interview reports for my position.

Screening Interview

The first interview was typical - a screening with a recruiter. This stage was conducted in English. I was asked about my experience in development, a few simple questions about Go, as well as about my readiness for a test assignment.

At the end of this stage, I was asked to send information about my availability for the following week. The day after the screening, I received an invitation to the first technical interview.

First Technical Interview

A week after the screening, I had my first technical interview. The interviewer was Russian-speaking, and the interview was conducted in Russian.

I really liked this stage, and it became one of the most memorable in my career. Instead of standard questions, the conversation flowed more freely, resembling more of an exchange of opinions and experiences.

The interviewer was interested in my technical experience and activities in my current team. He asked about my specific responsibilities, what I like about my work, and which tools and practices I use. I described all this in detail, which took about half of the time.

Then I was given a small task. I needed to design an offline storage for books in a library for quick searching, choose a data structure for the storage, and explain it. During the solution process, we touched on some technical internals of the Go language. This took up slightly less than the remaining half of the time.

The remaining time was for my questions, and I had many. I asked about the specifics of the work, internal processes, and the team.

Test Assignment

Three days after the technical interview, I received an email about successfully passing the previous stage. I needed to inform them of my readiness to start the test assignment, which was to be completed within 3 days.

The task was to develop a component for parsing Ethereum transactions using Ethereum JSONRPC. A mandatory condition was to avoid using third-party libraries. The task description mentioned that the time guide was 4 hours, but the actual time wasn’t tracked, and there were no requirements for perfect execution.

I spent more time on the task than the recommendation — about 6 hours. Approximately one hour went into studying Ethereum’s documentation and developing the solution’s architecture, defining modules, and areas of responsibility in the code. Then, I spent about 3 hours writing the main code and tests, and the last hour on numerous minor refinements. In addition, a friend and colleague of mine helped me review my code and suggested several ideas and improvements.

Outcome of the Test Assignment

I published my code for the test assignment on GitHub. Also, after submitting my code, I found another candidate’s test assignment results on GitHub.

I was promised a response to the test assignment within a week. At the end of the week, I reminded them about myself but didn’t receive an answer. On Monday morning, I received a standard rejection email: after careful consideration, their team decided not to move forward this time. There were no further details or feedback. I decided to seek more detailed feedback on the test assignment and wrote an email to the recruiter.

One day later, I received an email with feedback. The solution was considered good enough and suitable for a number of tasks, but they were looking for a more advanced option. According to the reviewer, my solution had its pros and cons. Pros:

• subscribed addresses are checked in O(1);
• context passing;
• dependency injection;
• tests.

Cons:

• complex and inconvenient implementation of the JSON client;
• inefficient error handling, lacking a mechanism for wrapping errors;
• use of sync maps and mutex for data storage, although only a mutex was necessary;
• lack of control over the parser’s parallel operation;
• complication of the process with transactions in the database, which, in real conditions, would likely be inefficient.

Conclusion

Overall, I liked the interview process, except for the response time and feedback. The results of the test assignment assessment raised more questions and disagreements for me. Some of the indicated shortcomings, in my opinion, are subjective and could be the subject of discussion. Some of the shortcomings were known to me and mentioned in the TODO in the README, as their implementation required more time. With the remaining shortcomings, I fully agree and have no further objections.

I consider the outcome of the interview more as a matter of luck, as it’s hard for me to imagine what a perfect version could be within the recommended 4 hours without using third-party libraries.