What computer science knowledge/concepts do software engineers use on a daily basis?

For as long as I can remember, there’s been a disconnect between kinds of stuff people ask in software engineering interviews and the day-to-day work that software engineers do. As a recruiter and a former engineer, this disconnect is particularly salient because when I evaluate candidates I have to ask myself two separate questions:

  • Will this person be able to pass a few rounds of coding interviews?
  • Is this person actually good?

It’s a bit funny that whether the person is good is somewhat immaterial if he isn’t going to make it past the CS fundamentals gauntlet.  That said, I think that the standard interview process isn’t the worst predictor of success on the job — people who are good at solving toy problems, have solid knowledge of various data structures, and for whom evaluating code efficiency is second nature also tend to be good at being engineers.  This is perhaps a classic correlation vs. causation problem — people who are good at being professional coders also tend to be good at being interviewed.  However, I’m not sure that they are good coders entirely because they are good interviewees.  In other words, I would guess that this approach has a pretty high false negative rate.  Unfortunately, I don’t have a good solution to this problem, and surely  lots of false negatives is better for a company than the same number of false positives (especially if the company has a good brand among engineers that affords it a revolving door of applicants).

Recently, someone on Quora asked about what CS concepts are actually used on the job (as opposed to what candidates are expected to bring to the table).  Bulat Bochkariov did an amazing job at attacking both this question and discussing coding interviews.  With his permission, I’ve reproduced his answer here.

Answer by Bulat Bochkariov:

The set of questions people ask is frustratingly disjoint from what’s important day-to-day. There are reasons, but I’ll try not to get sidetracked here.
Here’s a tiny list of things an engineer should be prepared for.

  • It’s 2pm. The release gets cut at noon tomorrow. (Or we could delay, but that would suck kind of a lot.) This piece of code is running way too slow for us to ship it with our names on it. How would you decide what to do? And then how would you do it? Remember that there’s still that other feature we were working on.
  • We need to do X. You know our stack and our toolchain. Research the options, then determine the next step and take it.
  • MySQL is seriously melting with this growth. We can’t keep doing all these joins.
  • There’s a critical bug in production.
  • We’re losing velocity. Our crufty code is keeping us from making changes quickly. What’s the root of the problem? What would really good abstractions look like? What are we trying to do? And how do we keep doing it while cleaning up this mess?
  • EventMachine is leaking more than normal.
  • Someone took out Git. There’s a crater.
  • Is it ok not to encrypt this? Like, what’s the worst that could happen. Right?
  • I think we’ve been hacked.
  • We’ve got an interview today. They even mentioned some security experience. What do we ask? How? What will it tell us?

For the most part, no one cares if you can make a red-black tree. It’s not something you’ll be doing. It’s just a proxy for a few things that do matter: your ability to solve new problems and an understanding of the content in a core CS curriculum—or whether you can write code that compiles and runs. But those are just the basics. They’re necessary, but they’re not sufficient.

What’s more important is your understanding: whether you can see the forest for the trees and find your way to where you’re going. You don’t think in JavaScript or Python but in problems and solutions, on multiple dimensions at once. You know the details are important but they aren’t the point—except when they are, and you can tell the difference.

You don’t do stuff that’s clearly bad; consider that a given. You don’t leave O(n^2) code turds on the floor or weird recursion time bombs that will blow the stack if n gets bigger than a thousand. But in a Maslow pyramid for programming, that stuff is on the bottom steps. It’s important to keep reaching for the top.

The most important question you can ask is “why.” What problem does this project solve, and what problems is it made of? Why should I consider Factor A over Consequence B? Why the hell is there a ServletBeanAdapter here? And keep in mind that sometimes it’s because an engineer took time to fully understand the problem, examined the upside, noted the risk to his or her own timetable, considered the security concerns, thought about maintainability, sketched out some more powerful solutions, decided not to waste the effort here, and made a quick decision that looked right when faced with finite time and lots of ambiguity. That’s what software engineering is about. You develop judgment and you learn from your mistakes.

And that’s what no one asks about.

Here’s where I should say a couple things. First: I’m a “new grad,” which means I’ve interviewed enough that I can’t count them on my fingers and toes, but I wouldn’t need to grow a lot of extra hands. That leaves me biased in a number of ways. Second: The context is important. If you work on machine learning, you’ll definitely need some statistics. For distributed systems, you’ll need data structures and concurrency. I don’t mean to say that core CS is not important. I’m talking here in generalities, so please don’t take them for specifics.

In my experience, what people ask is more like this.

  • FizzBuzz variants; easy looping questions. (Because it would be rude to check your pulse.)
  • Counting nodes or levels in some sort of tree. The goal is usually to see if you can think recursively or how you’ll try to hack the problem if you don’t. I love to harp on these, but honestly they make pretty good screens.
  • Basic questions from an algorithms class. Can you solve a searching problem if you aren’t told how? Can you mentally connect the properties of BFS with level-order printing in a binary tree?
  • Data structure questions with a fairly clear right answer. Given some data and a time or space constraint, can you process it a certain way? Can you make a stack with constant-time maxValue()? What structures would you hook together for an LRU cache? A lot of these are just fill-in-the-blank if you know the standard structures’ time and space costs, but that’s already showing that you know something worth knowing.
  • Sometimes they’re just random made-up problems that you probably won’t guess in advance. Maybe some weird string questions or a twist on a dynamic programming problem. Some companies might ask more mathy stuff like rolling averages or random number generation.

And of course there’s plenty more. There’s a bunch of different lists online that people study with. I just don’t think what’s in them is the point. The most important thing I have to share, strictly true or not, is that the skills you’ll need for interviews are not the skills you’ll need at work.

If you’re interviewing, brush up on your textbook knowledge. Practice your dynamic programming. Go code up a union-find in C. Worry less about what skills you really need and more about the ones you need to demonstrate. They’re different. The standard problems people test you on are proxies for the things they really want. They just have a funny and imperfect way of finding out.

View Answer on Quora

How long should my resume be?

Disclaimer: I do eng hiring for startups so my advice will be based on startup experience. Big, established organizations may do things differently.

I would try to keep your resume as concise as possible without sacrificing readability. Sometimes, this means you will go over one page, especially if you’ve been working for a few years. It’s not the end of the world. I would rather see a 2 page resume that looks like it was written by a functional, thinking human being than a one page resume that lacks any kind of content or soul. Try not to go over 2 pages, though, as your reader’s attention span is short. In other words, you should be aware that the people reading your resume are not going to read everything. Make it easy for someone on autopilot to internalize the most impressive things you’ve done, and always err on the side of conciseness. This means that you probably should:

  • Refrain from listing every project you’ve worked on. Pick the ones where you took some initiative, built something from scratch, or had major impact on the final product. At the end of the day, I’d rather see one impressive project than 5 projects where you upgraded some framework or followed detailed instructions to fix a subproblem of a subproblem of a subproblem.
  • Explain what you did in plain English. I can’t harp on this point enough. People outside of your company aren’t going to know what any number of internal acronyms or tools are. Think big picture. Ask yourself, “Why does what I worked on matter? How did I contribute to the overall mission of the organization? What is the context for what I did?” and so on. This doesn’t mean you shouldn’t go into technical details (you should), but it does mean that you shouldn’t use obscure terminology or the languages/tools/frameworks you used as a crutch.
  • Don’t keep repeating what tools/languages/frameworks you used. This wastes precious space, and in most cases, what you did trumps what you used to do it (unless you did something very specific like migrate from one language to another or fix a bug in some framework). Rather than going on about how you used Hibernate to do ORM or whatever (this is a particularly poor thing to go on about because you’re not adding any value — you are using a tool for its intended purpose!), just put all the things you used/know in one concise Skills section. For bonus points, delineate which things you’re very proficient in, which ones you know pretty well, and which ones you’ve used but would need a refresher on before diving in.

To illustrate these points, here are some project descriptions (taken from real resumes). My comments on the bad ones are italicized. I think the good ones speak for themselves.

Bad ones:

Designed software application including: data modeling, software architecture design, software- hardware integration, user interface design, and database management

I have no idea what the candidate did or how he contributed. This is super vague and uninspired.

Developed [product name], using C# in .NET framework, for marketing and allowing end-users to experience [another product name]

Again, I can’t tell what the candidate did. He’s hiding behind products/technologies to potentially mask the fact that he is either not too excited about his work or that he didn’t contribute much.

Good ones:

Created and launched a service that collects product opinions and recommendations from Twitter. The service finds related tweets, removes spam, analyzes sentiment and creates a structured database of everything that was said about particular products [link to demo]. The service is exposed as a consumer website and as widgets that can be embedded in online retail websites.

Evaluated and identified [OS name] network stack performance bottleneck in latency, system jitter, per-packet processing overhead, and scalability of different network IO models through various system measurement and profiling techniques

Note: This post was adapted from an answer I wrote on Quora.

What are the characteristics of great engineering recruiters?

A great technical recruiter should be able to do 2 things: (1) present engineers with companies that fit their criteria and (2) present companies with engineers that meet their standards and are likely to accept an offer, should one be made.

Before I come up with a list of bullet points (though you can skip to the TL;DR section below for bullets), I'd like to pose the question of why an engineer or a company would want to work with a 3rd party recruiter. I'll then go on to explain what value a good recruiter would add.

From a candidate's perspective

As an engineer, what's the point of even working with a recruiter when you can just apply to companies directly? In short, a recruiter should be able to help you flesh out what you want in your next job, come up with a short list of positions, deal with interview logistics/minutiae so you don't have to, advocate for you throughout the process, and help you understand your offer.

People want all sorts of things from their jobs, though sometimes it takes some time to really distill what someone's requirements are. Sometimes it's more money. Sometimes it's more impact, a specific type of challenge/problem to solve, or a specific kind of team structure. Sometimes someone wants to change over from an enterprise product to a user-facing one. Sometimes it's a matter of entering a new industry. It's the recruiter's job to know which questions to ask and figure out what's going to be most important to a candidate. In figuring this stuff out, I'm of the opinion that having industry engineering experience is going to be invaluable (how else would you really understand what it means when someone tells you they are tired of monolithic code or want to work somewhere that is more receptive to using 3rd party tools than their current gig?).

Once that's figured out, a good recruiter should help you go beyond your personal network and a sea of badly written job ads to find the job that will make you the most happy. To do this, a recruiter should have a pretty good mental model of what companies are out there, what they do, how much traction they have, what projects are currently being worked on, what the culture is like, and what compensation looks like, and then use that info to handpick a short list of jobs that would be perfect for you.

Sometimes this process takes several iterations, and it's the recruiter's job to elicit useful feedback and go back to the drawing board as many times as necessary to get things right. If a candidate says that he wants one thing, and when presented with that specific thing, he doesn't want it, that doesn't mean the candidate is lying or not being helpful. It means that the recruiter didn't ask the right questions.

Once a list of companies/jobs is in place, the recruiter should continue to be useful by abstracting away some of the interview scheduling back and forth. In essence, the recruiter should tell you to put on pants and to show up to interviews at some specific place and time. After each interview, the recruiter should be advocating for you to figure out what next steps are and make sure that you hear back and hopefully get any relevant feedback in a timely fashion.

Once you get to offer stage, your recruiter should be on hand to provide you with any non-confidential data about salary and industry trends and help you navigate the equity component of your offer.

From a company's perspective

As a company, what's the point of working with an external recruiter rather than doing all your outbound sourcing yourself? Chances are, if you're a startup, you're not going to have a huge recruiting department. You may not even have a dedicated in-house recruiter (though you probably should). Regardless, there's more to recruiting than just sourcing candidates. You have to deal with the candidate pipeline (screening people, making sure subsequent interviews happen in a timely fashion, and make sure that candidates are moved through the process, made offers to, and rejected). You have to deal with placing job ads, campus recruiting, figuring out ways to promote the company's engineering brand (meetups, tech talks, hackathons, wrangling people to write blog posts), incentivizing internal referrals… the list goes on. Having a bit of help getting candidates in the door is not the worst thing in the world.

Let's say that you now have some agencies working for you to find engineers. There are 2 pain points I've encountered as an in-house recruiter working with 3rd party agencies: influx of either low-quality candidates or of high-quality candidates that have a low chance of accepting the offer.

Consistently sending high-quality candidates to companies isn't easy. There is definitely some correlation between a candidate's pedigree and technical ability, but in my experience, it's not as strong as one might like. Therefore, getting an idea of a candidate's ability before pitching him to a company is invaluable. To be able to screen a candidate thoroughly, a technical background is going to be necessary, no two ways about it. Even with the advent of a single screen, it's pretty hard to tell who's good. It isn't too hard to tell who's bad, though, and ideally a recruiter would be able to filter out the poor and mediocre candidates, leaving the fine-grained filtering of the decent from the great to the companies themselves. Even if a recruiter isn't technical, he can still filter out some amount of poor candidates by asking them to describe what they worked on in a way that a non-technical person can understand. Doing this well is non-trivial and, in my opinion, tends to correspond to future workplace success more strongly than pedigree. Regardless of how the filtering is done, a great recruiter is going to find a viable way to do it.

Let's say that a recruiter is working with a candidate who is clearly strong technically. At this point, the recruiter has to decide where to disseminate the candidate's info. A great recruiter will take into consideration what the candidate wants (see portion above about the candidate's perspective) and will only pitch him to companies who match what he's interested in. Doing this is non-trivial because, in addition to understanding what the candidate wants, the recruiter must also understand the companies' business models, cultures, be familiar with their tech stack, and so forth. Unfortunately, because effectively matching candidates to companies really is non-trivial and requires deep, specialized knowledge, many agencies don't do this and turn the recruiting process into a giant feeding frenzy. The same candidate's info can get sent out to any number of companies, and for each company, the odds of closing said candidate drop off. This approach is particularly poor from the company's perspective because interviewing candidates is expensive, both in terms of engineering time and logistical expenses (such as flying people in).

As with candidates, it often takes several iterations to nail down exactly what the company is looking for. Sometimes, there's a disconnect between what a company claims to look for in a candidate and what candidates are actually successful. To mitigate this, it's always helpful to get an idea of the current eng team demographics. In general, it's also good to keep a frank, open stream of communication in both directions (company providing feedback to the recruiter and the recruiter potentially sharing insights about inconsistencies between what the company advertises to want and what it wants as well as any industry salary/equity trends that might be helpful).

TL;DR

Great tech recruiters:

  • grok engineers' and companies' criteria
  • are familiar with salary and equity ranges at startups in different stages and for different positions and understand/are able to offer meaningful advice about these things to both companies and candidates
  • are able optimize on candidates' and companies' constraints within a preexisting, broad network of companies and engineers
  • are able to filter candidates' technical ability to some extent (separating bad from decent is much easier than separating decent from great)
  • are able to elicit useful feedback from both candidates and companies
  • care about people/take pride in doing their job well so that when it's tempting to just play a numbers game, they don't

Note: This post was adapted from an answer I wrote on Quora.

What is a better recruiting strategy for small/med teams: casting a wide net or targeted?

This question has a tacit assumption, namely that these two methods, while different, are somewhat interchangeable. I would argue that they are not. The situations in which each method will be most successful are different, as are the resources you would need to execute on each of these methods. In addition to finding the best method for you, please keep in mind that there's no magic bullet when it comes to hiring great engineers. In addition to explicit recruiting efforts, you should be perpetually working to make sure that (1) your company is the kind of place where top people want to be and (2) the world knows about why you're awesome.

When is casting a wide net effective?

Casting a wide net can be very effective if your company already has a strong engineering brand. If you make the conscious decision to play the numbers game, chances are, your messages to prospective candidates aren't going to be very personal. Engineers with good pedigrees receive at least 3-4 LinkedIn messages/emails per day, and they're going to quickly skim your messages, if they read them at all. They're definitely not going to go and research your company, and these days, everyone is a disruptive, well-funded startup with great culture and free food. Therefore, if nothing in the message speaks to them directly, and if the name of the company isn't something they recognize, the message will probably get lost in the noise. Facebook, Google, and a short list of high-profile startups can afford to employ this technique because people are familiar with the prestige behind these brands. In other words, if you're Facebook, you can scream into the void, and the void will answer back. The rest of us aren't so lucky.

The same rule goes for working with external agencies, though I'd argue that there are a few disadvantages to this approach. First, someone from the outside is going to be worse at selling your offering than someone from inside the company. Some agencies have strong brands in their own right and have a great stable of companies they work with, so their response rates may be pretty high. However, if a solid candidate bites, that candidate will most likely be farmed out to a number of companies. Therefore, with agencies, you may get more good candidates in at the top of the pipeline than you would on your own, but you may not end up closing them.

Another situation in which the wide net model can be successful is if you just want to hire a few people but aren't looking to really scale your team. With enough messages, you will probably get a few decent people in the door. However, you're not getting anything sustainable for your efforts. After a year of spamming, you may have a few hires, but what else will have changed? You won't have enough positive data to really tweak what you're doing, and you will not have built something that makes future hiring easier. You are forever beholden to the number of messages you send out.

What resources are needed to cast a wide net?

Casting a wide net takes resources. For one, you're going to want a dedicated sourcer. You can hire an in-house recruiter to do this (either f/t or contract). On top of that, you're going to be paying agencies ~20k/head if you're going to be working with them on contingency (another option is to pay an hourly rate that will get the agency to do your sourcing for you). The good news is that finding recruiters and agencies isn't going to be too tough, if all you want them to do is message as many people as possible with some boilerplate copy.

When is a targeted approach effective?

This approach is effective when you have the specialized manpower to do it well (will discuss more about what you need below). Sending personalized messages to people is really hard. You need someone who can research the person, read blog posts, and grok their personal projects. Why is this important? Because to meaningfully engage with prospective candidates, you're going to have to figure what they value and what drives them, use this info to actually identify what it is about them that your offering speaks to so profoundly, and articulate that. Much of the time, it's not as simple as matching the technologies that your product relies on to the technologies that a given person is passionate about (e.g. webGL). People are driven by all manners of disparate things.

You're also going to want your manpower to know who not to go after — just because someone is great doesn't mean they will be happy working for you. Interviewing people take a lot of engineering time, so you're going to want to do your best to only engage with people who are going to be likely to accept. For instance, if your company is pretty conservative and isn't using a bunch of new shiny things, someone who gets off on trying every new framework out there is probably not going to be happy.

If you do end up pursuing this approach, one indirect benefit is that it will help build your brand. People really appreciate it when a company takes the time to send them something personal and relevant, and even if you don't end up hiring everyone you reach out to, they may remember you and appreciate that the people working for you are good at what they do.

What resources are needed for a targeted approach?

The best people who can understand what engineers are working on, what they'd like to be working on, and what drives them are other engineers. Some companies will explicitly dedicate a certain amount of engineering time to recruiting tasks (e.g. looking over GitHub and LinkedIn, finding people to contact and contacting them). This approach is costly, of course, and not everyone is going to want to participate. Another option might be to hire someone technical to help with recruiting.

What is the best thing to do?

As I mentioned above, if you already have a very strong brand among engineers, or if you want to do a few one-off hires, casting a wide net may make the most sense for you. However, if you don't yet have a strong brand but do want to scale your team, I would suggest the following.

Take some of the money and time you would have spent on spamming and use it to build your brand. First, ask yourself if your company is the kind of place where really great people want to work. If it is, that is awesome. If it's not, then fix it. Even once awesomeness is in place, if no one knows about why you're awesome, no matter how much time or money you sink into recruiting, you will not be able to hire top people at scale.

In general, it's very tempting to look at low-effort, seemingly accepted, high-cost solutions and hope that they will make everything better (e.g. finding an in-house recruiter and hoping that he/she will fix all the things, throwing money at agencies, buying ad space, buying a huge booth at a career fair). However, that money is best spent on finding meaningful ways to tell the world that:

(1) you have a great product,
(2) your company is full of really smart, driven, passionate people that anyone would be proud to work with and learn from, and
(3) that you're solving hard and interesting problems.

There are a number of ways to accomplish this, including

  • giving tech talks (both at schools and at meetups)
  • open sourcing some of your stuff
  • having an engaging engineering blog
  • hosting hackathons and meetups
  • having really great job ad copy
  • having a creative, fun, and difficult coding challenge that will make people want to share that they've completed it
  • having members from your team share what they're working on on their own blogs
  • guest-posting somewhere like TechCrunch, if possible
  • developing a highly selective internship program

Some of this stuff is hard to do, but without it, hiring is going to be an uphill battle.

Once a strong eng brand is in place, you can employ a mix of the two techniques you mentioned, depending on what resources you have available to you. In addition to GitHub and LinkedIn (as well as Entelo, which aggregates info found on these sites and others), I would recommend StackOverflow (more for their candidate database than for their job board), Hacker News' whoishiring, and potentially working with Udacity and Coursera.

Note: This post is adapted from an answer I wrote on Quora.

In what situations should your resume include an objective at the top?

In my experience, most objectives are complete fluff with no content. I don’t care if you want a challenging position where your sharp analytical skills and programming ability can contribute to the vision of the organization. I just threw up in my mouth a little bit while I wrote that.

That said, I can think of a few situations where having an objective might make  sense (listed below). All of these situations are specific instances of a more general case, i.e. it makes sense to have an objective when it is not immediately clear what you’re looking for just from looking at your resume. However, proceed with caution, and don’t start writing fluffy crap.

  • You have pretty broad experience within some field but are looking to really hone in on something specific at your next job.
  • It’s not immediately clear from your resume whether you want an internship or a full-time job.
  • You have worked in a number of different disciplines, or you’re a new-ish grad and have a degree in something that doesn’t directly apply to what you want to do now.
  • Your startup folded, and you’re looking to work for someone else again.
  • You were doing management for a while but want to get back into being an individual contributor.

Note: This post is taken from an answer I wrote on Quora.