robconery.com

Dumb CS Problems And Your Next Job

September 26, 2017 | Career
Going through a coding interview is not fun. The questions you're asked can come off as pointless - there's a reason you're asked these things, however.
***

Congratulations!

I'm happy to let you know that seed round you've been dreaming about - that one that you wanted for that dream startup you've always had - well I'm going to fund you!

Here's a million bucks - now go make that amazing idea happen!

This is a fun daydream - let's run with it for a bit shall we? Just like everyone living in LA has a screenplay they want to write, I think everyone in the software industry has a startup they'd like to launch if only. OK fine HN troll - not all programmers but I think most of them do.

If you don't, here's some money now go dream one up!

Let's Build This Thing

You've got a million of my bucks in the bank. You've had your parties and livestreamed a tour of your new furnished office space on Twitch. You also asked a friend you trust (ha ha ha ha ha ha) to be your cofounder - now let's get down to the business of getting this thing off the ground.

You need a staff. This means you'll have some choices (in no particular order):

  1. network with the people you know, asking friends if they want to work with/for you
  2. hire a recruiter
  3. take out an ad
  4. cherrypick top talent and be prepared to "1 for 2"

I've had to staff up an office twice in my career and each time I loathed the process. The first time I did it I started asking friends whom I trusted if they wanted to learn to program (I would show them what I know) if they promised to work hard and learn. This worked only once and I ended up losing 3 good friends along the way.

We hired a recruiter once and instantly regretted it. Every person they sent us was a cold call - just a joke.

Craigslist and cherrypicking worked the best. Keep in mind this was back in the early 00's when startups were closing down right and left - it was pretty simple to reach out to people who were afraid of losing their jobs.

Then came the fun part: asking them what they know. I didn't know them and I wanted to, so I needed to ask some questions, which is where things started to suck.

Lying F**ing Liars

In 2001 I had to fire 90% of the people I had hired over the previous 4 years. I remember one conversation particularly well (not his real name):

Me: I think you know what this conversation is about so let's get to it. We'll pay you for the next month while you find a different job.

Joe: Yeah I know. It's not like I did anything here anyways. In fact I don't think I've written a line of code in like 6 months (giggle giggle) and I have no problem taking more of your money. This whole place is a joke - I don't know if you thought you were fooling anyone but –

Me: Before you go on, Joe, yes I know you haven't been doing anything. You weren't completely worthless to me, however, as that acquisition that almost happened 4 months ago (which we stupidly passed on) was worth $36 million to us, which means you were worth roughly $1.2 million to me just keeping a seat warm. Enjoy your month off.

You could say I was kind of an asshole in that conversation, but I wasn't lying. We passed on an acquisition of our company that was worth exactly $36 million. We were a consultancy and developers at desks was how we were evaluated (at 8 to 1 I might add).

Why do I bring this up? Because every one of the people we laid off lied right to our faces. In fact in the interviews I've done since, I could tell that most of the developers sitting across from me lied in a sort of du jour way. A fun little game where I needed to spot where they were lying and wink so they could lie some more and I could wink some more...

I asked one interviewee once what the 5 objects were in ASP classic and they looked at me directly and said "when's the last time you wrote a COM object for an ASP site?". Had to admit he had me there.

It's all lies. All of it. Not only that, it's a legal minefield of lies. You need to get to know this person as you'll be spending a large amount of your waking hours with them should they get hired. You need to figure out if they'll be a committed team member or a distraction, a cornerstone or liability - all without asking anything that doesn't directly have to do with their responsibilities.

Good luck.

What Application?

Yes, astute HN troll, not every programmer lies. Just most of them. Some don't even have to try to find work - as Joel Spolsky pointed out many years ago (emphasis mine):

... one thing I have noticed is that the people who I consider to be good software developers barely ever apply for jobs at all. I know lots of great people who took a summer internship on a whim and then got permanent offers. They only ever applied for one or two jobs in their lives. On the other hand there are people out there who appear to be applying to every job on Monster.com. I’m not kidding. They spam their resume to hundreds or thousands of employers.

I know a few good friends who get cherrypicked constantly. They're not disloyal, but at some point the money is so compelling, the job so interesting that not taking it would be a bad move for their career!

If you're a founder and can cherrypick like this, good for you. Most of these "alpha devs" (to use an extremely tired, but accurate term) don't care for instability - which is what your startup will bring.

So now you get to interview the rest of the pack.

Fibonacci... are you like... serious?

This is a standard (fantastical) reaction to a basic interview question:

I: Let’s start with the technical stuff, shall we? Do you know what a linked list is? X: (Tells what it is). I: Great. Can you tell me where linked lists are used? X: Sure. In interview questions.

Get it! Programmers don't like interview questions.

Paul is right. He's one of the most amazing developers I know and there are quite a few large companies out there that would "DNH" him if he didn't know breadth-first search. I think Paul knows BFS however, but his point remains.

I would hire him on the spot if I were you, by the way. For the other developers out there, you might need to ask them a few questions. Really. Annoying. Questions.

I failed an interview once (in spectacular fashion I might add) by answering a question thus:

Them: So, Rob, how would you [do this whacky thing with Docker]? Me: I wouldn't. That's completely ridiculous, won't scale, and will suck money, time and talent from the company's primary business goal. I think I would probably just crater the entire effort.

I didn't get hired, which is probably a good thing. Or was it? I can sit here and let my ego inflate over "telling it like it is" while not having a job, or I could, you know...

Just Answer The Damn Question

When I asked that developer back in 2000 about the 5 objects in ASP classic I didn't have a choice - if he wanted the job it was his; that was the state of things in 1999. I just wanted to pretend that I was at least trying to interview him.

We needed bodies in chairs and coders were being hired with absolutely no experience at all, they just said "I'm a coder!" and boom, they had a job. No, I'm not exaggerating.

I asked my interviewee (who actually turned out to be pretty good) later at our holiday party if he in fact knew what the 5 objects in ASP were, and of course he did:

I just thought it was a stupid question. Who care's about using COM in ASP classic? Oh - unless you're one of those Dino Esposito drones who does everything MSDN magazine suggests...

That was a good one, I must admit.

But now we come down to it: I didn't know him or what he knew. For him to assume that I should just know his awesomeness is ridiculous. More than that: it's so arrogant that it's likely covering something else: they probably don't know as much as they think they do.

That's the problem you face when you pop off in an interview: it sounds like you're covering up your ignorance.

Paul's Point: Github

I gave you that seed round and you're still sitting here! You need to staff up and there's a pile of resumes on your desk. You pick one of them up and it has my name on it, with my blog URL and Github repo. You don't know who I am or the things I've done.

What can you make of my repo? There are 1500 followers, quite a few repositories and 6 total stars - pretty mediocre really. What story does my repo tell about me? I tend to give repos away to others so I've lost most of the 5K stars I used to have (boo hoo) but there is a smattering of code you can read. Some elixir, some JavaScript...

Here's a repo that I picked randomly. It's called meteor-shop and there's some shopping cart code - let's have a look:

if(Meteor.isClient){
  //the cart relies on this global key, which could be a problem!
  //refactor as you see fit!
  userKey = localStorage.getItem("user_key");
  if(!userKey){
    userKey = Meteor.uuid();
    localStorage.setItem("user_key", userKey);
  }
  getCart = function(next){
    Meteor.call("getCart", next);
  };
  addToCart = function (sku, callback) {
    Meteor.call('addToCart',userKey, sku, callback);
  };
  removeFromCart = function (sku, callback) {
    Meteor.call('removeFromCart',userKey, sku, callback);
  };
  updateCart = function (sku, quantity, callback) {
    Meteor.call('updateCart', userKey, sku, quantity, callback);
  };
}

Hmmm, looks like Rob is a Meteor fan... have to ask him about that. Probably likes MongoDB too and, unfortunately we use PostgreSQL. This code is interesting but he's not using ES6 and moreover he's grabbing a cart key from localStorage??? That seems problematic. I don't know...

My point is simply this: I thrash when I think about new ideas and I routinely save my thrashing to Github so others can help unthrash me or just see what I'm thinking. I honestly don't worry about polish as I'm not trying to impress anyone. Maybe a future employer will understand that, maybe not.

Who knows - maybe it's already cost me an interview or two. One thing I do know for damn certain is that I'm no Paul Betts. That man is metal.

So I hate to contradict you Paul but... yeah please don't use my Github repo as a measure of my skills...

Back To The Whiteboard

I've wandered in and out of a number of opinions so let's tie this up, shall we? To do so I'll reiterate what I said in the very beginning: they don't know you and they want to, so let them. They're going to pay you money and hopefully treat you well; I don't think it's too much for them to ask you a few critical thinking questions is it?

This means that, yes, you will need to know basic CS data structures and algorithms that you indeed won't use ever during your job. You'll need to know Big-O, recursion, and what the stack is vs. the heap.

Again, these will likely never ever come up during your employment. Neither will a great many CS things that you've learned over the years.

The point is not what you know, it's what you can figure out. That's what these questions are all about: what skill do you have when it comes to breaking a problem down and building a solution?

No one wants to feel stupid or inadequate so it's natural to counter that with frustration and anger which is precisely what they're also looking for. You're going to be challenged by your peers on the job. You're going to be wrong, you're going to struggle. You're also going to kick butt and do amazing things. In other words: you're going to be part of a team and it's critical to know just how you'll fit in.

Will you meet those challenges with frustration and anger or with professional curiosity? Will you blame others when you fail, or take responsibility for your choices?

How can your future employer know any of this about you without asking some basic, logical questions? Github isn't enough. Your blog just isn't enough. The only thing that's left is the very basic CS "stuff" that transcends language, platform and a practice. Things you might have learned getting a degree or picked up along the way.

For what it's worth: yes, if Paul walks into your startup and wants a job you damnwell better give it to him. You would be quite lucky to have him too... the one's you don't know, however...

Shameless Plug

All of this comes to mind because I just went through the Google interview process myself. Yes, it was very very hard and I had to study my butt off. The good news is that all of that studying was rather fun and I learned buckets about interviewing at big companies. Yes, I swore a lot too. Some of these questions are just so, so, so dumb. They're also challenging and if you can let go of the ego and view them as puzzles they actually become kind of fun. In fact a few patterns begin to emerge and you can develop some strategies...

Which I decided to wrap up and put into a video because I like making videos. It's what I do and you can buy it here:

Mission

I made the thing that I wish existed when I was prepping for the Google interview - something more than just problem after problem; something to keep me focused and stop my frustrations from boiling over.

OK, /shameless_plug.

Always Be Interviewing

A friend of mine said this to me a month or so ago:

I try to interview at least once a year to keep my skills sharp. It's a necessary evil but it's also kind of fun in a self-harm sort of way.

Interesting idea. Big companies cycle candidates through constantly, in fact it's common to interview multiple times at a place like Google before you get in the door.

You just have to contain your frustrations.

Join over 15,000 programmers just like you and me

I have a problem when it comes to trying new things and learning about computer science stuff. I'm self-taught, so it's imperative I keep up with what's going on. I love sharing, so sign up and I'll send along what I've learned right to your inbox.