Facebook Bootcamp is the best thing in the World

After 5 years at Microsoft I joined company, which product I’ve been using for last 12 years :O

12 years at facebook

Before I forget how amazing it was, I wanted to drop a few lines about Facebook Engineering Bootcamp.

When you are about to join typical company you have to make a decision whether it’s a good fit for you. Usually it’s based on 4 or 5, hour long LeetCode sessions with different members of the team. Of course you talk to your future manager, HR is telling you how great it’s gonna be etc.

Facebook does it differently! Your are being interviewed by people from different teams across the company. Not necessary from the team that you are going to join. It’s actually very unlikely that you gonna end up working with any of them. This allows to remove bias, and make interviewing a fair game. Microsoft and Amazon have huge variation between teams. Somebody who wouldn’t pass interview in one team can be a rockstar in other team.

After you pass the interview and join Facebook, you start as bootcamper. You have usually 6-8 weeks to learn facebook engineering systems, and to find a team. You can to talk to as many teams in the company as you want. These are not interviews, but informal chats. Usually short 30 mins meeting, quick coffee or lunch. Some people call it “Facebook Dating” 😀

Once you determine that there is “chemistry” between you and your future manager, or somebody from the team, then you usually work with that team for a couple of days or a week. Like a real work! They give you desk in their open space area, you get some easy task that is related to what they are working on, and you are a team member for the time being.

Don’t worry about good and bad teams. At Facebook there are only different teams 🙂 I was surprised how everybody I met during bootcamp had slightly different interests and all of us decided to join different teams :O

Usually you want to “try” a few teams to have comparison, and to make connections that might help you in the future. E.g., when you will need to work with different team, or when you will be changing teams. This is the best part of the bootcamp. You can literally give you future job a trial run.

I graduated from bootcamp last week and joined Facebook Marketplace Growth team.

I’ll probably drop a few lines about Facebook Engineering systems in separate post, but I’ll just tell you this: imagine that you can have all your wishes regarding engineering systems fulfilled, and it’s better than that 🙂

If you want to learn more about bootcamp check this note 🙂

Leaving Microsoft…

reseting Microsoft PC

Last Friday, September 13th was my last day at Microsoft. Coincidence was that it was Programmers’ Day = 256th day of the year 🙂

It’s been awesome 5 years! I helped to ship the new Azure Portal, turned hackathon project into Microsoft product announced at //build keynote, helped SeeingAI with a few features, and for last two years helped to grow Azure Search. When I joined the team it was a startup. Now, it’s a mature Azure Service. Along with my everyday job I had awesome opportunities to speak at conferences and meetups around the World about my work. During my time at Microsoft I delivered almost 30 technical talks!

Along that journey I met a lot of awesome and inspirational people. Thanks to them my job was my passion. I was very lucky to have awesome bosses. I want to thank Andrew Birck, Ian Carbaugh, Madhur Joshi, Janusz Lembicz and Pablo Castro for everything they did for me. If you end up working for them, consider yourself very lucky!

Special thanks to Steve Sanderson, Scott Hanselman and Scott Guthrie! Their technical talks made me want to join Microsoft, when I was still in college!

Stay tuned for what’s next!

Azure Search on Azure Friday

Once again I had a pleasure to join Scott Hanselman on Azure Friday. In the past we did a video about Azure Mobile App. This time we talked about Azure Search.

Azure Friday is very casual. You just walk in, and chat with Scott. It just happen to be recorded 😀

In this week’s episode we did a quick overview of Azure Search capabilities. Service, on which, I was working on for last two years.

01:00 – Creating a search index
02:37 – AzSearch.js – Automagical UI and sample React controls
03:27 – Searching the JFK Files
08:00 – Adding search to Scott’s blog

You can deploy JFK Files by yourself. More info in our JFK Files github repo.

Check out AzSearch.js to generate website to search your index!

This is just tip of the iceberg! Check our docs for more! You can start today by creating your first search service. We allow one free service per subscription!

Solution for missing battery icon on Surface Book running Windows 10

Recently I got a Surface Book 2. From the beginning, my battery icon was missing, and I spent hours researching how to fix it. I didn’t even have battery show up in device manager.

To save you hours, here is the solution:

  1. Go to device manager
  2. View -> show hidden devices
    Missing battery icon on Surface Book
  3. Uninstall Surface Serial Hub Driver:
    Missing Battery Icon on Surface Book - uninstall Surface Serial Hub Driver
  4. uninstall all other devices that have warnings*
  5. reboot and wait a few minutes for missing drivers to get reinstalled

(*) – I am not 100% sure step 4 is required, but it won’t hurt and it may help.

After that you should get your battery status back:

Surface Book - battery status

It should also be visible in device manager now:

Surface Book device manager - battery status


Domain-Driven Design – tl;dr

Domain Driven Design

After hearing about Aggregates and Bounded Contexts over, and over again, I decided to check out what Domain-Driven Design is all about. There is a ton of DDD resources on the Internet, but this blog post is for my personal reference. I am publishing it so I can google it, and maybe you find it useful as well. This post is about what DDD is, and how it can help you to write better code.

What is DDD?

According to Wikipedia:

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:

  1. placing the project’s primary focus on the core domain and domain logic;
  2. basing complex designs on a model of the domain;
  3. initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

More pragmatic (and ignorant) definition: DDD is software development approach that focus on business processes over implementation details. This allows developers to work with business people more effectively. It also makes code more maintainable and extendable.

Most important DDD terms (buzzwords):

  • Ubiquitous Language – using business terms for naming classes, methods and variables
  • Domain – functionality of the system
  • Bounded Context – components used to deliver a functionality (AKA domains)
  • Value Object – simple, immutable class representing some business term
  • Entity – class with unique identifier, usually used to represent persistent data
  • Aggregate – group of entities
  • Repository – class used to save and retrieve aggregate (AKA save/retrieve data to/from database)
  • Application Service – your Domain(s) communication layer
  • Anti-corruption layer – layer for interaction with external (or legacy) system
  • CQRS (Command Query Responsibility Segregation) – separates querying for data from modifying data
  • Event Sourcing – storing changes to application state as a list of events, which allows to invoke and process events in producer/consumer fashion

Resources to learn about Domain-Driven Design

There are two DDD bibles: Blue Book and Red Book. I’ve been told to do not read Blue Book as first introduction to DDD, because it’s very “heavy” and hard to understand. People were right. I would also add: it’s not very well written (shoot me for criticizing DDD God AKA Eric Evans).

List of recommended resources, sorted in order that I would recommend to follow if you are new to DDD. I strongly recommend positions in bold!

Notice that I placed Blue Book at the end. It’s hard to absorb. It also suffers from low knowledge/pages ratio.

There is also Domain-Driven Design path on Pluralsight that has nice set of courses around DDD and software design.

My thoughts on DDD

Before diving into DDD I was expecting to learn about something new and revolutionary. After reading about Ubiquitous Language, Aggregates and Bounded Context I still didn’t see much difference between DDD and good, SOLID software design. It feels like DDD is mostly about good object-oriented design presented in particular, formalized way with specific buzzwords (aggregate, bounded context, etc.). In Uncle Bob’s Agile Principles, Patterns, and Practices in C#, there is the Payroll Case Study example that is following clean code, good design and implementation practices. If you were put that example into DDD book…it would fit. If you take examples from DDD books and put it into Uncle Bob’s book…it would fit fine as well.

There are however, some new concepts introduced by DDD. Such as Repository pattern, CQRS or Event Sourcing. Are last two actually DDD? Or they are just related to DDD?

DDD is also enforcing designing system around business domain, not around, e.g. database. That is usually a case when designing architecture from scratch quickly. As 99% of apps are CRUDs, ending up with database driven architectures would be natural. You usually start with file->new project, and go from there. This is not a problem for small apps, but might strike later when evolving the app. DDD solves that problem.

If you are familiar with Clean Code and SOLID design as presented in Agile Principles, Patterns, and Practices in C# then DDD does not bring much new concepts to the table. It may make you think more from a business perspective, and consider using new patterns (Repository pattern, CQRS or Event Sourcing) though.

It’s worth to notice that even if you look at Domain-Driven Design path on Pluralsight, there are non-DDD courses about good/clean design as part of the path. Thus, good design is prerequisite of DDD. On top of that we have mentioned earlier buzzwords, CQRS and Event Sourcing.

Going back to DDD terms (AKA buzzwords), they could be also summarized as follows:

  • Ubiquitous Language – use meaningful names for classes, methods and variables
  • Domain – be aware what problem you are solving
  • Bounded Context – group objects that depends on each other
  • Value Object – simple, immutable class
  • Entity – class with unique identifier, usually used to represent persistent data
  • Aggregate – group of related entities
  • Repository – facade over your persistence layer to make it implementation agnostic
  • Application Service – your system’s API
  • Anti-corruption layer – layer for interaction with external system
  • CQRS (Command Query Responsibility Segregation) – separates querying for data and modifying data
  • Event Sourcing – storing changes to application state as a list of events, which allows to invoke and process events in producer/consumer fashion

What DDD enforces from the beginning is layered architecture that may not always be needed. Should you follow DDD in your projects? The answer is, as always, “it depends”. There are some good ideas there, but being over obsessed with favoring DDD in your design decisions over pragmatism will lead to over-engineering.

After TDD and BDD there is DDD. Should you use DDD in all your projects? No. It’s just a way to design software. Also: using DDD does not mean that you need to use all patterns from Blue Book and Red Book.

It seems like DDD should definitely help in long term, but over-engineering (with CQRS and Event Sourcing) may unnecessary complicate things. Actually, I should say: writing SOLID code would help you…and here we are again: is DDD really something different than just good software design?