Sunday, October 28, 2018

The toughest interview questions asked recently

During a recent round of interviews, I was asked these 5 questions that I found particularly interesting / challenging. They each covered a different interesting pieces of computer science that I thought worth sharing. Check them out and see what you think about them:

1. A set of overlapping ranges are provided in [start, end) format. Find the max number of ranges that overlap each given range. Improve your solution to O(N log N) complexity (basic solution is: O(N^2) complexity for a set of ascending ranges [1,4), [2, 4), [3, 4) etc.).
2. Implement a multithreaded producer / consumer queue using condition variables.
3. Implement a multithreaded rate limiter (token bucket with defined capacity) using no hard-coded poll durations and without a background thread for "filling". Discuss fairness vs head of line blocking tradeoffs of the implementation.
4. Implement a multithreaded scheduler that executes tasks repeatedly at specified time intervals which manages task overruns (task time > interval time) and does not skip scheduled run points. Estimate the maximum number of outstanding threads that a task may produce.
5. Given a matrix of size NxM with 0 and 1 entries, find the number of connected regions in the matrix. Extend your solution to handle updates of 0 entries to 1s that may connect existing regions. Expected solution is O(NxM) complexity in the worst case even for the second case with updates being approximately O(1) and space being O(NxM). Hint: Disjoint sets. 

For System Design, the following were interesting questions:
1. Design typeahead search (given a query prefix, provide completions). 
The interesting part was managing hotspots for small query lengths, the use of a KV store for serving given the low latency requirements and managing personalization.
2. Design an ad click prediction system (ML infra pipeline).
3. Design a lineage system for tracking input data to ML model training to avoid sample bias.

Overall, interviewing was a pleasant process that refreshed a lot of skills. Let me know about other interview questions that might have been interesting for you.


Friday, August 17, 2018

Great workplace habits

  1. Wellness: Maintaining a healthy body, mind, and spirit/mood.
  2. Self-presentation: Controlling one’s grooming, attire, and manners—given the social and cultural situation at hand—so as to make a positive impression on others.
  3. Timeliness: Arriving early, staying late, and taking short breaks. Meeting or beating schedules and deadlines.
  4. Productivity: Working at a fast pace without significant interruptions.
  5. Organization: Using proven systems for documentation and tracking—note taking, project plans, checklists, and filing.
  6. Attention to detail: Following instructions, standard operating procedures, specifications, and staying focused and mindful in performing tasks and responsibilities.
  7. Follow-through and consistency: Fulfilling your commitments and finishing what you start.
  8. Initiative: Being a self-starter. Taking productive action without explicit direction. Going above and beyond; the extra mile.
Found from:

I'm not the best at them, but I've found that they have made me a better person. Highly recommended.

Friday, May 11, 2018

Actionable Production Escalations

I've long considered the following items the basics of an actionable production escalation. These were taught to me by Googlers (mostly when I violated these understated values). The fundamentals of any production escalation require the documentation of the following from SREs:
1. An exception, call graph, logs or metrics showing the problem
2. A first pass characterization of the problem (what is it / how much impact)
3. Why me? (Do we need a PoC that you wouldn't know otherwise?) 
4. What have you already tried. 
5. Things that you have noted that are out of the ordinary.
6. How specifically can I help solve this problem? (Find a PoC? look at the code? Judge downstream impact? Validate severity?)

Following the above process keeps a check on the level of due diligence needed before a Dev escalation. It also helps formulate concrete action items as part of the escalation process. I've found that this helps resolve issues quicker and keeps the prod overhead low for devs. What do you think?

Friday, July 21, 2017

The True Worth of a Life

A life is measured not by how much money is earned but how many people are helped while the candle is lit. The people present when the candle blows out represent the true worth of a life. 

Tuesday, May 16, 2017

Thoughts on Software Development: A recent interview

I had a very productive discussion with a few consultants from India recently. The topic of choice was Software Development: specifically, how best to run teams and a good software development process. Here's a quick summary of what we discussed. Hopefully, this will be helpful to a broad audience:

Q1: Team Structure: How best to structure a team, what are the roles and responsibilities?
A: Largely, teams in tech are structured with 2 leaders: a technical lead and a manager. The role of the technical lead is managing the technical aspects of product development (code reviews, commits, design, testing, client team management and tough debugging). The role of the manager is people management (specifically and preferably practicing "'servant leadership"). The manager is responsible for morale, happiness, compensation, budgeting etc. but is not responsible for the technical direction of the team.

In some cases, it makes sense for the technical lead to also be the manager of the team, but largely, it means that one of the two roles becomes secondary to the other. In many cases, teams suffer slightly. 

Within management, there are two schools of thought: manager-leads and TL-leads. In the manager-leads scenario, the manager has the upper hand and decides prioritization of tasks (leads to conflicts with technical direction where business priorities precede technical quality). In the TL-leads scenario, manager is responsible for resourcing of projects but TL leads project execution and budgeting. Such a scenario leads to better incentives around code quality and execution but might have slips on the budget end.

Q2: So which should I choose? Manager-leads or TL-leads?
A: Manager-leads is run by several teams in the industry (Amazon being one of them). While business results are excellent, there is quite a bit of churn on the team. Churn is bad because it makes producing long term, stable infrastructure much harder (because nobody understands the system well enough).

TL-leads is the philosophy followed by Google (and other similar companies). They are OK throwing a little more money and time into problems as long as the results are excellent. Many other companies cannot afford this style of management and they resource a lot more conservatively.

Q3: What's the team composition like? How many people should be put onto a team?
A: A typical team can vary in size but it's important to understand certain ratios. Micromanagement is a big problem in the tech industry - there's always a lot of work and never enough time. In such a situation, an idle manager just slows down projects by constantly asking for updates and communicating them throughout the org.

A healthy ratio of managers to engineers is 1:7 - beyond this point, the manager really doesn't have the time or the ability to micromanage the execution of a project. A ratio of 1:5 or more is better for a TL as well for similar reasons. The absence of micromanagement makes engineers happier and empowers them by giving them more freedom of choice during the execution phase of a project.

Q4: What about Product Vision? What is the role of a Product Manager?
A: Product Management is a glue role. Product Managers do not have engineering reports. They don't have involvement in the execution phase of a project. A typical ratio for Product Managers is 1 PM for 20 Engineers (or around 1 PM for 4 teams). The reason for this large leverage is that execution takes a lot longer than ideation. By having a PM responsible for 4 teams or the work of 20 Engineers, the PM has enough leverage to keep multiple projects running simultaneously. The PM doesn't necessarily have to track the project progress himself (possibly only the key ones might matter), but he does have to answer daily execution questions from the engineers to guide the execution of the project.

Q5: What are success metrics for a team? What are the KPIs of an engineer?
A: You get what you incentivize: At Google, individual engineers are incentivized to product business impact. This means moving customer and product metrics and placing the improved metrics in context. eg. If an engineer improved suggestion quality by 2%, is that a large change or a small change? (At Google, it might be a large change if most improvements to suggestion quality are in the 0.1% range). Producing business impact is rewarded disproportionately at each level. This leads to lots of launches, several failures but a general bias to produce new things. 

Such a system dis-incentivizes routine maintenance work and as a result, product iteration and maintenance isn't as glamorous. Other important metrics are code-craftsmanship and leadership.

LinkedIn follows a similar structure: the key performance scopes are in "Leadership", "'Execution" and "Craftsmanship". In both these systems, individual productivity metrics like "code coverage", "lines of code written", "commits made", "bugs fixed" are de-emphasized because these numbers are easy to game.

Q6: On to general execution: What does the software development lifecycle look like?
A: On a high level, the software execution lifecycle is split into 4 major phases: Design, Build, Run, Maintain. Engineers are expected to design systems, they're supposed to commit infrastructure and code that creates the system, they're supposed to run it and stabilize it in production (with monitoring and alerting) and they're then supposed to maintain their code (This last part is crucial. In a healthy software ecosystem, lots of things have dependencies on each other and things break all the time; having a sense of ownership of the code you've written promotes code maintenance over time and prevents code rot because "it's someone-else's problem").

Q7: Practical matters: What makes it into a software release? How do you decide what to keep and what to cut?
A: The current best practices in software development are continuous integration and continuous deployment. Continuous integration means that every code commit is tested for correctness by running all tests on a machine that is separate and isolated from an engineer's development environment. This ensures that local dependencies don't leak inadvertently into the build / test / run ecosystem. In addition, Build / CI systems like Jenkins and others allow running the tests across a wide variety of environments / devices / versions etc. This ensures that the system is meeting build and code quality across an entire range of project platforms.

A continuous deployment system takes the "continuous integration" concept a step further: once a code commit passes continuous integration, it's automatically deployed to production. Such a style of development requires strict control of code check-ins. New code is always developed behind a feature flag and the flag is always turned off till the time the code is known to be stable. During the stabilization phase of the code, the feature flag may only be enabled for a subset of users but the continuous integration tests should ensure that all tests pass in both scenarios.

In a world of continuous integration and continuous deployment, the concept of a release is made very cheap: if it's built and the tests pass, it's ready for release. If a feature is released and found to be unstable, the feature flag is just turned off and the rest of the binary is expected to run without issues. What makes it into a "cut" is now simply: "is the code committed, are the tests there and do we have enough confidence in the code to turn the feature flag on".

Overall, this was quite a stimulating process. Hopefully, despite the length, this post will provide value to you as well.


Saturday, April 15, 2017

Freelancing for the gainfully employed

I've been professionally employed for a very long time and I was self-employed before then. Life has changed significantly for me, having come to the US from the small college town of Roorkee and my hometown of Jamshedpur.

Over the past few years, I've been knee deep in technology at Google and now recently at LinkedIn. One of the things that I've missed in both these jobs is the freedom of execution that's inherently present when you pick up work of your own volition. 

There's a lot to be said about companies and the infrastructure they provide and there's a lot more to be said about the problems they abstract away. When working for a large firm, you just don't have to deal with the nitty gritty and some skills go to rust. But every single time I've had the opportunity to pick up a project or a hobby outside of work, I've been amazed at the rapid pace of change out in the marketplace: new frameworks, new technologies and new systems keep coming up and dying out. Systems inside companies are much slower to evolve.

So, to just get a quick pulse on the market, I've realized that there's really nothing better than finishing off a quick side project and grounding myself in the current state of the world. When looking at the freelancing marketplace, there were really 3 options of interest: (too competitive, mixed bag of projects, lowest price wins), Upwork (good mix of jobs at various skill levels, top of the market projects are thin though) and Toptal (top of market, top pricing, pickier customers). 

Amongst the 3 options, Toptal seems to suit my needs beautifully. They have a Software Programmers Group and Customers come there expecting to get great work and are willing to pay top dollar for it. That's exactly what I'm looking for. I'm going to be giving Toptal a try over the next few weeks and I'll see how it goes. Wish me luck!

Excellent Book on Advanced Data Structures and Algorithms

This book draft by a competitive programmer has an excellent overview of advanced algorithms and data structures. It's dense and packed with information and covers many tips and techniques not found in any other "standard" algorithms text. 

If you're looking to learn Competitive Programming and solve some of the more advanced challenges, go through it: