How To Make The Right Career Path Decision? Part 1 — The Search
After a decade and a half in the software industry, I have joined Wix as Backend Guild Manager.
During the quest I went through, I kept personal insights and questions that helped me stay focused on the road for my next role. I hope that sharing them with you (including my interview process), in this post will be as helpful to you as it was for me in answering the question “how to make the right career path decision?”
Taking a career path decision is a matter of conscious decision that will require your focus, consistency, rigor and self-discipline. Don’t rush, but rather learn and gain a deeper understanding on what really matters to you
On The Search
My Journey started in the Winter of 2018. It was December, and I was on a business trip to the US with Oren, Cellebrite’s CTO, working on an important project. Back then, I was working, as R&D Group Leader, in one of the most successful companies in the domain of digital forensics.
Surrounded by amazing people, caring for my team, my incredible staff, and my managers, we all set as a goal to make the world a safer place. Yet, I didn’t feel as energized as I expected myself to feel.
How could that be?! I enjoyed what I did, felt satisfied, fully engaged and really started to master the business domain.
One tip I can offer you before you decide to quit your job is to try to distill what exactly is wrong, write it down, be honest with yourself. Otherwise, you might find yourself struggling with the same dilemmas but in a different place.
Let’s explore together with my most important factors (Culture and Business) I personally consider deeply, before starting a new role.
Culture
Engineering culture has a tremendous impact on our effectiveness and our ability to execute. Organizational structure, communication and feedback channels, meetings and ceremonies, learning and knowledge sharing, MVP and lean development, production responsibility, ownership, hiring process and more — are all part of the engineering culture.
I personally pay extra care to the following three factors:
- How independent are the teams? Try to take a closer look at your organizational structure. Your architecture and org structure will eventually look the same. How are the teams divided? Are teams able to deliver independently? Do the teams require a lot of synchronization and integration for delivery? Are they blocked by architectural teams or infrastructure teams that are not part of the core team? If so, are they able to contribute and impact infrastructure by themselves? Often when human synchronization is needed between teams regarding a schema change, non-functional requirements, design or a feature — it hurts and most probably impacts your culture dramatically.
- Ownership and responsibility are leading indicators in your engineering health. There is an enormous amount of research showing that when team members own their work, are held accountable for it by their managers and responsible for the success and failures, great things are starting to happen. Try asking if I, as an engineer, take full responsibility over my code in production? Do I hand it over to QA teams or production teams and rely on their ability to find bugs. Who wakes up at night when there are production incidents? Do engineers own their backlog? And, by the way, when I say backlog I don’t mean only the product features backlog, but of course tech debt, support tools, bugs, production incidents, and product features (inspiring video I like watching “Not just code monkey, by Martin Fowler”)
- Feedback loops and short cycles. One of the biggest challenges in software development is when you end up building software that no one ends up using. The earlier and more frequently you build working software in front of real users, the quicker you understand how valuable it really is. I remember myself working in a company on very large epics asking questions such as “Why we are building this feature?” “Can we think of version one which is leaner?” “How decisions are being made for version scopes?” and getting assumptions from product teams based on a hunch without real data behind their decisions. In addition, understanding the company’s fundamentals regarding CI/CD practices reflects insight on your could be day-2-day as an engineer. Try asking a simple question, “How long would it take the organization to deploy a change that involves just one single line of code? Do they do this on a repeatable, reliable basis?”. At this great talk, What Does Tech Excellence Look Like? Martin discusses the similarity between delivering software and a vehicle that needs to cross long distances. What I like the most is the fact that he highlights the “short cycles” as the key part enabling this ecosystem to exist.
Business
Many of us are here for the technology and challenges but don’t be confused, we are working in a highly competitive business environment. Access to technology, computing power, and cloud resources are becoming a commodity. The systems we aim to build should help our organization gain competitive advantage, scale fast and be profitable over time.
Try to define first the size of the organization you imagine yourself working at. Beware of the differences between a corporate, large growing company and a small startup. Is it B2B or B2C? I always try to understand the elevator pitch of the company, is it going to make the world better with their products? What is the mission statement? I like searching at Crunchbase to gain a deeper understanding of the company portfolio. Use LinkedIn to asses the engineers working there. Search the company profile page, try to locate employees that left the company, don’t be afraid to understand why? Who are the engineering leadership? Who are the company founders? what is their point of view on technology and engineering?
In addition, try to understand the differences between Saas vs On-Premise and their impact on engineering. As public cloud is making a huge leap with regulations and policies, in my opinion there will be less economic justification to run data centers on-premise for the long run. Cloud will be cheaper, more stable and secure by far from any on-premise solution. As I see it, working in Saas ecosystem accelerates the entire engineering chain, enables fast and continuous delivery, boosts the development velocity, enables you to easily observe and measure features impact from first hand. Of course the same (or almost the same) can be achieved via on-premise ecosystems, but with more challenges and human involvement. Working in several great on-premise companies, I remember enjoying hearing war stories from our sales engineering departments but having difficulties with managing physical data centers and taking care for their availability, having multiple staging environments, maintaining simultaneously multiple live branches for hotfixes and taking good and expensive care of the installations, deployments and upgrades in our clients sites.
After mapping the sort of companies I imagined myself working for, I started reviewing their published job descriptions. While revisiting the fifth company it all started to look the same — “come and join us”, “We are a fast-growing company”, “interesting challenges!”, what I was really missing is a glimpse into the world of the engineers from an engineering perspective. Wondering, how my day to day would look like? who are really the leading managers of the engineering organization?
Having recently been through this process first-hand, I’d like to share a little bit about what it’s like in Wix while it’s still fresh in my mind.
The Interview Process
First Contact
If you want to hear real stories and dilemmas about great companies, talk directly to their engineers. Technical meetups and community events are the perfect places to facilitate such interactions. It was Thursday eve, I was attending an event of one of my favorite community gatherings — Tech Leads IL. This private group meets on a monthly basis, to share personal experiences through roundtable discussions on topics related to engineering, scale, technology & humans.
I met Kfir, an old friend of mine, we happen to be both born and raised in the same hometown — Tiberias but we met occasionally at meetups. Kfir has been working at Wix for the last 9 years, we had an interesting conversation about scale and challenges.
We talked a bit about the guilds and companies structure challenges Wix is facing with its massive growth and his own personal plans. I really liked what I heard and we agreed that I will come and meet personally more engineers and start a process for the position of Backed Guild Manager.
On-site Interviews
On the day of the interview, I woke up early and went to Tel Aviv port, to have coffee and enjoy the sea view. The atmosphere was great, there is something with staring at the waves that make you focus and help free your mind.
At my first interview, I met one of the senior engineers working at Wix for the last 6 years also as a guild master. We had an interesting discussion on scale and distributed systems pitfalls. Telling him about a service I once built that tried to stream extremely large amounts of data to our clients. We talked about what happens when you have multiple data centers and how you deploy fix when you have millions of live users.
The next step was meeting my future peers Yuval, Aviva, and Ittai. It’s not that common that you pave your way to the offer via all your peers and even your direct reports. I see it as a signal to a great and healthy culture. As those people will be working with me most of the time, they should be able to answer the question “Am I a good fit for the position?”.
Once the technical interview sessions completed, I met Aviran Mordo, VP Engineering and Yaniv Even Haim, VP R&D. The interviews were mainly around Wix challenges, expectations for such a role and growth opportunities.
Finally, I met Omer Wilner, HR expert, and Tali Ben Haim HRBP. For the entire process, my experience as a candidate was great, felt like I’m already working there. The personal touch in such a growing company was a great sign.
The Home Assignment
Being on both sides of the table as interviewer and interviewee, I liked coding tasks for engineers. I believe it helps reveal sides you won’t come across in any other way. I must admit, having a home assignment for a management position surprised me at first.
But, I actually thought the challenge was pretty fun, relevant, and creative. I was asked to implement a game that turned out to be a mathematical riddle. I started with reading about the algorithm behind this game, understanding exactly the heart of the problem. Once understood I wrote failing API tests, implemented the bare minimum for having a walking skeleton and moved to refactor.
I iterated around this concept for a couple of hours (If this sounds familiar you are right, this is TDD). I chose to code with Clojure and used the CLI to interact with my player. It was not the perfect language for this job, but I thought functional programming practices using immutable data structures and a recursive solution will help me code faster. I took good care of the game execution to be as simple as possible, for trivial user interaction and documentation. Coding was done around 2 am, I’ve wrapped it nicely with a shaded jar, finalizing the readme.md and submitted my test back by email.
Yes I do!
I remember, during my interviews break, I sat at the kitchen hearing half conversations between the engineers, talking about production incidents and planning their lunch. I looked around, no big meeting rooms, transparent walls around small rooms, TV screens with production monitoring KPIs hanging on the walls. Of course you never have all the information, and it’s never 100% certainty, but I felt this is the right decision I should make, I could imagine myself working here.
I got the offer, asked to meet Aviran, my direct manager, before my final signing. We talked about how success looks like and what are my goals as Guild Manager.
At the same day I signed the contract. Yay! I am going to work at Wix.
Ok, So What’s Next?
I hope the things I review will be useful for other engineers who are also on their own unique search. Don’t be afraid to bootstrap yourself toward positions taking you out of your comfort zone and will help you grow, it is in your own hands.
Soon, I’m going to share the 2nd part of this post, which dives in-depth on my onboarding journey into Wix.
If you have any comments, want to share ideas or just come visit and talk about technology challenges, feel free to approach me via LinkedIn or by my email avip@wix.com.
How Do We Hire Backend Engineers at Wix? [Optional Reading]
On average, thousands apply to Wix engineering open position, year by year. Out of them, only a single-digit percentage got hired. To enable such a massive scale there is a well-defined funnel to support the hiring process.
- CV screening
- Screening Call. Typically done by the hiring manager or an engineer, the main purpose of this step is to increase conversion and filter out candidates who don’t have the relevant background and passion.
- Technical Coding Interview. The 1st on-site interview, at this stage you will start by speaking about one of your projects, done by you and that you are proud of sharing. The discussion will be around dilemmas and technical decisions taken. This step will be followed by a coding challenge. You will have to code it using your favorite IDE using any language you feel comfortable with. We will pay special care for: your coding skills, your level of fundamentals in programming languages and how you are getting things done.
- Technical Design Interview. The 2nd interview done usually by two of our senior backend guild engineers. We call it a whiteboard design interview. You will be asked to draw an architecture for a system with a given technical requirement. The main goal is to assess your design skills and your level of understanding of how the operating system works and distributed and complex systems knowledge.
- Guild Manager Interview meeting the engineering management from the relevant company and the guild management. Passion, drive for curiosity and humble are part of the x-factors we are looking at our candidates.
- HR Interview
To ensure the right match for the role and reduce individual unconscious bias, at the point between the HR interview and the Offer, we are holding the committee. A committee is a round table with all the interviewers who took part in the process, having an open discussion, reviewing summaries we had on you and trying to get consensus about how to take things from here. This is how we make sure
