In software companies, it’s a common practice to assign engineers to specific teams, each responsible for their respective deliverables. While this approach can work well in the short term, I firmly believe that gaining exposure to different teams is essential for long-term professional growth.

However, it’s important to note that not all companies readily embrace this idea. In some organizations, the notion of engineers moving between teams can be perceived negatively, as it may be seen as a lack of loyalty to the team they’re originally assigned to. While cross-team collaboration for specific projects is commonplace in many companies, these initiatives are often driven by business needs rather than a deliberate focus on individual growth.

Let’s consider how your manager might react if you were to express a desire like this in your next meeting:

‘I’m eager to contribute to the exciting projects happening in the XYZ team for the upcoming quarter and then bring the knowledge and experience back to our current team.’

It’s hard to predict, but there’s a real possibility that your manager might not immediately embrace this idea, potentially leading to rejection. 😔

On the flip side, there’s a chance that your manager could propose a different approach — suggesting that you permanently join the XYZ team instead of temporarily.

Drawing from personal experience, it’s worth noting that expressing a desire to collaborate with different teams may not always be well-received in some companies and could even be perceived as a negative trait.

I’ve encountered only a handful of companies that genuinely encourage employees to venture into different teams solely with the aim of enhancing their career growth.

In this blog post, I intend to shed light on the impact of cross-team collaboration, drawing from my own enriching experiences with embedding in a different team at Spotify. By sharing my journey and insights, I aim to underscore not only the general advantages of this practice but also how it has personally shaped my career and contributed to the vibrant work culture at Spotify.

Spotify’s organisational culture excels in the practice of embedding team members across various departments, and for good reason. Different teams have varying skill requirements, which can fluctuate frequently. For instance, exceptional engineers specialising in a particular platform, such as Android or iOS, might find themselves under-utilised in their current teams. This presents a unique opportunity for them to explore other teams within the company that urgently require their specific skills, making the most efficient use of their expertise at that point in time.

What sets Spotify’s approach apart is its flexibility. Embedding durations can vary widely, spanning from just a few weeks to several months, depending on what the team deems most suitable. This adaptable approach not only fosters cross-pollination of skills but also encourages a dynamic, responsive work environment that can swiftly adapt to the ever-evolving demands of the industry. The result is a workplace that thrives on versatility, learning, and an unwavering commitment to excellence.

In simpler terms, embedding implies that the engineer dedicates their full-time efforts to the new team, often with little to no ongoing obligations or responsibilities to their original team.

Here are some of my key takeaways from embedding in different team :

1. Connecting with Fresh Perspectives
   One of the most significant advantages of embedding in a different team is the opportunity to engage with new people and team members. Not only do you get to collaborate with a diverse group of individuals, but you also gain insights into their unique work practices and engineering approaches. Building relationships with colleagues from various teams broadens an engineer’s professional network. These connections can be invaluable for future collaboration, knowledge sharing, and career growth.
2. Bilateral Knowledge Exchange
   Beyond the interpersonal benefits, there’s a substantial potential for knowledge sharing in both directions. Those embedding into a new team can acquire fresh insights into the team’s working methods, while also imparting the practices from their previous team. This cross-pollination of knowledge can extend to various aspects, including how regular meetings are conducted, such as standups, retrospectives, and the process of introducing new features. During my embed, I engaged in code pairing sessions with a variety of mobile engineers also the team work on iOS which allowed me to explore a new platform and expand my skills.
3. Exploring Varied Aspects of the Business
   In many instances, a single team is assigned a specific challenge, requiring all its members to focus exclusively on that issue. This often leaves little room for individuals to delve into different facets of the business or contribute to alternative problems. Even if an engineer has the willingness to address a different problem, they may find themselves burdened with extra responsibilities, making it impractical. I had embedded in a team that addressed a distinct domain of problems which helped me gain more understanding of the business. I have seen other good example of embedding viz, an engineer working on feature development teams embeds into the developer platform team, gaining exposure to diverse developer challenges and ultimately evolving into a more well-rounded engineer
4. Enhanced Comprehension of Organizational Structure
   In a post-COVID landscape, where remote or hybrid work models are prevalent, employees have fewer opportunities for in-person interactions and discussions beyond work-related matters. As I had to work with all together a different team during my embedding, I gained valuable insights into Spotify’s ever changing complex company hierarchy and structure, an I am sure this is a real problem for any mid size company working remotely to give a clearer picture of the company’s internal structure.
5. Exploring Diverse Problems and Platforms
   The beauty of embedding is that it transcends platform boundaries. For instance, consider an iOS engineer who harbors an interest in tackling data-related or release-related challenges, or even problems on a different platform altogether. Embedding offers a perfect avenue for such explorations. This type of embedding not only provides a platform for honing skills but also facilitates a transition toward becoming a more versatile full-stack developer.
6. Knowledge Transfer for Team Enrichment
   While the primary goal of embedding is to fuel an engineer’s personal career growth by working on the right challenges, there’s a secondary objective that’s equally motivating: sharing the knowledge acquired with their home team, which can ultimately benefit the entire team. For instance, an engineer who embeds with the release squad for a quarter can bring back invaluable insights into the release process and related intricacies. This transfer of knowledge ensures alignment within the team’s processes and, when feasible, allows for the education of the whole team or adjacent teams using the insights gathered during the embedding experience. This knowledge-sharing not only bolsters individual growth but also fortifies team capabilities.
7. Discovering Your Ideal Team
   Working in a different team, addressing diverse business challenges with a fresh approach, can provide engineers with a new perspective on their career. In the process, an engineer might realize that they are genuinely interested in being a part of the new team on a permanent basis. This approach empowers engineers to make an informed decision rather than being randomly assigned to a team, with the hope that their skill set matches and the team is a good fit. Additionally, it allows managers to gain a deeper understanding of the engineer’s contributions, passion, and working style, aiding in the assessment of whether the engineer is the right fit for the team.
8. Investing in Internal Talent for Holistic Growth
   In the long term, prioritizing internal talent investment yields significant benefits for a company. Nurturing and developing a robust internal talent pool enhances resource utilization and ensures more effective and streamlined operations. Furthermore, it greatly reduces the “truck factor” — the risk associated with key employees leaving the company. This commitment to internal growth ultimately leads to a stronger, more resilient organization.
9. Diverse Feedback for Dynamic Growth
   While embedding in a different team, engineers have the invaluable opportunity to receive feedback from a variety of perspectives, which often differ from those within their original team. This influx of diverse feedback enriches their growth journey, enabling them to adapt and improve in a more holistic and dynamic manner. The multi-faceted input from various team members accelerates their personal and professional development.
10. Boosting Employee Satisfaction
    Offering the chance to embed in various teams demonstrates the company’s commitment to employee growth and well-being, which can lead to higher job satisfaction and retention rates.

Embedding is not a concept confined to individual teams or a select group; rather, it’s an approach that should be wholeheartedly embraced by the entire organization for maximum effectiveness and benefits. The company’s commitment should extend to the creation of internal tools that facilitate the discovery of suitable embedding opportunities for engineers. Simultaneously, promoting the concept of embedding should be a top-level leadership initiative.

In my view, embedding represents a win-win scenario for both engineers and the organization as a whole. In the long run, this practice culminates in the development of a remarkable internal talent pool, fostering a culture of growth, adaptability, and enduring success within the organization.

For further insights into the implementation of embedding and internal mobility, I recommend checking out Spotify’s blog post on the subject. It offers a deeper dive into how Spotify has successfully embraced this practice.

From my personal experience, I have come across very few companies that wholeheartedly adopt this remarkable internal talent mobility strategy. If you’re aware of other companies that also excel in this aspect, please feel free to drop a comment and share your insights. 🗨️

A heartfelt shoutout to all these companies for their outstanding efforts in nurturing internal talent and fostering a culture of growth and adaptability. 👏👏 Your commitment to innovation and employee development is truly commendable. 🌟

Spotify is one of the best Engineering company to work for and it has always been my dream company to work. After putting lots of efforts in interview preparation and giving interviews at many other companies I was lucky to crack the interviews at Spotify.

Spotify stood out from all other companies in terms of way they conduct the interviews (focusing on the right aspects in each interview) and a very smooth coordination by the recruiter right from start till the end.

During this pandemic, in-person interviews has become a thing of the past. Most of the companies are following the virtual interview process, and it generally takes a bit longer to schedule the interviews as everybody are working from home and from different time-zone.

It took almost 2 months for me to complete the whole interview process at Spotify.

Lets cut the long story short and lets focus on the main part — The interview process.

I applied to Spotify Android Engineering position, based out of Stockholm - through the career website. Spotify career website is very comprehensive and has a detailed information for all the openings and the application procedure. You can have a look at the website here.

Within a few weeks of me submitting my application, I was contacted by the recruiter via email for the initial phone call. The recruiter was very friendly and supportive. The initial call is meant to understand the candidate better and also make sure the candidate understands the company and job description well.

If all goes well in the initial call, the recruiter invites the candidate for the further interview rounds. In my case all was good and I was invited for the further rounds.

The overall interview process looks simple, after the initial phone call there are two parts for the interviews : second round and then the final rounds.

Note: Every round of interview had a panel of 2 interviewers, there is nothing to worry here, mostly the other person is shadowing the main interviewer.

The second round of interview is more of a screening in detail round. This round covers a number of topics including but not limited to technical background discussion, Android domain questions and a bit diving deeper into some areas, there is also a coding exercise in Java and Kotlin and finally few follow up questions.

This round went really well for me. Within a few days my recruiter reached back to me stating everything looks fine and they want go ahead with my further interview round.

Finally, there comes the final rounds or few companies also call it as onsite rounds. This is most hectic and the difficult part of the interview process, but there is nothing to worry as the recruiter will explain everything in detail.

Final rounds consists set of 4 different interviews which are1 hour each. Preferably all these rounds are packed in a day or two according to the availability of the candidates and the interviewers. Scheduling the final rounds generally takes couple of weeks and hence there is plenty of time to prepare in between 😃.

There are 4 different rounds in the final interviews/Onsite rounds, below is a brief overview of each of them:

1. Programming/DS and Algorithmic Round: This is a typical algorithms, complexity and data structures programming interview. You’ll be asked to code solutions to problems, discuss their complexity, optimize them, and so on.
2. System Design Round: This interview is about designing, building, and scaling systems.
3. IDE Programming Interview: An interview designed to be as close to your day to day work environment as possible. In this round we will have to open our Android Studio and work through a programming exercise. Make sure the internet connection is good as we have to live code while we share the screen. This is more fun and pair programming session.
4. Spotify Values Interview : This is an opportunity for the interviewers to learn more about the engineering cultures we’ve been exposed to, and mostly to check how well we fit into the Spotify culture. Been honest is the key to excel in this round.

After all the interviews are completed the feedbacks are communicated back within few days irrespective if the feedbacks are positive or negative.

Here are some pro tips for cracking the interviews, for the curious readers:

1. Always start simple and then expand. Most often it’s best to come up with a simple solution and then go from there.
2. The interviewers generally do not expect the candidate should know the answers to all the questions. The main thing is to be honest and accept if you do not know any topic or concept instead of beating around the bush.
3. Don’t hesitate to ask for help if something’s unclear or if you get stuck.
4. Think out loud! Communication is important in order for the interviewers to understand your thought process, so speak your mind and motivate your choices.

Wishing you all the best 😃!!

Life is short and we all are ought to live it to the fullest, and to live it to the fullest we have to love what we do and spend time doing everyday, and to love what we do we have to be good at it and obviously not struggle at it everyday and need motivation to do it.

Trust me building softwares is the best profession I have ever known of because it gives you lots of potential/power to change peoples perception and also the way things are been done. It’s truly wonderful to see this digital transformation.

Let’s admit it.. we always face the oops moments at job when we do not know certain obvious things about software development. By obvious stuff I mean the things that a software developer is assumed not to be taught, rather it needs to be learned and known by default.

Graduating fresh out of college and working for the first time in a company can be altogether a different experience. There will be huge learning curve involved and it is important for the newbies to refer to the right learning resources so that they get on-boarded easily to the team.

In this blog post, I am posting some of the must reading materials (books/websites/ blog/papers) for every newbie in software development or for all those who aspire to be a software developer. This reading material will make software development more easy and fun.

Sit back, take a cup of coffee .. and enjoy the curated list.

I have also given appropriate links to all the bullets so it becomes easy for referring.

• The Clean Code Blog : This is a great blog with all the great blogs post related to great topics in software development. I always read this blogs as I get time.
• Clean Code, Robert C. Martin : : This books is the best known book for writing highly efficient Clean Code. For every software developer writing clean code should be the highest priority and this books presents a revolutionary approach for writing software.
• Clean Architecture : A Craftsman’s Guide to Software Structure and Design: This book is an essential reading for every current or aspiring software architect, software designer and software manager and for every programmer who must execute someone else design.
• The Clean Coder, Robert C. Martin : This book is a great follow-up to Clean Code Book mentioned above. In this book the author explain what every programmer who considers him- or herself a professional not only needs to know, but also needs to follow in order to make the young profession of software development grow.
• The Pragmatic Programmer: From Journeyman to Master : The Pragmatic Programmer illustrates the best practices and major pitfalls of many different aspects of software development, Whether you’re a new coder, an experienced programmer or a manager responsible for software projects, use these lessons daily and you’ll quickly see improvements in personal productivity, accuracy and job satisfaction
• Structure and Interpretation of Computer Programs, Abelson and Sussman
• TDD: By Example, Kent Beck : TDD(test driven development) requires a shift in mindset of programmers i.e. how we write the production code, it is a proven set of techniques that encourage simple designs and test suites that inspire confidence of the developers
• Code Complete, Steve McConnell : This wonderful books many timeless techniques which can be used to design with minimum complexity and maximum creativity.
• Release It!, Michael T. Nygard : This book is best for all software developers who aim to write code with less bug and don’t want to get alerts every single night for rest of the life.
• Domain Driven Design, Eric J. Evans : This book is a fun read with lots of interesting software development stories written. This book is not about drawing pictures of a domain; it is about how you think of it, the language you use to talk about it, and how you organize your software to reflect your improving understanding of the domain.
• Refactoring, Martin Fowler : Refactoring is all about improving the design of the existing code, it is the process through which the internal structure of software is improved without modifying the external behaviour. This books equips the software developer with the best refactoring practises.
• The Mythical Man Month, Fred Brooks : This is a timeless book and very few books on software project management have been as influential as this one. With a blend of software engineering facts and though provoking opinions the author offers great insights for any one managing complex software projects.
• Out of the Tar Pit, Ben Mosely, Peter Marks (paper)
• The Way of Testivus, Alberto Savoia (humour)
• On the criteria to be used in decomposing systems into modules, David L. Parnas (paper)
• Architectural Styles and the Design of Network-based Software Architectures, Roy Fielding (thesis)
• Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services, Seth Gilbert, Nancy Lynch (paper)
• How to become a Hacker, Eric S. Raymond

It is important that you as a software developer grow and flourish each and every day and become the best over time. Quoting an inspirational quote from a famous book :

You don’t drown by falling in the water, you drown by staying there.

Hence, I urge to all the fellow developers that it very easy to get stuck in the infinite cycle of mediocrity where you never realise what you do is correct or wrong , it is important to refer the right material present at your disposable and make yourself better at it, and come out of the mediocrity cycle.

Thats all folks as of now, I will keep updating this list as I encounter more and more great resources over time. Also, if you find this blog helpful, don’t forget to give some claps!!