Author: Carson Moore

I don’t want to live forever.

I bring this up because yesterday my boss was talking about how we are at most 30 years away from curing death through some sort of regenerative DNA therapy or something; he was in particular certain that cancer has no more than a few years left to live. From there, it’s a straight shot to curing pretty much everything else — heart disease, obesity, diabetes, you name it — and presumably aging, too.

I’m not here to disagree with him¹ — he’s a smart guy², and he has a lot of friends in the biotech industry who are apparently working on exactly this.  I’m just here to say that that’s terrifying.

Let’s just assume we manage to cure cancer — completely cure it — in the next 30 years, and while we’re at it, we wipe out heart disease and diabetes, too.  First off — awesome, way to go world!  That is a really awesome accomplishment, and I unironically applaud you for it, despite what I’m about to say. Second off, what comes next?

I attribute this argument to my brother, who once pointed out that in a world where the average adult human would not expect to live into their 60s³, you could not imagine the existential horror of unavoidable prostate cancer⁴ or slowly, confusingly wasting away as your brain eats itself from Alzheimers.  In a world where, if you’re lucky, you’re going to die from being old and slow and bled out by a saber-toothed cat or put out to sea on an ice floe by your immediate family, it’s hard to imagine a world where those dangers no longer exist, and — again if you’re lucky — you die painfully of gout and liver failure from the copious quantities of alcohol you’ve consumed⁵.  Now we’ve purified water⁶, and people die from 70 years of eating too much and cancer and brain autocannibalism.  Imagine what terror lies beyond treating obesity and cancer and Alzheimers?  If living to your 80s causes your organs to literally give up, what does living into your 120s cause?

But let’s just say for the sake of argument that whatever comes next isn’t terrifying or painful.  Maybe whatever we use to cure our modern ills also — and cheaply⁷ — cures all future ills as well.  Now imagine you look like this for the rest of your incredibly long life.

“Aha!” you say as you read this, “Your boss said some sort of DNA therapy!  Perhaps that cures aging as well!”  Then you notice that I mentioned that earlier and that this post is entitled “Forever Young,” as though I, too, had thought of this exact line of argument.  It turns out you’re pretty dumb, and you probably shouldn’t have said anything at all.

Let’s say we do also cure aging.  We don’t lose our teeth or our eyesight, and our skin stays wrinkle-free and healthy looking, and our hair stays dark, and we suffer nary even a split end.  But is any sort of DNA therapy going to actually reverse aging?  Presumably it would use our DNA at time of treatment, and since DNA degradation may contribute to aging, it’s not unreasonable to think that we may only be able to stop aging rather than reverse it.  We’re talking about something that’s 30 years away, so if you’re in, let’s say, your late 20s⁸, you’ll be in your late 50’s by the time this treatment comes around.  And you’ll be stuck there.  Forever.

On the face of it, that’s not so bad — I’d much rather be stuck in my late 50s than, say, pretty much anything later than that.  My parents are in their early 60s and they’re not doing so bad.  But it’s not like everyone will be stuck in their late 50s — everyone born after you will stop aging whenever they feel most beautiful, which will damn sure be younger than their 50s.  And there’s just more and more of them born every day, and they all stop aging at 25.  Now you’re part of some sort of weird protected class because you were born in the Years Before Aging Stopped and are therefore ugly and gross, and an increasingly large percentage of the world is young and hot and sexy and not you.

If they do cure aging in the next 30 years, millennials are in one of the unluckiest generations to have been born in the history of time — and that’s a history that includes thousands of generations where making it to adulthood was an accomplishment.

But, for the sake of argument, let’s say they really cure aging — maybe you don’t get to freeze time in your 20s, but generally speaking your body doesn’t wear out, and any damage already done can be repaired.  Awesome, right?  Yeah, super great.

Except for the resulting demographic crisis.  Ignoring for a moment the obviously issues, think about your grandparents’ generation.  They were the Greatest Generation, except for all those times they fought vociferously to keep society segregated and how they still use words like “negro” and blame the occasional local mishap on a Jewish conspiracy? And it’s fine because they’re old, and back in their day, that was the norm, and hell, they’re gonna die soon anyway?  Now imagine they never die and they always vote and they’re you now.  Sure, our generation has come a long way on accepting people’s differences, but it’s almost guaranteed that in 60 years we’ll be like way sexist/racist/classist/-ist-against-something, like robots, or people who are in love with robots, or people who are in love with people instead of robots, or schizophrenics⁹ — and that will keep happening, as each new generation fights some new social battle against the mounting legions of preceding generations, forever.

This of course ignores the really obvious demographic issue, which we’re already facing: we have enough problems funding social security now that people live to be 80, just imagine how bad it will be if no one ever dies.  Maybe we won’t need social security, though — maybe everyone can keep on working, tirelessly, forever.

Great, not only are we toiling in endless perpetuity, remember how hard it was to get a job out of college, applying to job postings for “entry level” positions with like 7 years of required experience?  Now imagine being born into a world where everyone’s been doing their job for hundreds of years.  Good luck climbing the ol’ corporate ladder!

But maybe we won’t need to work at all!  Ignoring completely the population crisis that would result from a world in which no one died (not to mention in which people stayed fertile their entire, interminable lives), imagine how mind-bendingly boring it would be.  Lord knows I have enough trouble keeping myself entertained for three hours after work each night¹⁰.  While it sounds awesome to be able to do whatever you want 24 hours a day seven days a week, imagine being able to do that… forever.

It’s the only thing that sounds worse to me than having to work forever.  Now imagine a world where, instead of saber-toothed cats or liver failure or breast cancer or dementia or just being, like, really old, the leading cause of death is ennui-induced suicide.  That’s why I don’t want to live forever.

When I was interviewing last spring, I met a lot of people at a lot of companies.  The people and the companies varied widely in talent, competence, vision, and mission, but there were constants throughout.  One of the things that kept cropping up, especially at larger organizations, was that people spoke in buzzwordy catch-phrases that had very obviously been created somewhere at the top of the company and then forced upon the underlings as “culture” and “team branding.”    People were moving fast and breaking things, demanding excellence, working with stunning colleagues, and just generally guzzling that delicious cherry Kool-Aid (TM).

When you hear that kind of cultish lingo, it can be off-putting; I know it was for me.  There I was, talking to some of the brightest engineers, project managers, and MBAs in the country, and they seemed completely incapable of thinking for themselves, just parroting back meaningless phrases.  I mean, wake up, sheeple!  You’re playing right into the hands of the your corporate masters!  When I was weighing the pros and cons of the offers I got, I actually listed LinkedIn’s well-defined culture and values as a con.  I mean, it just seemed so phony to even make that list in the first place.  What company would ever be like, “We have a strong culture of settling for mediocrity!” or, “We willfully abuse our customers, because we enjoy it, and it makes us feel good.”

But in my time at the company, I have come to view the rigorous cultural definition as a huge positive.  Not because I think the values themselves are so revolutionary; they’re obviously great things to value or whatever, but again, pretty commonsense.  What I’ve found most useful is actually what originally turned me off in the first place — specifically, that they are so well-defined and brand-y.¹

What I didn’t realize about a well-defined corporate culture is that it provides a shared framework for communication, a sort of internal language you can use that everybody understands.  This is especially important in a large organization, where you’re likely to work with people you’ve never met before; it acts as a sort of common-ground handshake, like how people from the same school or city can find common ground over a shared sports team. “Members first!” becomes the new “how ’bout them Falcons?”

This shared language is also critical to the day-to-day running of the business, because it facilitates communication and provides a framework for business decisions.  When someone comes to me with a ball of code that’s held together with spit, duct-tape, and band-aids and copied to a floppy disk — and not one of those hard floppy disks from the ’90s but one of those actually floppy floppy disks from the ’80s — I don’t have to try to figure out how to tactfully but forcefully chastise this extremely hypothetical person that I’m extremely hypothetically managing.  I just tell him that I’m going to “demand excellence” on this project — in this case, excellence is cleaned up, well-tested, and preferably not floppy.  Likewise, when someone proposes a project publishing everyone’s private messages, you can pretty easily shut that down as a quick “members first” violation.

Those are obviously super contrived examples, but you’d be surprised how often the core values come up in conversation at work and how effective they are for framing the decision making process.  The core values’ success in this regard betrays an interesting quality about them — namely, that they were designed.²  This is probably one of those things that seems super easy on the outside, but there’s like a secret hidden world of best practices and domain knowledge and consultants who charge hourly rates in the thousands, like compliance with the Affordable Care Act, or celebrity Twitter account management.

Not knowing any of the insider knowledge, I attribute their success to the fact that they’re pithy, they’re bulletized, they’re imperative, and they’re ubiquitous.  They’re short and easy to remember, which makes them easy to sprinkle into conversation, and they come in a single short list; the company may value other things, but these are the core values, the ones we’re going to talk about and use as a framework for internal communication.  The fact that they tell us what to do and how to do it also makes them more tangible; they are a call to action rather than a list of ethereal concepts.³   They have also been visibly adopted from the top down; they get used by execs in meetings and speeches and are displayed prominently in internal communications like emails and posters, and because of the first three factors there’s not a lot of variation in phrasing that might confuse the issue.  They are, in effect, well-managed as a brand, which has been critical to their success.

I bring this up because, as I mentioned earlier, in my interviewing I encountered a lot of different perspectives.  One of the most interesting and, frankly, valuable perspectives I got was from the CEO of a pretty successful startup, who told me that as CEO he had two jobs: Setting corporate culture and identifying talent.  After that, he just gets out of the way. Since I still dream of starting my own (actually successful) business, it’s interesting to think about how I could apply what I’ve learned about corporate culture to my own business one day.  Of course, since that business is still extremely hypothetical, I guess I’ll just blog about it.

Dear Recruiters,

As a recent job hunter, I talked to a lot of people at a lot of different companies, and words cannot express how appreciative I was when I finally talked with one of you — a professional whose entire role was to work with people in my position, looking for jobs.  You were kind, you were empathetic, you were interested in my success as a candidate, and you lent your company an air of credibility.  In many cases, you went above and beyond, scheduling on-sites at the last minute and expediting the process from start to finish during a two-week whirlwind of interviews on both coasts.  I truly cannot overstate how thankful I am for your services.

But, in the aim of being open, honest, and constructive, I have some feedback for you.  This may not apply to each of you — in fact it may apply to only one of you, or even none of you — but I urge you to examine your practices on each point and consider how you might apply each lesson going forward in your professional activities.

My first piece of feedback is simple and easy to do: get scheduling right.  Let me know when I should expect to hear back from you, and write it down.  That date is now a deadline.  If you can’t get back to me by then, it’s not a problem, but you need to let me know before that deadline passes so that I can adjust my expectations.  Just to confirm, it can be helpful to summarize all action items and deadlines in written form — a quick email — after our conversation.  In an extreme example where such action would have been helpful, I ended a phone call with one of you with a discussion about my availability for a phone interview; we discussed a particular date and time, and I took that to mean that the interview would be at that date and time.  I waited an hour and a half for the phone to ring (maybe there was a time zone issue?), and it never did.  Finally, I emailed you, and to my embarrassment, our discussion was but a preliminary one, and in fact the interview had not been scheduled.  A simple note indicating the schedule was tentative, and that I should expect confirmation from a third party, would have saved me a lot of embarrassment.

While we’re on the subject of scheduling, could you also try to make sure you’re on time for our calls?  This feedback is not just for recruiters, but is especially aimed at people conducting interviews.  Since you’re calling me (and I’m not calling you), I have no recourse in the event you just don’t show, save to email the recruiter (see above).  About three minutes after you’re supposed to call, I start to get anxious.  After five minutes, you’re late.  After 7, I assume the problem is on my end, and that I’m somehow wrong (sometimes I am; see above).  Again, it’s fine if things change or you’re running late, just communicate that to me.

Speaking of time, let’s talk about time zones and daylight saving time for a moment.  I may be on record as being vehemently against both concepts, but we live in an unfortunate world where the places we inhabit, be they San Francisco, New York, Washington D.C., or any other where in this otherwise great nation, are subject to not one, not two, but three separate time zones¹.  If you don’t know which one you’re in, Google “What time is it,” and you’ll find out.

On the one hand, I’d like to express my appreciation — especially to the west coast companies, as I was on the east coast², for always giving me a time zone.  On the other hand, it was confusing to me to see things like “11:00 AM PST on June 14, 2015,” since there are literally no places in the U.S. that observe PST in June.  A normal person would see this as an honest mistake³ and assume that they meant Pacific Prevailing Time, but as someone who was interviewing for data-centric positions, I honestly had the thought run through my mind that this might be some sort of test, given the importance of time zone information in time data and the indescribable complexity of dealing with such information.  I was so frustrated with this phenomenon that I composed an entire tweet about it:

Hopefully that tweet gives you a solid understanding of just how passionate I am about time zone data: Honestly? Not very.  I am pretty much 140 characters (or less) passionate about it, give or take a few blog posts.  You know what else I’m not passionate about?  Messaging apps.  Nor am I passionate about scalable web services, cloud storage, social networking, dating apps for 30-to-32 -year-old Zoroastrians with kids, or whatever your company’s app does⁴ that you put in your job posting.  Pretty much the only thing I’m really passionate about is sex, and even for that, only when I’m actually in the middle of having it.  For certain stretches of the term, you could claim I’m passionate about automation, or maybe dinosaurs, in the way a 6 year old’s unbridled enthusiasm about a topic well beyond his comprehension will undoubtedly leave a mark on him for another 25 years.  But Hadoop? No, I am not, nor indeed is Jim Q. “Apache” Hadoop himself, passionate about Hadoop.

However, as part of my new job, I am learning about Hadoop; it seems real great or whatever.  But besides passionate, you know what else I’m not?  I’m not the best at Hadoop — in fact I haven’t actually touched it yet.  So if you tell me that you only hire the best of the best, guess whose application you’re gonna be missing out on?  Hint: it’s mine.

 

But wait! There’s more!  Think about how many other, actually great people aren’t going to apply either.  Somewhere in there is probably a candidate that could transform your business, and you’re missing out on that candidate.  Bringing this back to my last post, in the words of Laurie Voss in his post “You Suck at Technical Interviews,” “Don’t hire [people] for what they already know.”  Hire them for what they can learn.  Going even fuller-circle on my last post, Joel Spolsky on the Stack Exchange podcast brings up some excellent points on that practice.  You can find them at about the 31:36 mark in the embedded episode below.

To paraphrase his point, which is actually Sara Chipps’s point from a previous podcast I haven’t (yet!) listened to, you don’t get fewer bad applicants, you just get fewer non-traditional ones.  The message you’re trying to send is that applicants will work with really smart people, but you end up scaring off anyone who doesn’t think they’re already the best, which means you miss out on a lot of really smart people who will learn what they need to, enrich the overall environment by teaching others what they know, and ultimately get things done.

Also, as a side note that I can’t make into a footnote due to *technical difficulties*, I didn’t start listening to the Stack Exchange podcast until recently, so it didn’t make it into my posts about podcasts, but in my own tweetwords⁵,

I know that I have been throwing negative examples left and right at you, but again, my experience was overwhelmingly positive.  To round this out, I want to take a moment to call out something that was done right.  Specifically, whether or not I actually was special in any way, a number of people, from recruiters to CEOs, went out of their way to make me feel that way.  There is nothing worse than feeling like you are one of a thousand people in a pipeline — a feeling I did experience — but the personal touch of people at a number of companies really made me feel like a valued individual, even at places I had no business applying to.  A small thing, like a 30-second phone call from an executive after receiving an offer or a text to say that the schedule had changed at the last minute significantly raised my perception of the company and my likelihood to recommend it to someone in my professional network.  It just goes to show the power of even the smallest gesture; a little thing can go a long way.

So, recruiters, hopefully I have given you an idea of a few little things you can do that will go a long way to improve your performance.  I look forward to seeing how far you’ve come on our next encounter, whenever that may be.

In a famous¹ blog post from the great Joel Spolsky² entitled “The Guerrilla Guide to Interviewing,” he lays out very practical, fundamental, and altogether good rules for how a company should interview technical people.  Laurie Voss, CTO of npm — who, by the way, was just super great to apply to, because Laurie actually keeps you updated on your status, like omg what a breath of fresh air³ — referenced the post in his excellent post “You Suck at Technical Interviews,” which I also highly recommend reading. These were obviously super useful to me back in the day as someone who had to interview technical people (duh).

But what about people interviewing for a technical position?  Or, more broadly, any position? As someone who recently went through the process of interviewing for a technical position — unexpectedly successfully, I might add — I present to you the guerrilla guide to being interviewed.

The premise, for those who didn’t read the above-linked post, is that a bunch of guerrillas have hijacked a ferry and demanded something you’re good at making (Spolsky uses a Fortran compiler as an example), and you have to prove that you should be on the team that will produce this thing in a life-or-death scenario.  Ultimately, you are going to be able to do this by proving to the team that you are smart (able to produce the thing in question, or learn how to)m that you get things done (you can produce it before the guerrillas blow up the ferry), and that you’re not an asshole.

So how do you do that?  First, I’ll walk you through the interviewing process, because it’s good to know what kinds of opportunities you’ll have to demonstrate your value.  Then, I’ll give you a couple of good ways to show that you’re a non-asshole who’s smart and gets things done throughout the process.

The process

I went through the full spectrum of interviews with five companies over the course of two or three weeks, and every single one of them went something like this⁴:

1. Talk to a recruiter
2. Phone screen (this may not happen if the job is in town)
3. On-site
4. Decision

The recruiter is there to determine if you’re a crazy person or not; for smaller companies, it may be any sort of non-technical person (I spoke to a CEO at one company).  The phone screen may be Skype-based, and if it’s a technical position, it should include some coding — it’ll almost certainly be with a technical person.  The on-site usually consists of a tour of the office and a few face-to-face interviews, which may be technical or not, and the decision will probably be made as a team and delivered over the phone (probably not in-person that day).

There are obviously variations on this theme, so ask the recruiter what to expect.  In fact, ask everyone what to expect next, always.  It can give you a good insight into whether or not you’re going to get to the next step; if someone really liked you, they’ll probably say it.  Plus, a lot of people don’t like the awkwardness of telling you you didn’t make the cut, so they just won’t get back to you and leave you in a weird limbo. It’s good to know when you should expect to hear something, and if you don’t then send an email or follow up.  The worst case is they don’t respond.

Know your audience

It’s critical to understand the role of the person you’re talking to.  For instance, the recruiter is really interested in three things: do you know what you’re applying to, have you just completely fabricated your resume, and are you a sane person.

To the first point, it is essential that you know what you are applying to, and can reasonably say that you are interested in the subject.

To the second, remember recruiters are not engineers, and although they will ask you basic technical questions about your resume, you should not get into the weeds about how your solution to X problem was linearithmic in time compared to the previous solution, which was quadratic.  They may have a few key words they’re looking for (e.g., if your resume mentions you have SQL experience, they probably want you to say “SELECT,” “UPDATE,” etc. and maybe want to hear that you have DDL and DML experience).  They are also interested in applications — what did you do with your SQL experience? If you say that you developed a login GUI, you are lying.  But if you say that you persisted user info to a DB, great!  You passed the test — you are smart (know the stuff you claim to know) and you did a thing.  Obviously, if prompted, give additional detail.

To the final point, this is your first personality screen; you want to sound intelligent without sounding like an asshole.  You can be the smartest man in the world and be an asshole, and no one will want to work with you.  Remember that the recruiter will be your primary point of contact and, in many cases, will end up going to bat for you after the interviews are done and it’s offer time (I think some may even be paid on commission), so you want them on your side.

Similarly, if you’re talking to an executive or a high-level manager, it’s almost certainly a behavioral interview — you want to sound inquisitive and curious about the business while demonstrating that the things you have gotten done have driven value for the business.  A lower-level manager or someone in the position you’re being interviewed for wants to know that you have technical chops and aren’t a huge pain to work with.

Fail early, fail often

Even the smartest people are really dumb sometimes (or maybe it’s just me?).  If you haven’t interviewed in a while, you should apply to as many marginal places as possible, so you can use them as practice.  These can be places that don’t really have a position that matches your skills, a place that seems really cool but you’re probably not qualified for, or a place you’re just not that interested in working at, but you are qualified for.  You want to apply to as many as possible, since only a few will actually get back to you.  This way, you can get out your dumbness before you need to demonstrate that you’re smart to people you really care about.  This also lets you know what sorts of things people are going to ask about — but more than that, when you lay awake at night wondering why you bombed such an easy question, you’ll be kicking yourself for not saying the obvious, glorious answer that has formed in the last few days since the interview.  Go with that answer when you want to demonstrate that you’re smart.

For instance, I interviewed for a really cool-sounding drone company, and they asked me my experience with deployment.  I basically responded with, “I dunno, we sorta emailed folks, and then if no one objected, we pushed it?”  That is, just, like, such a bad answer — but my problem was that I hadn’t thought about that question, and I wasn’t sure of a good way to answer it that would be interesting.  Within 24 hours, I had considered every single time I had deployed something that wasn’t super vanilla, and even though it was like 1-2% of total deployments, I still had 15 examples of things that needed backward compatibility built in during a transition phase; communications and documentation that needed to support multiple versions; OS upgrades on servers; daemon upgrades for job central, firm-critical scheduling software; core parsing software that we ran two versions in parallel for a month to ensure there were no unexpected differences (hint: there were!); the very versioning system we used!  I could have gone on and on about all of it, and the next time I was asked that question, I nailed it, and I sounded super smart and I got to tell people about a lot of the stuff I did.

Prepare, prepare, prepare

It’s not hard to prepare for an interview, and it gives you a chance to look smart to anyone you’re talking to.  There are a couple of things you really want to do, and, assuming you are even slightly qualified, they just aren’t that hard and they don’t take that long.

• Basic company research: go to the website, check out TechCrunch (or whatever); see what’s new.
• Basic job research: what do they want? What should you be emphasizing? This information will be in the job posting.
• Basic interview research: if they tell you who will be interviewing you, check out their LinkedIn page; they’ll see you viewed it (“Hey look, the candidate prepared!”), and you can use this to tailor your questions to your interviewer.

It takes two hours or less to do this, and if you come up with an intelligent question or insight, guess what? You’ve just demonstrated that you’re smart.

Additionally, if they send you any materials, look them over.  98% of applicants won’t do that, but it gives you a good starting point for what sets this company apart from others — more importantly, though, it gives you a starting point for what this company thinks sets it apart from others, and you can hone in on that to your advantage in the question phase.

Speaking of the question phase, most interviewers will leave a little time at the end for you to ask questions.  It’s really good to have a few questions you can ask everyone, and a few questions you can ask certain people.  Your questions should reflect positively on both you and the company, or else you risk looking like an asshole.  A really good question to ask is, “What do you love about the company?”  It’s positive (never ask “what do you not like,”) and you’ll get a really good idea what the people at the company value.  Plus, you can ask the same question to everyone, and you’ll learn something new every time.  Another good one is, “why did you join?”, which is a very different question — “I joined because the hours and pay, but I stayed because I love the product.”

Otherwise, ask questions targeted to the role of the person interviewing you — ask a person doing your job what his or her day-to-day is like, but ask senior folks when they joined and what role they had (does the company promote from within?), and what the direction of the team / company is — where will we be in 5 years?  Also, use “we” — it makes it seem like you’re already seeing yourself there.  These sorts of questions make you sound like a thinker — a smart person!

You can convince them you get things done by asking questions about how they get things done — “Tell me about some production-level code you’ve shipped in the last three months?” is a great question for a peer, while, “What are the key milestones to hit in achieving that vision?” is a great follow-up to the question above for a more senior interviewer.

Be one with the interviewer

If you haven’t interviewed someone before — or maybe even if you have — maybe especially if you have? — and you’re applying for a technical position, make sure you read those two posts I mentioned earlier⁵.  They should give you keen insight not only into what a good company is looking for, but also into the fact that no one who is interviewing you knows what they are doing.  This is important to understand: most interviewers are not professional interviewers, they are professional something-elsers.  They are evaluating whether or not they want to work with you.  If you’ve never worked with someone who is awful to work with, congratulations on interviewing for your first job!  The rest of us know that there’s nothing worse than someone who’s defensive and protective of their knowledge, or someone who just can’t get a single thing done… or, of course, an asshole.

Another reason to read those articles is it gives you a chance to evaluate the company.  I, for one, agree with those articles, so pretty much anything that deviated from them was a knock against the company for me.  For instance, I had a technical phone screen with one company, only to be brought up to the office and have four half-hour behavioral interviews.  No whiteboards, no coding — no one gave a hoot what I could do or how I wanted to do it. Just the same questions asked over and over again on loop.  Likewise, I had a few interviews where people just asked me rote questions — they were OK questions, designed to see if I was completely lying on my resume, but they weren’t coding — and it kinda put me off, because I kept thinking, “This doesn’t matter.  Ask me to solve a problem.” The message I got was that the company interviewed to find people who were smart, not people who could get things done, which meant they probably had a relatively high proportion of people who couldn’t.

It’s also important — especially for the more junior people you interact with — not to underestimate the kindness of strangers.  They want you to get the job; it’s uncomfortable to judge people.  I can’t tell you how many people I interviewed that were marginal at best that I passed along, just because I didn’t want to be the reason they were out on the street.  That’s absurd, of course — they’ll get a job somewhere — but the only part of their life I see as an interviewer is the part where they perform their trade in front of me and I say, “Meh! Not good enough.”  So relax, they’re on your side.

Talk too much

The interviewer doesn’t know what you’re thinking.  He or she doesn’t know what you know.  You, and you alone, do.  Your job is to tell them what you’re thinking and convince them that you know what you know you know.

Consider the following completely ridiculous example: you are handed a clicky pen and told you need to write a letter.  How would you do it?

You can either click the pen and write the letter — congrats, you know how to operate a clicky pen — or you can walk through the absurd amount of knowledge required to get to even that stage: “This is a pen. I know that because I’ve used a number of pens before, of many types.  Pens are good for writing, so this is an excellent tool to write the letter.  I know pens come in many different colors; this appears to be blue, because the pen itself is blue and the pen color usually matches the color of the ink, but we can test that in a moment.  Pens I’ve used have largely come in three varieties — clicky, twisty, and capped.  Additionally, I know of a fourth type — fountain — but I’m not very familiar with them. From experience I can say that this appears to be clicky; there’s no twisty portion and certainly no cap, so I’m going to test that assumption by clicking the end, which should — aha! — produce the writing tip…” Not only do you know how to operate a clicky pen, you know how to operate all pens, and you’ve demonstrated deep knowledge of the subject and clearly identified that you understand the boundaries of your knowledge.  You are smart, and what’s more, your vast experience in pen applications suggests you also know how to get things done.

Admittedly, it’s not a bad idea to preface your spiel with a quick, “I’m going to explain everything I do, so if I’m going too slowly or being overly explanatory, just let me know.”

Know what you don’t know

The above example hits on something really important, that Laurie Voss also mentions: it’s important to know your limits.  As he states, “Strong candidates say ‘I don’t know’ as soon as they hit their limit, and may start asking questions.”

There’s no better way to prove that you’re not smart than to try to bluff your way through something you don’t know.⁶ Instead, it’s important to be up front about it — “I don’t know how I’m going to write a letter with this pen, the pen doesn’t appear to write.”

As Voss continues, “The very strongest candidates say ‘but if I had to guess’ and then attempt to extrapolate.”  It’s a great chance to show what you do know, even though you don’t know exactly what they asked.  “I don’t know how to use this pen because it doesn’t write and there’s no top to remove, but I’ve seen pens that need to be dipped in ink.  They look different than this one, though, so that might not be it either.  Can you give me a pointer here?”  Then, when they say, “Yeah, this is a clicky pen, click the thing,” extrapolate further — show that you internalized and learned something: “Ah!  The tip protrudes!  I bet there’s other mechanisms — maybe you could twist a pen and have the tip retract and protrude like that.  This retracting tip concept might offer a few advantages over the models I’m familiar with; for instance, I bet it does not dry out as quickly.”  Not only have you learned something, you’ve also shown that you’ve internalized it and can apply it to other situations.  You’ve turned a weakness into a strength!  People love that stuff.

Be honest

This is sort of in the same vein as “Know what you don’t know,” but broader — be honest about what you don’t know, and about what you do.  For one company, I had six or seven interviewers.  Three of them asked me basically the same question.  The first time, I took a broad approach — “You could do X, but I could see how Y, Z, A-W, and a few more options could really work.”  The second time, I said, “I’ll be honest, I’ve already been asked this question,” to which the interviewer replied, “Great!  Where did you end up?” and I told her, and she said, “OK — can you take that one step further?” I had the chance not only to score Honesty Points (TM), which are only awarded to people who aren’t assholes, but also to show her that I’d Learned Something (TM), which is what smart people do, and that I could Apply What I had Learned (TM), which gets stuff done.  If I had just walked through the exactly the same thing as the first time, I wouldn’t have really shown anything new, and — worst case — they’d have figured out they asked the same thing and I gave the same answer twice without saying anything.  When the third interviewer asked it, I told her I’d heard it twice before, and when she asked where I got to and I told her, she decided to use a different question, and I got to show how smart I was in another way.

This also goes for other parts of the interview — be open and up front about whether you’re looking at other companies or whether you have other offers.  Yes, you can use another offer to get a quicker response from a company you’re interested in, but don’t lie about it.  If you have an offer from a company you’re not interested in, let them know immediately that you won’t be taking the job.  Likewise, don’t make up an offer in order to get a faster / better response from a company you are interested in.  Don’t be an asshole.

Keep an open mind

My mother was a recruiter, which was a super valuable resource in my job hunt, because she’d seen it from the other side (see “Be one with the interviewer”).  The best piece of advice she gave me was, “Don’t decide on the job until you have the offer.  Until then, you’re interested.”

This has a really practical application: if the job you’re really interested in turns you down, and you stuck around with a job that gave you an offer you weren’t so interested in, guess what?  You still have a job.

But on another, less practical level, it gives you two more things.  You get something to compare other jobs to — you get additional experience with a number of different companies, and if you’ve been asking everyone your canned questions, you get a lot of answers to cross-calibrate by.  You may also not know that you’re interested in something until you go through the process.  I got an interview at an internet behemoth — something that predates Google — and I thought it would be a terrible job.  When I got there, I found out they were under new management, had a clear and high-impact way to get back on track, and were solving a really interesting problem.  Likewise, for another job in “business analytics,” I started off thinking that it wasn’t what I wanted to do.  After I went to the office and met everyone, I realized that the company was full of incredibly intelligent, bright, professional people that I wanted to work with, the position involved developing data-driven applications more than analysis, and the company had a great culture. If I had said no up front, I would probably be in Charlotte right now instead of San Francisco.  So don’t turn the job down until you get it.

Closing thoughts

I’ve spewn a lot of nonsense at you, but this is the stuff that worked for me.  In the end, you want to present yourself as someone who’s smart and gets things done, but also as someone who’s not an asshole.  The best way to do that is to show that you can learn, show that you can solve problems, and be open and honest.

And if that’s not enough?  You didn’t wanna work there anyway.

In my spare time (which is plentiful), I’ve been teaching myself Rails, the full-stack Ruby framework, with which I’ll build my next side project.  Side project side note: I have a big ol’ database diagram written in whiteboard marker on my window.  I feel like a real engineer!

Anyway, Rails has some really cool features (I love the scaffolding concept, the rigorous MVC emphasis, etc.), and learning it has actually given me a bit of perspective on where other full-stack frameworks — principally Meteor, on which I built Squeaky Wheel — are coming from.  To some extent, they need to emulate Rails, because Rails has been the backbone of web app development basically since it was released 10 years ago, and a huge chunk of their primary user base is going to be coming from the Rails paradigm.  But they also emulate it because it’s convenient and it works, so while they may aim to improve upon it, they’re still using many of its key features.  I’m still learning Rails, so I have a lot of features still to learn about, but so far it seems much better than what came before it — whatever that was.

Of course, as part of learning Rails, I’m learning a bit of Ruby.  Ruby has some cool features too, I guess?  But mostly, I kinda hate it?

My biggest problem with it is that it adds in a ton of “features” that are supposed to be convenient, but in reality just lead to sloppy code and hard-to-find bugs.  If you’re familiar with arguments in this vein, right now you’re thinking “Oh he just hates dynamic typing.” I’m not talking about static vs. dynamic typing.  (Sidenote: I believe static typing can lead to compile time errors that could have a 0% chance of being hit at runtime (although why is that code branch there, then?) — I learned on PHP and am all for dynamic typing.  Except I think you should rigorously define the output type; it drives me nuts when a function might return, for instance, an array … unless there’s only one element, then it returns that element … or false for zero elements.  THAT IS TERRIBLE PRACTICE PEOPLE WHAT ARE YOU DOING YOU ARE THE WORST.  A lot of R stuff is particularly bad (why does simplify always default to TRUE?))

I am talking very specifically about needless — and often counterintuitive or conditional — elimination of what many people would view as “cruft” — stuff like brackets, parentheses, semicolons, etc.  I like these things for the same reason that I love the Oxford comma*: it adds clarity for humans.**  Ruby has do and end to mark the beginnings and ends of blocks, but I hate anything that doesn’t specifically require brackets even for simple, one-line if statements.  Failure to provide brackets is responsible for a famous Apple SSL bug, which was written like so (with a duplicate goto fail line):

if (...) 
  goto fail;
  goto fail;

This would have been picked up immediately with curly braces and literally any text editor with auto-formatting  (or eliminated entirely):

if (...) { 
  goto fail; 
}

goto fail; # pretty obvious...

or even…

if (...) { 
 goto fail;
 goto fail;
} # completely harmless

The error comes from ambiguity in how curly brackets work: they denote a block, but aren’t necessary if the block is only one line so then they can be omitted.  Needing to remember that there is an exception (“I can omit these brackets in this case“) when it actually provides negligible benefit (honestly, two less characters matters that much to you?) opens you up to a world of hurt.  Any time you encounter a feature that includes the words “except” or “if,” you don’t have a feature, you have a potential bug.

Ruby is positively riddled with this sort of “convenient” shortcut.  You can eliminate parentheses around function arguments unless you need to chain something (oh and by the way, this makes it really unclear whether you’re working with a function or a value, since either of the following is syntactically valid and may be hidden behind the scenes:

rand_no = 7
def rand_no  
  # do like 30 minutes of computations for no apparent reason
  7
end

And then you innocently call a = rand_no + 1 and it takes half an hour for some reason… or worse, you define both, and all of a sudden one of them needs parentheses:

rand_no = 7
def rand_no 
  8
end
rand_no
=> 7
rand_no()
=> 8

).  What if I want to use a function return value as an argument to another function? Better use parentheses because this is ambiguous:

def foo(a, b=0)   
  a + b
end
def bar(a=0, b=0)
  a - b
end

foo bar 3, 3 # does this do foo(bar(3), 3) or foo(bar(3, 3)) or ...what... -- actually it returns an error because it's ambiguous.

You see those function definitions above?  They didn’t require a return statement — so convenient.  Except that if you want to terminate execution, you can use a return statement.  There’s no semicolons — wow! — but you can do multiline statements.  But if you do you better make sure it’s obvious you’re stopping on that line:

def foo a = 0
  a + 1
end

bar = foo 1
bar 
=> 2
bar = foo
1
bar
=> 1
bar = foo(
1)
bar
=> 2

I could go on and on — and indeed as I’m learning I come across more and more of these cases (e.g., in method definitions if you assign something, the left side of the assignment refers to a local variable, but anything on the right side will look for a local definition, then hop to a class-level definition if a local one is not found), and every time I see “except” or “but” or “in this cases” I die a little bit inside.  Many of these “features” are not unique to Ruby, either — I’ve seen these in a thousand places, and as I said, I started out with PHP, which has its own set of terrible, awful, no good, very bad conventions.

In the highly unlikely event you are about to begin designing a language, I urge you to take a step back and think about what you’re doing when you attempt to make things “more convenient.”  Just because you hate typing parentheses doesn’t mean they’re not a useful construct.  If what you’re doing has negligible benefits in the average case, but makes me remember another rule for when I’m allowed to use your shortcut, it’s not a shortcut.  You’ve made my job harder, not easier.  Favor consistency and make it as easy as possible for me to understand what I’m reading and writing without having to clog my head with exceptions to rules.

In the meantime, I’ll stick with Javascript***, thanks.

---

 

* Apparently also known as the “serial comma,” because that podcast is everywhere.

** But like also maybe don’t trust a website that advertises the following:

*** 100% definitely click on this link if you have ever written any code ever and watch the entire thing if you have not seen it.

I promised to write more about development on this blog, and I’ll make that promise again now.  But before I make good on that promise, I wanted to talk to about something completely unrelated.

 

A couple of friends of mine are leaving the DC area this summer and have been putting together a DC bucket list.  They’ve been extra kind in inviting me along with them for some of the more interesting outings, and last weekend we went about 30 miles west of the city to Manassas, site of the first real battle of the American Civil War and another battle the next year.  (Those of you up in arms yelling about Fort Sumter being the first battle — which is probably none of you, since I assume anyone reading what I have to say is a mindless troglodyte — should know that the Fort was surrendered with no casualties.)

It was fascinating to see the battlefield — I’ve read a number of books about battles in the Civil War, and I’ve seen maps, but I’m terrible at visualizing what those mean.  Actually being in the field was a completely different experience; you could easily see how the troops were deployed and what the key strategic elements of the battle were.  (The decisive fighting of First Manassas took place on a field no larger than about 300m x 300m, so it was particularly easy in this case.)

Also, completely unrelated to the main thrust of this post, I Learned A Thing!  I had always assumed that when Stonewall Jackson got his nickname, it was during some great Confederate victory mid-way through the war, when his line held while the lines to his left and right were breaking.  Not so!  It turns out the famous, “There stands Jackson like a stone wall!” line was given at First Manassas, and not because his men were standing tall in the face of withering fire from an overwhelming enemy… but because they had just shown up at all while everyone else was fleeing in terror back toward Richmond.

Anyway, this trip was particularly topical, since the Civil War ended 150 years ago last month with Lee’s surrender to Grant at Appomattox on April 9, 1865; Abraham Lincoln would get to see his nation at peace briefly before being shot on April 14, dying the following morning.  Except…

While Lee was easily the best commander, and his army of Northern Virginia likely the best hope for the Confederacy in the field, his army was far from the last army in the field.  In fact, the largest Confederate surrender didn’t occur until April 26, almost two weeks after Lincoln’s assassination, in Durham, NC; the Confederate government wouldn’t dissolve until May 5; the last battle would be fought on May 13; the last general wouldn’t surrender until June 23, and the new president wouldn’t declare the war’s end until August of 1866.

There’s a tricky thing about war; it turns out that it doesn’t necessarily matter whether you defeat the enemy’s army in the field or, say, accomplish your mission militarily, when your real goal is to completely change the way of life of your conquered foe.  In hindsight, the end of the American Civil War was relatively straightforward; the most important army surrendered, the rest followed, and within a year or so, things were relatively peaceful.  Of course, there’s the tricky bit of Reconstruction, and while the occupying Union troops had their work cut out for them (I recommend listening to the recent BackStory episode on the close of the war; (BackStory is one of my favorite podcasts)), there was not widespread guerrilla warfare after the war ended — which is what you might expect given the circumstances.  (There are probably thousands of contributing reasons for this, not the least of which is the widespread failure of Reconstruction to actually change Southern society, curb institutionalized racism, etc., but that’s outside the realm of this post.)

What was particularly interesting to me about the end of the Civil War was the acknowledgement from the highest powers in the Union, implicit in the generous terms of surrender, that the situation could deteriorate into a guerrilla war at all.  Maybe I’m just also a mindless troglodyte, but I was always taught that wars back in the day were fought in pitched battles in the field, at least until North Vietnam saw that their only hope of defeating the militarily superior United States was to engage them on their own terms.  This technique has since been appropriated by insurgents in the Middle East, to our continuing dismay.

But if you look back on it historically, that’s obviously nonsense — the first case of a guerrilla pseudo-war against occupying forces was not in Vietnam.  It wasn’t even in the 20th Century; the word dates back to the Peninsular War of the early 19th Century, but the tactics were used long before that.  Many pre-Vietnam instances are even well-known; for instance, the French Resistance during World War II is not that different than modern insurgencies, Americans just view it differently because we (not the French) were still at war at the time.

So what do you do when you’ve won the “real” war, but the insurgency continues?  Our strategy recently has been to train the (new) government’s troops to do the job while we disengage; it’s hard to say how successful this effort is or will be, but it’s definitely better than Vietnam, when we just cut and ran.

Except it’s exactly the same strategy we used in Vietnam.  And Vietnam wasn’t the first place we used it, either — it turns out this is the same strategy we used in the Philippines after the Philippine-American War (who knew that was a thing?), when we set up a provisional government, then let their army and police take care of the lingering hostilities.

So now, here we are, doing the same thing to solve the same problem. I wonder what we could have learned from our Civil War forebears to avoid this in the first place.

As I’ve mentioned previously (see “New Job“), in January I left my job as a highly paid and undermotivated investment professional and struck out on my own.  For the next two months, I worked hard bringing my idea to life; I maintained a disciplined approach, waking up at 6:00 every morning and sticking to a schedule of distraction-free work time.  I was probably 100-200% more productive working for myself than I had been in the last two years at my old job; I got way more done in way less time.  And in the end, the project was a total, complete failure.  Here’s why.

The Idea

I’ve been in the energy finance industry for over four years, and during that time I worked really hard, especially at the beginning.  But it was pretty clear even from the beginning that no one really believed in what we were doing; we were doing it primarily because there was a lucrative market for it.  Unlike most people, I really did believe we provided a valuable service for the market (and I believe in financial services generally; I believe that financial participants lubricate commodity markets by sending accurate pricing signals and absorbing risk, which smooths out price changes that can cause potentially disastrous market shocks); I just didn’t care.  This wasn’t a problem that, on its face, really affected me.

What I really wanted to work on — and work hard on — was a problem that I believed in.  Thing is, as a middle class white guy, my life is actually pretty great and I just don’t have that many problems.  Sure, there’s all sorts of societal issues I believe in — gender / marriage / racial equality, promoting women in STEM fields, etc. — but these all have experts already working tirelessly on the problem, and I’m both not an expert and also, in the immortal words of Homer Simpson (~19:30 in that video),  just one man. .  If only there were, I dunno, like a list of problems or inconveniences that people face, and I could pick something off and solve it.

 

So I set off to create what was, effectively, a bug tracking system — but instead of for software, it’s for problems in the meat world.

Barriers

There’s a huge and obvious barrier, which is that a typical bug tracking system has people on the other end actually fixing the bugs.  There’s another, complimentary barrier, which is that probably 98% of the bugs that exist already have a real solution.  (For example, if your lifebug is “I have trouble coming up with ideas for what to eat for dinner,” you should check out Random Restaurant Generator, which I just found by googling “random food.”)

That’s not a huge deal, a platform to address existing solutions is actually really useful, and the more existing solutions there are, the smaller the first problem is.  The real problem is that this whole idea relies on having an experienced and self-moderating user base that will resolve bugs, mark duplicates, close off-topic stuff, etc.  In short, this idea suffers from network effects; it gets exponentially more valuable the more active users it has.   In this way, it’s like reddit or the Q&A platform Stack Exchange.

I know that all of these barriers can be overcome, so I did what people advised me to do and went off to make a demo.  It wasn’t feature-complete, and it didn’t look great, but it worked OK and it’d store your data and you could discuss things and there was a basic workflow and yadda yadda.  You can find the demo here, by the way; I recommend you check out the demo release notes, which are basically my apology to anyone attempting to use it.

The point is, it works, so I’m ready to show this to people who can help me solve the bigger user acquisition problem and get funding or whatever, which I more generally call “the business side of things.”  About two weeks ago, I sat down to look into the business side of things, and that’s where the trouble started.

The Trouble

The business aspect can, to me, be broken into two parts:

• Getting funding: I need this so that I can hire developers to fix the thousands of UX issues in that demo, a designer to make it look good, customer acquisition, marketing, etc.
• Building the user base: I need this for my product to be useful.

Here’s what I know about either of those things:

 

So I did a little research and looked into accelerators and incubators and the like that might be able to push me forward.

They all want you to explain your idea; as Y Combinator suggests, the best way to do this is to be straightforward and short.  Remember that awesome idea I had about 500 words ago? “A bug reporting platform for the meat world.”  Simple.  Short.  But my idea had since morphed into something a bit more vague.  I was no longer modeling it as a bug reporting platform; it had become a Q&A site, with two modes of operation, and basically no scope: “A Q&A platform matching problems with solutions, but some of those problems don’t have solutions, and interested users could, like… solve those?  It’s like a Stack Exchange site, but instead of being targeted, it’s really broad, but like… broad in a  very specific way that I can’t quite explain.”  Great pitch, brah.

Another issue was that almost no one I looked at would help a single-founder company, and if they would, they’d do so only reluctantly.  They also wanted things like “revenue projections” and “monetization strategies” and “customer acquisition plans,” and I had a huge whitespace in my brain where that knowledge should be.  I was reading all these success stories and watching videos about companies that are getting funded by the likes of Techstars and Y Combinator, and basically every one of them is about a team that started out as middle school BFFs, and they’ve built like a hundred things together, and even though most of them were dumb, the point is they’ve been doing this forever.  Meanwhile, I’m some asshole working out of his apartment in Virginia who’s never done this before and, not only has he not really researched his idea, he doesn’t even know how to.  I clearly need a partner who knows this stuff.

So I called a friend of mine (incidentally, someone I’ve known since middle school); he’s literally my only in in the startup community, and I told him my idea, with my crappy pitch and all.  And after telling me my pitch is stupid, he goes, “I sort of get where you’re going with this; have you ever heard of Quirky?” and I’m like, “Oh that looks… pretty similar to what I was sort of imagining.”  It’s different, but not that different: having a place where people can submit problems that don’t yet have a solution and get those problems fixed.  And they have people on the other end to fix those problems!  They’re beating me.

OK, so maybe I could work on my pitch and maybe my idea was sufficiently different from what’s out there.  Let’s look at customer acquisition.  My model was pretty similar to Stack Exchange, so how did those guys get off the ground?  SE was founded by Joel Spolsky of Joel on Software and Jeff Atwood of Coding Horror.  You may not know either of these people or their blogs, but you should know that when they started Stack Overflow (the precursor to and still most popular site in the Stack Exchange universe), they had literally thousands of followers and something like 40 combined years of software development experience.  Meanwhile, Aaron Swartz was a key reddit founder; check out his wikipedia page, and you’ll see immediately that this guy had significant experience in the industry and the community.  I, on the other hand, had a blog with 3 followers (one of whom I think is probably a robot?) and no experience in the industry.

So there was already a probably-better version of my idea out there that already had funding, my pitch was terrible, and I didn’t have the relevant experience to make any of this work.  Time to close up shop and get a real job.

Lessons

The key difference between people who’ve been successful in the past and me is that these people are contributing members of the communities they’re interested in.  They have years of experience in software and web development and keep up to date with the latest and greatest technologies; they’re active in the startup community, they’re reading Hacker News and TechCrunch; they have jobs in the industry.  They’re constantly working on side projects.

My startup friend knows about Quirky because he’s keeping up with who’s getting funding, and he has friends and networks built in the community that I just don’t have.  Meanwhile, Spolsky, Atwood, and Swartz have been well-respected members of their respective communities with thousands of followers, so when they announce, “Hey we have this cool idea but it needs users,” they get them.

This is not to diminish the amount of work (and luck) that still goes into building a business; it’s just to say that these guys all started with a leg up that I don’t have.  And the best way to get that leg up is to become a productive member of those communities, which is why I’m about to start looking for jobs in web development in areas with a strong startup culture.

Regrets

On the plus side, I have no regrets.  I learned more about modern web development building Squeaky Wheel than I did in my 4+ years of doing in-house stuff at my old job.  I knew going into this that it was extremely unlikely that my idea would be successful, and I’m not giving up on it entirely — in fact, this failure spawned several new ideas, related and unrelated.  Coming out of this, I know exactly what I want to do, where I want to be, and I have about 4 years worth of fun side project ideas to work on while I gain real experience.  I’m more excited about my future now that I’ve ever been.