6 months with eBay/Adevinta

⚠️ Disclaimer

This article might be relevant for those who have never worked in a big tech company or international environment as I have.

The whole article is my personal opinion and might be not aligned with company policy or vision.

📜 Background

I am Alex and this is a review about being a Junior Frontend Engineer in an international company for the first time. Before the current company, I worked in an agency and a startup on an MVP step. Also, I have changed my career direction to the complete opposite and started from the beginning and my previous specialty was an Architect-Construct Engineer role.

👯 Hiring && Onboarding

The first contact took place at the beginning of November when the outsource HR manager found me and applied me for middle Frontend Engineer. In 4 interviews, we figured out that I do not fit that specific role's expectations.

Despite of that my knowledge level was not enough for middle-level specialists I did not feel any disappointment or straightforward criticism from the interviewers. The mindset of interviewers in the process was more like “you are the specialist, tell us how you do the magic”, not like it was in my native county “we are specialists and have doubts that you are too, good luck with changing our minds”. This was so new for me.

After several months HR manager contacted me again with news of the new Junior Frontend Engineer role. The second interview process was way faster since the company already knew my background and skill set so I had just a product interview and a team interview. After this speeded-up process, I was happy to receive an offer.

Onboarding

The onboarding process contains:

• shipping the new hardware (MacBook Pro, monitor, magic keyboard, touchpad, dock station, web camera, android device for testing [since I have an iOS one])
• company departments introduction
• tools and technologies brief
• “greeting the team” meeting
• setup of the product and 3rd party tools

I needed a lot of help and extra explanations since the international environment was something new for me and I was quite worried about my English and cultural fit. During the onboarding, I has been attached to an onboarding buddy which I have never seen after I got rid of my questions for him. I found the onboarding schema great, it helps you not to ruin the first impression for the team with the clarifications of essentials.

After the onboarding, I am led mostly by the Team Lead and personal preferences.

💬 Communication culture

Communication

Since I am from western Europe I will compare current working communications with the communication I saw before.

These are my highlights:

• I would say “being nice” is a non-written job requirement because everyone I have met so far is supportive and non-critical, which is new for me;
• The company is quite diverse and each of us is super careful about the others’ feelings and expressions;
• Always soft feedback highlighting strengths and weaknesses, but with a focus on the improvement plan which helps to avoid anxiety after the failures;
• You will never be texted out of working hours. We had a situation when our team member took a long vacation so the manager put extra effort to walk through all possible questions to avoid bothering the leaving one when he is out.

Working vertical

Even if the company is made up of thousands of people, our chapter vertical (chapter) contains 137 people.

I would like to highlight a few points that are particularly memorable to me:

• The company lives its key behaviobehaviorsI truly believe in:
• act for max impact
• use your voice
• grow through different perspectives
• win and lose together
• experiment bravely
• Your opinion matters more than your role;
• We share the experience around the teams with non-mandatory sync meetings;
• Even if I do not know personally the specific person from a vertical I do know that this person would be happy to help me (most likely 😅);
• product decisions are made by teams consciously and should be discussed as much as necessary for everybody;
• Company events. I have visited the dinner in the restaurant, online wine tasting, and pride month event;
• Crossfunctional fully packed teams of 2 Frontend Engineers, 2 Backend Engineers, 2 iOS Engineers, 2 Android Engineers, an Engineering Manager, a Product Manager, and a Designer.
• Management as a service;
• Remote work. Visiting the office is not mandatory. Also, I find a nice non-spoken rule to turn on the camera if there are just a few people on a call, that helps to sync better with others;
• Diversity lections, anti-discrimination lections, racism in tech lection
• Retrospectives. Personally, I like them, but I do understand why not everyone does the same;

And couple that I do not like:

• We do not have many team events. Company-wide yes, but not team-wide (only one per quarter). So working remotely is a bless and a curse;
• Retrospectives. I like it, but I can not judge others who do not;
• Motivation comes from explanation (that much that it needs);

🧑‍💻 Development culture

Great:

• Architectural Decision Records;
• A lot of attention for web a11y;
• Biweekly Frontend guild sync to share the experience;
• Code review must be done by 2 developers except you. Usually, it is the code owner and feature owner;
• UX > DX;
• Weekly Tech sync to share important updates;
• The company is a sponsor and organizer of Frontend connect in Barcelona last few years;
• Different documentation for the codebase of the web, iOS, and Android;
• Documentation for the product (!);
• 87% of the code is covered with tests Unit, Integration, and End-to-end (!);
• Holding a hand on a pulse of metrics for performance;
• Holding a hand on a pulse of metrics for errors;
• Open discussions about our current issues and challenges;
• Very comfortable with codebase with TS, functional components, and just a few topics where I got an answer “it is what it is”, mostly decisions made by purpose;
• Each developer I have a chance to contact is super passioned about their topic;
• I was lucky to see how we are creating a completely new team and getting them to work and how my teammates created professional presentations for them with records and a specific team to support the newbies;
• Even though I am in a Junior role I am invited to the architectural discussions which I find very useful whatever much I can understand there;
• Supportive team leaders even if you screwed up;

Team Leader: “This is your first task”
Productions after my deployment:

Not that great approaches:

• No common convention around repos about their descriptions, title;
• Use cases of not-that-important but deprecated methods like in React without up-to-date ADR about it;
• Unstable CI/CD causes delays in delivering the features;

⚙️ Technologies

The product is relatively young, so most modern patterns and tools are used like functional components, TS, and fitted frameworks.

The product is in the process of TS migration and how we put the effort there is very inspiring even if it needs about a year to migrate. Let me explain.

The product is just a few years old, but it is already huge so the business is ready to spend resources on this very technical improvement. Since not all of the employees are familiar with TS’s first setup for it was way away from strict one which means that developers were allowed to use any everywhere, but the rules for TS are changing from time to time and the use cases for any are decreasing with tickets to get rid of created ones.

Also, migration to newer technology is a background process that does not interrupt delivering of the features as well.

Zero bug policy

I was lucky to join when the whole vertical adopted the Zero bug policy. Shortly it means that the whole backlog was restructured and only critical or blocking bugs were identified, and the rest were recategorized as improvements. Once they reached the mark 0 in the product they announced that each new bug gets the highest priority and should be resolved ASAP. Also, it is important to have a convention about what to evaluate as a bug.

🧑‍💼 Management as a service

In my previous experience manager was the controller and rarely a helper. Mostly manager was the person who is giving you tasks and controlled your work with micro-management and it take some time to explain what we are doing, and how and why this was important. I mean it is not bad, but not every day at least. The bad about it was that they never were engineers before management 😭

Here the situation is different. Most of the tasks are made by engineers themselves because they are improvements or suggestions to rethink decisions; the rest are features or epics from product management or principals. So the whole work is based on the trust of the company in you and that you know what to do and the rest of the company asks you to deliver the features, just like it was during the hiring process.

On my 1:1 with my manager, we work on my career development and I am encouraged to drive this and set career goals for myself, rather than goals set for me. So I would call it soft leading and facilitating my direction.

I have found the closest definition of our process in the article.

🧑‍🎓 Learning opportunity

The company encourages personal learning with a budget for conferences, courses, books, etc.
Also, once per quarter, we have Innovation days. It is 3 days of trying something new. For example, you can spend it trying to create an MVP, pitch it for the whole chapter and even get a budget from a company if it is a worthy idea to dig deeper. But just learning and being a spectator during those days is fine too. Being a participant is not mandatory.

In my retirement, I may name another company as the best company I worked with in my life, but for now, I can say that I have never worked with such passionate professionals in a good working environment with a modern tech stack.