Work for an employer that builds something you love

This article was cross-posted from Medium.

One of the best decisions I made in 2016 was to find an employer that made something that I loved. It’s provided me with a life-changing sense of work fulfillment and I’d like to encourage you to do the same.

Seeking purpose outside of work

Back in 2016, I found myself disengaged at work and seeking purpose in open source projects and entrepreneurial side projects. It was a downward spiral of frustration and stress that culminated in me quitting my day job without anything lined up.

I had one major rule when thinking about my next employer: the company had to make a product that I used regularly. If I was going to spend the majority of my days working on something — I needed a visceral connection to it. This rule led to a shortlist of companies and I started the interviewing grind: studying hard, doing mock interviews, and lining up real (practice) interviews with other companies.

After a grueling month and a half, I landed a role at Spotify.

Dream job

I f’ing love Spotify. I was a loyal, paying user for years. Discover Weekly (and the discover emails before it) completely changed how I discovered music and the artists I listened to (German, minimal techno — represent!). You ever hear a track in your Discover Weekly playlist and make a “damn, that’s good” face and get this rush of happiness that you found a gem? That has pretty much been every Monday for me for the past several years.

I applied to Spotify in Jan of 2014, after my first startup job out of school, and got denied. Thankfully, in 2016, I was incredibly practiced and knocked it out of the park.

There are Mondays (when my Discover Weekly playlist refreshes) where I stumble onto a gem and I make that face and get that rush of happiness. Then I look up and realize that I’m at Spotify — helping to make it more successful. I get this rush of pride and energy that I’ve never felt before.

Alignment on many levels

There are companies that hire for specific skills and then there are companies that hire skilled generalists and give them immense amounts of freedom in their work. I really wanted to work at a company that valued the latter approach and Spotify definitely delivers.

Spotify’s organizational model is to have a company-wide set of goals for the year and then entrust each goal to a squad (small team). It’s really like “here’s this hard problem that is important for the company to solve, it’s yours. Make all of the decisions, own all of the technology — we trust you. There are experts surrounding you if you need guidance, but otherwise, you have free rein.” It’s autonomy at its best.

On top of autonomy, you’re given the freedom to work across the stack as you’d like. Your squad owns the tech that solves the company’s goal, so it’s up to you to debug that Docker container issue, or figure out the future architecture of your system, or anything in between. It’s an engineer’s playground.

On top of the aforementioned autonomy and mastery, everyone at Spotify loves Spotify and listens to music on it daily. Walk around the office and you’ll see folks with headphones on, heads bobbing, and the desktop app open on one of their monitors. There’s a strong sense of purpose when you and everyone you work with are deeply connected to the company/product.

And I don’t even work on the music player…

I work on the monetization team — building Spotify Ad Studio: a self-serve advertising platform for small and medium-sized businesses to get their message across to Spotify’s free users. It’s filling a really big hole that will materially affect revenue.

I don’t even like advertising. However, I believe deeply in the power of the platform we’re building and its potential to massively impact the company. If I could help keep Spotify successful for years to come, then maybe more folks could discover that feeling of happiness from finding a great, new track.

Symptoms cured

Since joining Spotify, I haven’t at all had the urge to work on side projects. I come home having put in a great day of meaningful work: exercising and developing a wide surface area of skills; solving impactful, technical problems; and reinforcing a deep belief in the work that I’m doing.

Once the wife and kid are asleep, I put on my headphones on, fire up Spotify on my phone, and keep searching for more gems.

Find an employer that builds something you love and it’ll completely change how your work feels and make for a happier life outside of work.

Tips for interviewing at a large tech company

This article was cross-posted from Medium.

I wrote about what I enjoyed from interviewing at Spotify, and now I often get friendly emails from strangers asking for tips on how they should prepare for an upcoming Software Engineer interview. I wanted to share my thoughts more publicly — though they aren’t really specific to Spotify, but hold for any larger tech company.

If you have an upcoming interview with the tech company of your dreams, it’s probably too late to benefit from any tips. You should already be prepared for the championships.

If you still have time to prepare, though, here are a few recommendations.

Kick your negative view of whiteboarding

It doesn’t help you to think you’re above whiteboarding. The issue is also not really with the whiteboard. I know that there’s a stigma around whiteboard interviews in the industry; ignore that shit and keep your eye on the (dream company) prize. Buy into the whole “walk out of interviews that involve whiteboarding,” and you’re going to miss out on joining a great company with teammates that are better than you.

Accept reality, stop complaining, and put your boots on to do some real prep to earn your spot. You’re in competition with the thousands of other candidates who want to be at that company and who will do whatever it takes to get in. It’s kind of like college admissions all over again.

Interview with your dream company last

Don’t make the mistake of having your dream company be the first company that you interview with. You’ll be extremely nervous, under-practiced, and have a lot to lose.

Before you even apply (or if you can delay the interview by a month), line up interviews with other companies that are interesting, but where you wouldn’t be crushed if they rejected you. It’s hard, for me at least, to fake enthusiasm, but do your best to at least get a phone screen for practice. If you can convince them to give you an onsite, awesome! The onsite interview is the championships — with real stress, real people judging you, and real interview-level of difficulty programming problems to solve.

This likely applies in sports, but if you want to win the championship match, you can’t buckle under the stress of the championship match. You have to be practiced and confident enough to know that you can win.

Interview with your dream company last — when you’re no longer nervous, when you have several “gauntlets” (all-day interview loops with big tech companies) under your belt, when you’re excited to see what they’ll throw at you (since it’s another opportunity to improve), and when you understand yourself (your problem-solving approach, limitations, bad habits, and strengths).

You need to take that interviewer on your journey. Be confident, polished, and put on a great show.

Set up mock interviews with friends

This is more like the playoffs than the championships: you don’t have as much on the line, but it’s still stressful and close to the real thing.

Interviewing with your friends gets the jitters of being judged out of your system. You’ll want to impress your friend and not look dumb, you’ll want to continue to improve your skill at solving foreign programming problems, and they’ll have different styles and experience levels to administering a programming interview. The variation in interviewer style here will be good for rounding out how you perform with various audiences.

Interviewing is a performance art — much like playing an instrument on stage.

If you’re like me, you won’t want to “burden” your programmer friends with mock interviewing, but there will be a time when they’ll ask the same of you. They’ll also benefit from additional practice as an interviewer — which is another art form of accompanying/helping someone in their journey through a solution space.

Practice at home

You need to be critical of your skills with an eye for improving your problem solving approach. You need to fill the gaps in your knowledge.

Not comfortable with binary trees (because you’ve rarely used them)? Work problems with binary trees and have that tool in your toolbox to help you in future work. Don’t just accept the fact that you don’t fully understand binary trees or a particular algorithm, patch that hole and get familiar with it. It’s not wasted time, that material doesn’t ever change and you’ll be able to see problems in a different light with that additional perspective at your fingertips.

The more you practice at home (with careful self-reflection of what you did well and where you stumbled), the more likely you are to no longer be afraid of the problems you’re given during the interview.

As an aside, it really sucks that you need a certain level of privilege to have spare time to do this prep work. I hope we find a better path forward.

Focus on the language, not the frameworks

You need to be able to think in terms of a programming language. It’s fine to use helper methods if you don’t remember part of the standard library, but you shouldn’t be thinking about how to express your thoughts in the language on interview day. You shouldn’t be thinking about the programming language, you shouldn’t be thinking about your body language, and you shouldn’t be thinking about how a data structure works. You should be at a level of practice where you only need to think about the given problem, its constraints, and coming up with a few solutions.

I also see a lot of programmers spend years of their career only working in higher layers of abstraction (frameworks, libraries, abstractions specific to your project) and never spend time exploring and understanding the surface area of their most familiar language. If you think that you can improve your skill by learning the hottest new framework, you’ll probably fail the interview.

Postpone your interview, study your language, solve more problems in that language, and you’ll have increased your chances of success.

Focus on your performance, not your portfolio

Your portfolio only gets you an interview, it doesn’t get you the gig. A lot of people feel that whiteboarding is beneath them because they’ve built so many amazing things.

The issue, from an interviewer’s perspective, is that only the end result is visible, not the process you went through to craft the result. Did you code and pray the entire time (rewriting parts of the project many times over)? Did you collaborate with someone who did most of the work? Did you copy/paste code a lot of code from the internet? Did you base your work on another project that did the heavy lifting? What are the trade-offs that you had to make and were you aware of them?

You can glean some of this from the commit log (assuming that’s coherent), but an interviewer doesn’t have all day to prep for their session with you.

You need to spend time improving your performance on programming problems, or you’ll fail the interview.

Know how to articulate why the company is your dream company

If you come off as just looking for a job, you’ll fail the interview. You need to be passionate about some aspect of the company or one of its products. Do your homework on the company and be able to let the interviewer feel your passion for wanting to work there.

I think cover letters are a great exercise in formulating an answer to this.

Best of luck to you

I hope the above tips have been helpful to you. You most likely only get one shot at that company (or likely one shot a year) — make it count and show them your skill.

If you have any questions, feel free to reach out to me @mrjoelkemp.

Best of luck in your job search!

If you want to level up as an engineer, read the code. All of it.

This article was cross-posted from Medium.

Over my entire career thus far, I’ve noticed a single action completely transform a developer’s effectiveness as an engineer and technical leader: read all of your system’s code.

It’s a “simple” action (though it takes time, energy, focus, and skill at extracting meaning from code), but (surprisingly) not many people on your team will do it. Developers who haven’t read the system’s code will always rely on those that have.

Understanding how the entire system works, from an architectural standpoint, is a step in the right direction — but one step above what I’m suggesting. The details are beneath the architecture. The nitty-gritty order of logical operations will make the semantics of the components/sub-systems clearer, avoids the back and forth of “but I thought it did this/that,” and provides a level of insight that makes you more effective when discussing how sub-systems interact or need to interact for a new feature.

When you do decide to read all of your system’s code, you’ll likely notice a few things happen afterward when there’s a new feature to build:

  • You’ll be better equipped to identify which parts of the system need to change to accommodate the new feature. In turn, you’ll have a more informed hunch of the complexity of the new request. You’ll even be better equipped to provide meaningful insights on how those parts should change.
  • Since you understand the entire system, you’re also primed to help form a more thorough and comprehensive set of edge cases.
  • Your product manager(s) will rely more heavily on your informed hunch about the complexity of the feature to determine if there’s a less complex, but impactful feature that could make more sense at this time (given time and resource constraints). Ideally, the product manager would reach out to the sub-systems’ owners for that hunch; however, that increase in communication complexity only works for small teams (around a handful of engineers). There are real consequences to watch our for in this communication optimization though: make sure teammates don’t feel neglected, make sure you’re not overwhelmed with the question load, and avoid being placed on a pedestal in your team’s eyes.
  • Your teammates that own the affected subsystems will seek out and value your opinion. If they’re asking you for solutions, that’s a sign that you’re either micromanaging (a real danger when you know things at that level of detail) or that you’re in the “telling” phase of situational leadership (typically for inexperienced, new hires; less experienced, “junior” teammates; or teammates with a lack of domain knowledge or self-confidence).

Outside of the context of a new feature, you’ll possibly notice a few other things happen:

  • You’ll transition into a tech lead, which is a whole new can of worms.
  • You’ll get pinged to review more and more pull requests (PRs). If you’re giving effective code reviews, it’ll require lots of time.
  • You’ll get invited to more strategy planning meetings.
  • You’ll get invited to more architecture review sessions.
  • You might have a vision for how the entire system needs to evolve to meet long-term business needs.
  • External stakeholders will ask you questions about the system.
  • Your product manager will ask you more and more questions about feature complexity as the product evolves.
  • You’ll struggle to find time to code.
  • Teammates will just walk over to you (even if you have headphones on…) to get your thoughts on their idea.
  • Your paycheck will increase and folks will try to promote you.
  • People may start to call you “senior.”
  • Teammates may start to view you as their leader.
  • Your teammates will be impressed with your ability to think of so many edge cases — though they’re one action away (read the code) from being able to do the same.
  • Every new feature will feel like a game of chess (so many moving parts, so many disaster scenarios to plan for, so many possible paths forward).
  • You won’t be able to keep up with the evolution of the system. You’ll realize that the knowledge you worked so hard for is only a snapshot of the system in time. Your information is now outdated with every shipped PR and you’ll have to fight every day to keep the knowledge current.

Ok, so maybe don’t read the code… Life is easier that way 🙂

I really enjoyed interviewing at Spotify

This article was cross-posted from Medium.

After a month of intense preparation and interviewing, Spotify was a breath of fresh air. I’d like to talk about the process of interviewing for an engineering role and why it was one of the better experiences.

Spotify uses a traditional tech company style of interviewing for full-time engineering roles. Here’s the general process:

  1. Phone call with a recruiter
  2. Technical phone screen with an engineer
  3. Onsite interview with 4 rounds (system design, code practical, algorithm/data-structure questions, and a non-technical discussion)
  4. Offer or rejection

The interviews try play to your strengths in that the questions are planted within the domain that you’re most familiar with (frontend, backend, data, etc).

In my experience, other companies vary this process with 2 technical phone screens, an onsite interview with 5 to 6 rounds, and possibly a take home project or coding test (either at the beginning or end of this whole process).

I’ve had some oddball companies bring me in for 2 onsites of 5 to 6 rounds each. Yikes.

Spotify excelled in hitting all of the important areas in assessing an engineer’s skill-set with focused questions and little to no delay between interviews. They knew what they wanted to extract and didn’t waste your time.

Anyone who has gone through interviewing with multiple companies can appreciate one that knows what they’re doing.

Technical interviews: it’s not actually about the whiteboard

This article is cross-posted from Medium and a response to the following article on tech hiring being broken.

There are some interesting points in the above article on why folks fear and/or should avoid the whiteboard. I think the whiteboard hate is a crutch.

It’s like paper, but on a wall

Many preparatory materials will tell you to practice on a whiteboard before doing a technical interview. Of course, mindless practice will only get you initially comfortable with holding a marker, writing on a wall, and caring about your penmanship.

One important aspect of whiteboarding is to spend a few minutes thinking about space utilization. What is your process for solving technical problems and how can you use the space on the board to facilitate your process?

Do you work best by writing pseudo-code? If so, consider using the side of the board for notes (test cases, important bits of knowledge from the problem, logical conditions) and scribbles (algorithm structure or pictures of data structures). Or do you prefer writing code directly? If so, use the central/primary space on the board and consider leaving room between lines to fix bugs.

That’s it. That’s all you have to think about. Heck, you don’t even need to use a whiteboard to think about this. Practice space utilization on paper and that’ll transfer fine.

Yes, you might smear marker and get your hands dirty. Do you avoid writing on paper for the same reasons?

Focus on displaying your solution to the problem, not the medium.

Be careful of using the central part of the whiteboard for test cases or pictures. You’ll have to erase that stuff to code up the solution. Erasing the board wastes time. You may also erase an important test case and have to rewrite it — wasting even more time.

But I need access to Google

No, you don’t. If you don’t remember some part of the API (ex: forgetting if JavaScript has a method to trim whitespace from both sides of a string), vocalize that you don’t remember and use a helper method. No interviewer should ever knock you for that.

If an interviewer asks you to implement a classic sorting algorithm (like Mergesort), then that’s poorly testing memorization not application. In my experience, interviewers will expect you to know of the algorithm and its time/space properties, but are fine with you using sort as one operation in a larger algorithm.

Google is a crutch. Method names are details not worth worrying about. Worry about your algorithm. Worry about whether or not you actually solved the problem. That’s what matters.

But I prefer to code in an editor

One great aspect to whiteboarding (or solving problems on paper) is that it promotes delaying the actual writing of code for as long as possible.

If you use an editor directly, where do you scribble notes or designs? How do you make sure that you’re not jumping into coding before having analyzed the tradeoffs of multiple solutions? Coding too quickly is one of the biggest mistakes in these types of interviews. Avoiding lateral thinking puts on blinders that may commit you to the brute force solution without any awareness of a more optimal (depending on what you need to optimize for) approach.

If you must use an editor (if on a phone screen, for example), then one technique is to outline the solution using helper methods. Run through the outlined algorithm to make sure that it’s operationally sound. Then, if you and your interviewer agree, start implementing the helper methods. With this approach, you’ve avoided being too committed to an idea and avoided spending too much time down a potentially wrong path.

The code that you write for a solution does not need to run perfectly when interpreted or compiled. It should convey your thought process and correctly model the chosen solution to the problem. This is not an excuse for sloppy coding. Do a light pass code review after you’ve written your code to make sure it’s syntactically correct and typo-free. Banking on an interpreter/compiler when solving a problem hints that you maybe “code and pray” and don’t proofread your code or outline it ahead of time.

Remember the goal

You need to demonstrate that you can come up with a solution to a problem based on time/space constraints. The medium doesn’t matter. Don’t rule out whiteboarding because of the whiteboard; it’s a red herring that will deprive you of opportunities to join great teams.

Package Stats and Its Data Pipeline

For the last year (on and off), I’ve been working on PackageStats.io: an analytics service for NPM package authors. As an author of 60+ NPM packages, I found it extremely frustrating to gather a holistic understanding of the reach/impact of my packages – resorting to clicking through the 60+ package pages on NPM’s site. I built Package Stats to solve that problem – giving authors rich insights into their package ecosystems.

Continue reading

On Hiring Procrastinators

The work ethic that you have is likely a carryover from how you were in school.

Some of us might be labeled as procrastinators – not out of laziness, but out of a misalignment of goals.

In school, high leverage tasks (as teachers and the department viewed them) were tests, homework, and classwork. They assumed that you were in school with the goal of getting a degree. However, going to school is the norm. Not everyone goes because you necessarily want to. Some go because you need to (to get a job). As such, your goals in school won’t necessarily align with that of getting the degree.

In the workforce, it’s hard to interview for goal alignment (i.e. that the company’s goals align with the candidate’s goals). Hiring in tech is a bit desperate so we make offers to talented folks who have barely heard of our products. One solution could be to make sure that the candidate is passionate about your mission and product; unfortunately, that leaves you with an even smaller pool of candidates. If a candidate only want to join your company to “build cool shit,” you’ll need a strategy for alignment and readjustment.

Expecting the candidate to be aware of their misalignment is putting the company at risk. The candidate wants to achieve their goals – not yours.