Getting to Know Val Markovic

LinkedIn wouldn't be the company it is today without the engineers who built it. We have no shortage of talented individuals in technical roles across the company. They are the ones who create, build, and maintain our platform, tools, and features—as well as write posts for this blog. In this series, we feature some of the people and personalities that make LinkedIn great.

Val Markovic is a Senior Software Engineer at LinkedIn, working on the Feed Data Platform (FDP) team. His team is responsible for storing, indexing, and serving organic “activities” (the little boxes of content that make up the feed you see when you log in). Their main service is FollowFeed, which powers the index of activities.

Before joining LinkedIn in August of 2015, Val worked on Google Search for about four years. There he researched ranking signals, employed machine learning to improve Search, worked on internal tools for Search Analysts, and various other things.

Prior to all that, he graduated from the University of Zagreb (his hometown) with a bachelor’s degree and master’s in computer science.

What are some of the coolest projects that you and your team have been working on?
Recently I’ve been working on improving the handling of spam and low-quality content in the feed. As part of that, we’ve built an Entity Graph which makes it possible for us to see how the various entities that make up the feed relate to one another. While this may sound easy, it’s actually incredibly hard to build correctly at our scale and in the face of concurrency across a distributed cluster. It’s super challenging, but fun as well. And now that we have this infrastructure, we’re finding all sorts of ways we can leverage it to improve the member experience.

What other projects are you involved in outside of the LinkedIn feed?
Aside from my work on the Feed Data Platform, I’m also a tech editor for the LinkedIn Engineering Blog. I review articles in the queue to ensure that they don’t have tech-related errors and that the content is explained at a level where other software engineers who might not have as much context as the author can still understand it.

Outside of work, I spend quite a bit of my time creating and working on open source projects. In 2013, I created YouCompleteMe (YCM), a code-completion plug-in for the Vim editor. Today it’s the most popular Vim plug-in by any metric. Also in 2013, I created ycmd, which was me extracting the code-completion engine out of YCM and into a separate server that can be used in editors beyond Vim. Today there are ycmd clients for emacs, Atom, Sublime Text, Kakoune, Visual Studio Code, etc.

While still in university, I created Sigil (an EPUB editor) in 2009 and FlightCrew (an EPUB validator) in 2010. These were very large projects I worked on for years that I ended up burning out on quite a while ago. Both are still being maintained by others, but I’m not involved with their development anymore.

What are your favorite kinds of engineering stories to read on the blog?
I love reading about new technology we’ve developed at LinkedIn and have open-sourced. As someone who contributes to open source regularly, seeing the company I work for develop infrastructure projects with the understanding that they will be made available outside the company gives me that warm-and-fuzzy feeling. A recent example of such a post is Introducing and Open Sourcing Shaky.

The second category of posts on the Engineering Blog that excite me are the ones that provide a deep-dive into how LinkedIn uses a piece of tech. My favorite example of that would be The Log, from 2013 (spoiler alert: it’s about Kafka); every engineer should read that. It’s very in-depth and covers the full breadth of the topic, ending with how LinkedIn tackles this challenge. Another, more recent example is Instant Messaging at LinkedIn; it covers stuff like Server-Sent Events, Akka, performance optimization, etc.

What is the most challenging part of your job?
Effectively communicating with other engineers. Every engineer I’ve ever met has had strong opinions about software architecture, the technology we use (or should be using), the “best” design the team should be focusing on, etc. When you have several developers working together on a project and each has a different opinion about how to proceed, knowing how to carefully navigate these waters is an extremely important skill to have, and probably the hardest one to learn for software engineers. It’s not something they teach in a computer science curriculum. Unfortunately, a lot of devs don’t even think it’s important (to their detriment).

For those wishing to develop these skills better, I’d recommend reading Getting to Yes and Nonviolent Communication. Coding is easy; convincing others without burning bridges is hard.

What do you love most about software engineering?
What I love about software engineering is the actual process of slowly building up a project to completion; at the end of every day, I’m a little bit closer to success than I was at the start of it. Getting to the final ship time might be a long road, but I can see myself walking along it.

I can compare this to my past experience working on signal research and machine learning. Since experimentation is what signal research is all about, you can find yourself coming up with, testing, and rejecting ideas for months. At the end of those months, you’ll often have nothing more than a (very long) list of ideas that didn’t work—valuable, but not tangible. And then you get yet another “a-ha!” moment, but this time, the idea ends up working out: your final set of signals pries apart the categories in the data exactly the way you wanted. But until you get there, it’s not very fun…at least it wasn’t for me. Others I’ve worked with love that kind of problem, but personally, I prefer building things. I need that joy of evident progress.

Compared to other places you've worked, how do you like working at LinkedIn?
Other places I worked at were pretty great, but LinkedIn tops it all. I see a huge focus on craftsmanship around me, and not only in the sense of “we need to do this well,” but “how do we build this so that it’s easy to maintain and extend in the future?” And when a production issue does happen, projects get spun up to improve the services in question on a fundamental level. Temporary hacks don’t stick around; they get replaced with a better architecture.

But all of that isn’t anywhere as important as the people I work with: I’ve never before seen a greater collection of world-class talent. Every person on my team (and wider) is a great engineer.

What are your favorite things to do when you’re not at the office?
I absolutely love modern board games; I easily own more than 50. By “modern,” I’m not referring to games like Monopoly, but games like War of the Ring, Mage Knight, Twilight Struggle, Five Tribes, and others. I prefer complex, strategic, and long games to simpler ones; finding optimal strategies is super fun! Spending 3+ hours playing an involved board game with family and friends is about as good as an evening can get. It’s also a great way to spend quality time with the people you care about.

The biggest problem with this hobby is storing all the games; some of the boxes are quite large, and at this point I have three bookcases dedicated to board game storage and, frankly, I need another.