Diversity Is Really Freaking Hard


I’m going to discuss an important topic that affects everybody in tech: diversity.

No, this won’t be some preachy post about how diversity is great and how you should be a better human being. Rather, I’m going to tell you about the things I’ve experienced working on diversity – particularly the interesting events of the last few days that happened internally at Stack Overflow.

It’s no secret that the tech industry is not that diverse. It’s mostly dominated by white males, with a few women and minorities making appearances. Those who do enter the industry as a minority often feel marginalized and excluded.

Of about 40 engineering employees at Stack Overflow, maybe 8 are not white men. We can clearly do better.

As you may have learned in my last post, earlier this year I was promoted to Engineering Manager at Stack Overflow (formerly Stack Exchange (formerly Stack Overflow)). One of my first projects was to work on diversity at our company. As a part of this goal, I was given the opportunity to create a new diversity page to showcase our efforts.

There’s a volunteer group that we have internally called the Diversity & Inclusion Panel (DIP). This group works to make Stack Overflow a more open, diverse, and welcoming environment.

There were some awkward feelings that came with taking the lead on the diversity page project. For one, I was a straight white male running a project about diversity, which might raise some eyebrows or make people feel weird/jaded. To mitigate those feelings, and also because I value their opinions, I took the approach of including the DIP in the creation and review of the page. My rationale was that by including a group of self-selected folks who are passionate about diversity, we could reach a solid page design that wasn’t biased by building it myself. To this end the DIP were consulted multiple times and ultimately had the final say on the copy of the page.

Diversity Page Goes Live

After a few months of iterating with designers and the DIP, last week we rolled out the new page. Here’s what it looked like in all its glory (please don’t critique it in the comments – if you do, you missed the point of this post):

Our Shiny New Diversity Page

Our Shiny New Diversity Page

I was excited that we had made progress on such an important and sensitive topic. I announced the roll-out to the DIP group with little feedback or response, which at the time I didn’t think much of. I also broadcast it on Twitter, with very few others from Stack Overflow doing as such themselves. Again, I thought nothing of the lack of engagement.

A few days go by with the new page rolled out where things are mostly business-as-usual from my perspective. And then, last weekend, something really interesting happened.

The Blog Post

An employee at our company wrote a blog post titled “Discussing diversity terrifies me” on their personal blog. They have since taken the post down – a decision they made themselves. The post described this person’s feelings about our new page and how it made them feel uncomfortable in ways that they couldn’t fully explain. This person also explained how they felt terrified to discuss diversity with anyone, ever – even their best friends. This was because of prior experiences at prior companies where the discussion went poorly.

I came across the post on Saturday night at about 9pm. It did not call out me or the page as doing something wrong; it was a way for this person to express some thoughts that were very important to them, but that they otherwise felt they could not bring up.

I Felt Wronged

Upon reading it, I was really pissed off. I couldn’t believe that this person, given numerous opportunities to shape the page as part of the DIP, had remained silent during the project. I couldn’t believe that they didn’t come to me or anyone else at work, and instead took to talking about their issues on their blog, in public, which at the time I felt served to embarrass me in front of the company. After all, they were given tons of opportunities to talk about it internally, so why didn’t they? I felt slighted and wronged. I selfishly felt that this was all a personal attack on my work. I wasn’t happy.

The Company-Wide Revelation

On Monday afternoon I had a private conversation with the person who wrote the blog post. We had a really constructive chat about how the person felt, and ways to improve upon the new page and make it more sincere and reflective of our true values and current workplace diversity. It ended on a positive note. Later Monday evening, I sent out an anonymous survey to solicit broad feedback from folks on how to improve the page. The plan was to iterate to a better version ASAP. Satisfied with trying to improve the situation, I went to bed.

On Tuesday I found myself in a few conversations about our new page. The people engaging me were mostly straight white males (not unlike myself) who all said something similar: “talking about diversity scares me to death” and “it feels like one wrong word and I’m fired.” These conversations continued until about 1pm, when a forward-thinking co-worker realized that we all needed to get on the same page. They brought the diversity page controversy up in our company-wide chat room for literally anyone and everyone to discuss. Many people jumped in and what followed, for lack of better description, was quite an epic conversation. It involved a lot of people from a lot of departments – both people who were visibly diverse and those who were not – and even included 4 executives. The conversation rolled on for a few hours and culminated in a few important outcomes:

  • The person who wrote the blog post felt very uncomfortable talking about diversity at all, with anyone
  • Their blog post gave a voice to many others who felt the same way but were afraid to speak up
  • The diversity page was making people within Stack Overflow uncomfortable

As a result of the company-wide chat, the new diversity page was taken offline.

I Felt Even More Wronged

Conveniently, all of this discussion happened while I was at the doctor’s office for a check-up. As a result of the timing I didn’t get to participate at all. When I returned from the doctor and read the chat transcript, I became very, very upset and angry. I felt betrayed by the company and wronged by almost everybody who participated in the conversation. In hindsight, I think that I probably would have said some things that I’d now regret had I been around to participate in the chat. Ignorance is sometimes bliss.

I was boiling over. Many unfair, selfish, and angry thoughts crossed my mind as I read the chat transcript. I thought things like “f*** it, I’m never touching another diversity project ever again” and “how could these people do this to me?” and even, for a brief moment, “what am I doing working somewhere where I’m undermined and treated unfairly?”

I called it quits a few hours early on Tuesday and had a few drinks of the alcoholic nature. I was fuming, and ranting to my wife, and otherwise upset about how I had been so wronged by the people that I was trying to help. I took some ibuprofen (for the impending hangover and headache) and passed out, unsure of what Wednesday would bring.

Worth noting, I don’t recommend self-medicating with alcohol when you’re upset – it’s a bad strategy.

This Wasn’t About Me At All

I awoke Wednesday morning with a clear mind and new perspective on the events of the past few days. I realized some really important things:

  • Absolutely, literally, none of this was about me. I was being selfish and making it about how I felt, when in reality it was about how we all felt.
  • We had created a diversity page that did a poor job of accomplishing our goals on diversity.
  • Taking the page offline was the right thing to do, because it was making a lot of people in our company uncomfortable. If it had this effect internally, it surely had a similar effect externally. In this case, the page existing was perhaps worse than having no page at all.
  • The person who wrote the blog post was completely in the right, and arguably did the right thing. The alternative was that if they hadn’t spoken up on their blog, nobody may have. This would leave everyone silently feeling uncomfortable.
  • The person who wrote the blog post felt uncomfortable speaking up about diversity at work. They talked about it on their personal blog to keep it outside of the company. This was an important revelation as it showed me that we have a serious issue at our company: people feel as if they don’t always have the right to speak up about difficult subjects like diversity. One person described it as “a manager’s word being law and difficult to contest.”
  • Nobody had been malicious at all. We were all trying to do the right thing, assumed the best of intentions in each other, and were simply expressing our honest feelings on the topic. Feelings are always valid.

Diversity At Stack Overflow

Through all of this I realized a some of why diversity is such a hard topic for people to discuss: no matter what position you are in, you probably feel like you’re not entitled to participate in the conversation. When nobody feels like they’re able to talk, silence soon becomes apathy.

On the topic of diversity issues, apathy rules all. It’s a safe and easy play to do nothing at all. Taking a stance means meeting resistance and having conversations where everyone feels invalidated. Unfortunately, doing nothing enables and furthers the issue.

One of the mistakes that I made was not considering the emotional response of the new diversity page that we created. How the page makes people feel is the only measure of success. The people in our company felt that the page was insincere and made them uncomfortable.

Here’s the truth: despite what the page said, we’re not great at diversity. We have about 40 engineering team members, and only 4 of them are women. At most, 8 or 9 total are of a visible minority. We certainly have a diverse team in the sense that we’re located all over the world, but that isn’t how everybody defines diversity, and maybe isn’t even the most important form of diversity since those geographically diverse people aren’t necessarily marginalized.

It’s really easy to feel as if your company sucks at diversity when any discussion is met with frustration and hurt feelings. However, I am really proud of the fact that at Stack Overflow we are able to have these conversations. We had a company-wide discussion on how the page made everybody feel, and even though that discussion got extremely heated and many people felt many strong emotions, not one person made it personal. There were 4 executives in the conversation and nobody quit or got fired.

I’m thankful that one person had the courage to write a blog post and speak up about their overarching fear of discussing diversity. What scares me as a manager is the idea that people might feel as if there’s no channel to talk about things that make them uncomfortable. If people don’t express their concerns, they suffer silently. It was the actions of one person that saved us all from a much worse outcome.

Ultimately, we made a company diversity page that’s like every other company’s diversity page, at a company that prides itself in not being like any other company. We’ve identified that people at Stack Overflow sometimes feel like they are unable to speak up on difficult topics – both inside and outside of the company – and that’s something that we need to work on.

What’s Next

As I said earlier, the easy and safe play is to do nothing. We could leave things in their current state of no longer having a diversity page, but it would also be the wrong thing to do.

What we must do now is continue the conversation. We need to talk honestly about diversity and discuss the feelings that we have around it. We need to channel those feelings into a better diversity page that accurately reflects our company and how we feel on the subject. We need to admit that diversity is hard, but that we’re working on it. Most importantly, we need to assume the best intentions of each other and make progress together in all of our diversity initiatives.

I hope that in reading this, you feel inspired to start or continue the conversation about diversity in your workplace. Like many companies, we have a long way to go. It’s challenging, but as a co-worker said, “the hardest conversations are often the ones most worth having.”

Developer Turned Manager

In February of 2015, I was promoted to Engineering Manager at Stack Overflow. This has made a lot of people very angry and been widely regarded as a bad move.

There are tons of things I’ve learned so far, some of which I’ve learned the hard way. There’s also a world of difference between managing code, and managing people who code. Your day to day work routine changes completely. You define success differently. You feel a little bit like you just rebooted your career and are starting over at the bottom of the skills ladder. It’s intimidating.

I’m going to discuss my experiences and insights over the last 6 months as a new manager. This one goes out to all of the developers out there who wonder what it’s like to be a manager, or are considering taking the leap into the realm of Pointy Haired Boss.

Trust is the most important thing

To be a successful manager, you must earn the trust of your team members. People won’t work for someone that they can’t trust. Combine this with the fact that a large reason that people leave their jobs is their boss (even above money, benefits, commute, or vacation), and it’s clear that this is your biggest priority as a manager.

Trust is earned, not given. A manager can’t talk people into trusting them; you have to show them that you can be trusted. In my experience, the time it takes to earn trust varies from employee to employee. I had the advantage of having already worked with my employees for almost a year, so some people trusted me on day 1 as a manager based on prior interactions. Others took a few weeks or even months to come around. The important thing to realize is that you can’t rush developing trust. Patience is key.

To earn your team’s trust, you must demonstrate good professional and personal character:

  • Hold everything told to you by employees in confidence. Don’t gossip or talk about employee issues with other employees.
  • Have an “open door” policy: make it clear that people can talk to you about anything, at any time that you’re free.
  • Be a person of your word. Say what you mean, and do what you say.
  • Don’t promise anything that you can’t deliver on. It’s better to say “I’ll see what I can do, but no promises” about a raise, promotion, or bonus than to say “sure we can work that out! No problem!” and then not deliver.
  • Never lie to anyone. Being a liar in the eyes of your employees is the fastest path to failure. They will not only distrust you, but actually start avoiding you as well.
  • Be direct with your people about things that you need to address, especially when it’s uncomfortable to do so. Don’t dodge subjects. Don’t avoid elephants in the room. These problems grow and only get worse if left unresolved.
  • Never be passive-aggressive. Don’t gossip about people. Don’t talk about person A to person B behind their back. It’s important to have an outlet to vent, but make that outlet your spouse or family in complete confidence – not your employees.
  • Praise publicly, punish privately. Never alienate someone in front of the team.
  • Be as objective and fair as possible at all times. Don’t give anyone special treatment or status.

All of these things (and more) are essential characteristics of a good manager.

Code scales, humans don’t

The great thing about code is that when written properly, it scales very well. The same code can easily handle both the 1 user case and the 100,000 users case if it’s efficient and optimized. As a developer this is what we aim for, and it’s easy to measure.

A manager, however, doesn’t scale. The work is done on humans, not computers, and human interactions don’t scale. Just imagine trying to reach consensus on a subject in a meeting of 20 people. It’s much easier to do in a room of 10 or fewer.

No manager can effectively manage 20 direct reports. In fact, people experienced in the field feel that 4-10 employees is the maximum. It’s important to recognize that you can’t get stretched too thin; this will cause you to pay too little attention to your employees and make them feel resentful and unimportant. It will also prevent you from getting any work done. If your team grows too large, split them up and get another manager on board to share the work.

Make people a priority

As a developer, people were an interruption and distraction to my work. As a manager, people are my priority. You must always prioritize people. Not just your people, either. It’s not uncommon for people from other teams to want to talk to you for an outside perspective – make those conversations a priority as well. This means being flexible: if they want to call you and chat at 5pm on a Friday, try and make it happen. If they work in another time zone and want to meet at 7am on a Tuesday, get up early and do it.

Another important aspect of prioritizing people is having a regular 1 on 1 with each of your employees. The 1 on 1 is your employee’s safe place to talk. They will tell you about what’s going on, bring up personal or professional issues, or give you feedback on things that you can do better. I have a recurring 45 minute meeting with each of my employees every 3 weeks. They have been incredibly valuable to me so far.

Make an effort to be organized and use your time effectively. Do everything that you can to avoid rescheduling, being late for, or missing a 1 on 1. If you do this regularly, your culture and morale will suffer greatly. Nothing says “you’re not important” more clearly than missing or rescheduling a 1 on 1 for no good reason.

Embrace uncomfortable conversations

As a developer I sometimes found myself gossiping about, or venting to, other developers about people and policies that were annoying me at work. As a manager, your job is to help people address their problems with each other directly. Encourage people to approach the other party to address their concerns, rather than gossip or vent to co-workers. Be sure to lead by example and practice this consistently yourself.

When someone comes to you with an issue they’re having with someone else, get both parties into a private room with you. Mediate a constructive conversation where they directly discuss their feelings and resolve their concerns. These situations can be awkward and uncomfortable, but you must embrace them and make them a part of your culture. Do this consistently until people start doing it without involving you at all. Make sure that you don’t let problems go unresolved; they only get worse with time.

Success is really hard to measure

The great thing about being a developer is that you usually have a specific problem to solve. “The application needs to do this new thing,” “Fix this bug,” and so on are well scoped problems. When you finally complete the work you get the satisfaction of having accomplished something. You might even get some accolades in a team meeting or town hall.

Management is not a race but a long-distance marathon. You will not be crossing any measurable finish lines anytime soon. As a manager, your work is in affecting the often-intangible aspects of human beings: their thoughts, feelings, soft skills, and overall growth. These types of progress are on-going and arguably never-ending. We are never truly finished growing, learning, and bettering ourselves.

Instead of “fix this bug,” a manager’s task is “help Person improve their interpersonal communication style” or “grow Person’s soft skills so that they can be promoted in a year” or even “figure out a way to help Person get to work on time more often because they keep sleeping in.” None of these are break-fix problems, and thus it’s rare to feel like you’ve succeeded or finished something you’re working on. I find that feelings of success come from the feedback of others: an employee thanking me for some great advice or feedback, someone telling me they’re noticing a positive change on my team, or even a “keep up the good work!” from someone outside of your team. Nothing feels better than knowing you’re making a positive impact in the day to day of your people, but it again requires patience to see results.

Nobody sees you do work

As a developer, your work is done overtly. You’re a better developer for being outspoken about what you’re working on, and creating transparency so that anyone – from other developers to the CEO – can see what you’re working on and what’s getting accomplished. It’s easy to show that you’re doing some real work.

As a manager, almost all of your work is done behind the scenes. As a result, being a manager becomes this “out of sight, out of mind” thing where some people will perceive you as doing very little work. This is because when I talk to an employee about their communication style and issues they’re having interacting with others, I do it privately. It’s not as if I can send a status report e-mail to the team that says “I had a chat with Person about their communication issues, high fives everyone!” As a result, nobody other than the person I talked with directly knows that the interaction happened. Thus, to others, it might appear that I never addressed the issue.

The way that a manager shows that they’re doing work is in observable team member improvements. It’s a slow process (like many things management), but it will become obvious that you’re doing good work when the team starts to notice that Person is interacting in generally more positive ways, or on time for work more often. As your people grow and develop, your team will become stronger and more effective; people may remark on your team’s positive changes as well.

Ultimately, your success is the success of others

If you’re in it for the praise, you’re gonna have a bad time. Management is about trust, having direct and sometimes difficult conversations, and doing your work behind the scenes but in direct and fair ways. It’s a very empowering, challenging, and rewarding job that I’m enjoying immensely.

One of my favourite quotes from Futurama was pretty much written for managers, so I’ll leave you with this:

“When you do things right, people won’t be sure you’ve done anything at all.”

Developers Shouldn’t Measure Twice, Cut Once

I was working on my fireplace this past weekend. Specifically I had just finished ripping down the old surface to the red brick, and then preparing the brick surface with a layer of thinset for tiling. I spent all of Saturday cutting tiles and then placing them on the fireplace surround and hearth. Even with help it took 11 hours to do, and about 8 hours of it was measuring and cutting tiles.

While I was doing this work, which is just mindless enough that your mind wanders but requires just enough attention that it doesn’t wander freely, I began to recite a common trades mantra. Measure twice, cut once.

This quip – a practical saying – saturates the construction industry. Whether you’re a DIYer like me, or a professional tradesperson, it’s important to measure everything twice and do the work once. This saves you a lot of pain and time down the road, since you can double check your angles and distances and get everything right the first time.

The reason that this practice is important is as simple as considering a tile. Let’s say that I need a 3/4″ width tile, but I measure incorrectly and cut it to 1/2″. There’s no way for me to turn that 1/2″ piece back into a 3/4″ piece, so I just wasted that tile. I need to toss it out (if it can’t be used elsewhere) and cut a new tile to the correct measurement. In short, measuring twice saves you time and money.

As I stood above my trusty wet saw, cutting tile, after tile, after tile, my mind began to wander into the realm of programming. I began to realize something interesting. In my opinion, many IT departments have a policy of measuring twice and cutting once, with the supposed benefit of cost and time savings. One might even call this sort of approach waterfall or agile, where estimates are gathered in detail (measured) long before the work is done (cut).

I believe that this is a fallacy that ironically leads to even more work. Every single developer that I’ve ever met in my career, including myself, cannot accurately estimate anything. We sometimes get close, because we can relate the task at hand to a similar task we accomplished previously, but in general I find that a new task is very much an unknown and the time spent to gather an estimate is pointless since it’s wrong anyway. By measuring twice and cutting once, we waste a ton of time.

I believe that developers should measure once, quickly, for a rough estimate, and then cut. The reason that I believe this is due to a fundamental difference between programming and other kinds of work that is managed with processes and estimates.

Code is not a tile or piece of wood. It is a highly flexible, malleable, mutable, digital thing. If a developer cuts a feature short, they can add on to it later, expanding it seamlessly to the required size. If they overestimate a feature’s length, they can easily chop off the excess and move on to the next feature. There is no significant cost in quick, roughly estimated measurements for programming work.

Immediately your team will regain a ton of time in which they can do their development work. They won’t have to attend hours of planning meetings or requirements gathering sessions. They will just work to get things done as fast and accurately as they can.

The only tradeoff is a lack of estimates that management-types can cite and depend on. I would challenge that any estimates derived are very commonly wrong and useless regardless. More-so, if you do not trust your developers to do the right thing and use their time effectively, why do you keep them employed?

To me, a lot of the process models around development that are popular (waterfall, agile) are derived from the measure twice, cut once methodology. This approach is super practical to physical goods since inaccurate measurements are expensive, but this does not apply to development work. These meetings to gather estimates in the hopes of controlling costs ironically bloat budgets and help to deliver less code and extend goal dates and deadlines. You take people that are hired to code, and tie them up in meetings where they have to try and justify what they’re going to code by the hour. They don’t know how long it will take, but they will have a better idea after a few hours of coding – if you’d just give them a few hours of no meetings to code.

If you’re working on tiling your fireplace, measure twice and cut once. If you’re working on code, take a rough guess at the measurement and get to work!

On Secretly Terrible Engineers – A Rebuttal

Today an article was brought to my attention. One that, at the time of writing this post, had hit the front page of various sites (including Hacker News) and had been shared over 2,600 times. The article is On Secretly Terrible Engineers, which is a criticism of the tech industry and the mentality which it holds towards hiring both new and experienced developers/engineers.

Spoiler: I strongly disagree with most of this article. If you aren’t open to debates and discussion, quit reading here and return to your normal activities.

Note: any and all bolding or emphasis will be entirely my own and not present in the original article. If you see bold, know that I bolded it.

If you’re still with me, I’d like to tackle this article inline because educated context, which is what I feel the article lacks in the first place, makes the world go ’round. Let’s begin with the credentials and qualifications from which the author speaks.

I am not unbiased here, having gone through this process myself. I started programming in second grade. I wrote tens of thousands of lines of code in high school, programming games and my own web server. I got a Mathematical and Computational Science degree from Stanford and continued coding. I should have been a software developer, but after a series of interviews, I realized the field was never for me. So much hostility, so little love.

I want to make my first criticism the most important: the author has never been a professional programmer drawing a paycheck. Yet, the entire article is about how the world of professional programming works, and how it’s broken. I liken this to me getting a law degree and then, after a few interviews at firms that happened to have mediocre or bad hiring practices, writing an op-ed about how the legal industry is broken and law firms and their lawyers are all cold, heartless entities that are not welcoming to job applicants.

The fact that the author earned a Computer Science degree from Stanford is impressive. Unfortunately, as many people who program full-time have realized, most theoretical knowledge gained in school translates very poorly to real world programming. I would venture out and say that the author probably was not a very good programmer when they were fresh out of school, looking for that first job. I say that because for the most part, none of us were. I certainly thought I knew how to program when I graduated, but in reality I was a terrible programmer – arguably even “net negative” (creating more problems than I solved) due to my ego and blind confidence.

They lurk, unnoticed in the great halls of engineering that are the office strips along Highway 101. “Programmers” not programmers, people who have cheated, stolen, and lied their way through engineering careers without anyone realizing they can’t code. They are among us, incompetent Cylons secretly plotting to undermine us at a crucial time.

What is this “us” that the author speaks of? There’s a reason I put the author’s credentials (which are at the bottom of the original article) at the top of this one. The author does not work in this field. There is no “us” – the author should have said “you” but knew it would be accusatory instead of an empathic opener that developers and engineers could relate to.

Secretly terrible engineers (STEs) are everywhere, and they may be on your very team as we speak.

There is only one way to stop this scourge, one interview to defeat them all. Well, more like a dozen interviews with white boards, but that doesn’t sound nearly as cool. But I digress. One interview to rat these jackals out, to prove just once that no matter how much you did in the past, you will be discovered as the Person Who Doesn’t Know The Big-O Of Trie Insertion.

The interviewer, preparing for this moment for years while waiting for git pushes, stands up and stabs his finger at the interviewee. “I’ve got you!”

I would not hire a candidate based on a pop-quiz style test. A company that I used to work at did this, and it sucked. We ended up hiring a bunch of the “secretly terrible engineers” or STEs as the author puts it. This is because a pop-quiz test can be studied for; it tests your ability to memorize and repeat, not your ability to comprehend. People would fool us into believing that they were skilled developers by reciting the correct answers to us. Within a few weeks of working at the company, they had usually outed themselves as terrible. Needing basic instructions on for-loops, source control, or even that pesky Trie Insertion that you seem to mock as if it were not a part of the daily job for many of us (ever built a type-ahead or autocomplete system?). It’s O(n) where n is the length of the key being inserted, by the way. I didn’t have to look that up because it isn’t trivia knowledge. It was derived easily from my practical understanding of data structures and algorithms.

The interviewer is not preparing for years to out the candidate, and certainly does not make a theatrical show of it. This is because for every 200 candidates that we (proverbial) interview, 199 can’t code. It gets really depressing and morale-depriving to constantly be rejecting candidates. We find no joy in it. It may feel like you were “outed” or a scene was made because you were unable to pass the interview, and this is very emotional for and personal to you, but on our end it’s just disappointing. We really liked your personality and attitude, and we’re frustrated that we cannot hire you and work with you. The only thing that stands between you and the job is core competency, which you lack.

Or, at least, I guess that is how this moment is supposed to go, since it never seems to actually happen.

How would the author know? They don’t work in the field and they likely don’t hire developers. If they did, I think they’d have written an entirely different article. The author’s evidence so far is entirely anecdotal and surely suffers from sample bias.

But there is also a darker vein running through these articles, of how to see through the posers and fakes, of how to test engineering skills so that you don’t hire that STE. In this view, the world is swimming in pure engineering mediocrity, and only extraordinarily careful interviewing will allow you to distinguish between fraud and genius.

It’s a paranoid fantasy, a As don’t hire Bs bullshit lie.

I agree with the first paragraph. It sucks, but it’s important to carefully screen candidates and hire the right developer. A bad hire costs more than you’d probably ever guess. It is true in my subjective experience that careful interviewing is the key to distinguishing between a fraud and a genius. Pop-quiz style interviews don’t weed frauds out. Only an interview that tests basic coding proficiency can weed them out.

As for the paranoid fantasy bit, I’d ask again how the author knows this, based on their lack of experience in the field. Also, what a sensational, angry comment!

The reality is, few professions seem so openly hostile to their current members as software engineering. There is always this lingering caution when interviewing a new candidate that somehow this individual has gotten through every interview process and team review without anyone realizing the incompetence before them. Founders swap stories of “that one guy” who somehow managed to work on infrastructure at Facebook, but was a complete idiot.

I agree. The industry is cold and unforgiving to most candidates. I consider myself a very talented developer, but that didn’t stop me from going through 6 interviews, 4 of which involved coding in order to land a job at Stack Exchange. I did it willingly because I knew that anyone that I would work with also passed those tests and is a competent developer. In reality, my coworkers are all brilliant (or geniuses, as the author says). I’m lucky to be on such a talented team. This is why these practical code tests are important: they ensure that your hires are skilled and that you get the best bang for your buck (the “10x developer” as the author puts it).

As for “that one guy,” he exists. As a start-up grows, they experience growing pains. Sometimes this is a rapid in-flux of hires to accommodate some scale issues or immediate need. Part of the growing pains is learning to weed out the fraud “developers” also, and so this person tends to get in before the interview process is solidified. Once hired, it is very hard to get rid of an employee (and it costs a lot too), so that one guy at Facebook slipped by. He got in as Facebook experienced growing pains, and slipped by the not-yet-solidified interviewing process. Most of us have worked with at least one of these people recently if not multiple times throughout our careers.

I’ve always been curious what all these people have been up to in the Valley. Where do they go all day? What do they do? If we are so surrounded by lackluster talent, how do we build all of these companies that seem to be taking over the world? Are STEs secretly burrowing owls who transform into humans during engineering interviews?

In all my years immersed in the tech industry, I have never once heard a firm talk about the idiots lurking in their own offices. They always seem to be elsewhere. For everyone.

If you made 7 bad hires and 3 good (or “10x” as the author stated) hires, you’ll likely get the work done. The 3 good developers probably won’t love their jobs (because they’re picking up the slack of the other 7, and in doing so hiding the 7 from the peering eyes of management). Your company culture will also suck, but the work will get done.

No firm is going to willingly talk negatively about their employees, especially when they’re seeking or have received funding and extra especially to someone who writes for TechCrunch. That would be asking for trouble. But hey, the author’s experience can dictate their entire view of the industry if they’d like it to.

Despite the worst talent crunch that Silicon Valley has ever experienced, we still regularly throw away huge groups of talent for not perfectly answering the latest hip algorithm question. “What do you think of the latest RB-tree research,” your interlocutor asks. “What?” “Buzz! Fail. Or should I say Fizz? Dammit I lost track,” you barely hear as security walks you in shame out of the office.

Here we agree: this is a terrible hiring practice. Pop-quiz interviews are pointless as they don’t accomplish anything and don’t filter out bad candidates. If this is an experience that the author has had, it becomes clearer to me why they wrote this article.

Yet in engineering, we expect people to do live engineering on a white board under stressful interview conditions because, well, because that is what we have always done. Most programmers need StackOverflow, Google search, or Dash in order to be effective, yet you get to an interview and are expected to spontaneously remember the positional arguments for some esoteric function. And we keep doing this even with people who have years of experience in the field!

As prior discussed, these types of interviews are terrible. They accomplish nothing other than a round of FizzBuzzword Bingo, and make the candidate feel stupid or bad. I deplore these companies. Read my prior blog posts for better ways to hire good candidates.

Yet, we don’t make the same assumptions in Silicon Valley. You can work at Facebook or Google for years, and still start over from scratch with FizzBuzz when you start searching for another job. That is complete paranoia. Nerds are frankly very nervous about status, which Paul Graham argues comes straight from high school. I am not as convinced by such pop sociology, but there is something in the culture that is making us seek out and destroy those losers on our group projects that can’t carry their own weight.

There are definitely elitist engineers; most of them are misguided. The industry is certainly full of egos. I’ve met enterprise architects that couldn’t architect their way out of a cardbox board, and junior developers who think that they are experts who know everything. It’s definitely a problem, and makes the industry seem harsh to newcomers.

No, but we only realize this when we consider the real context of how engineering happens today. We still act in interviews as if every engineer works independently, when in fact teams greatly affect the performance of every contributor. We act as if engineers should have the entirety of Python’s standard library memorized, when in reality we all use the API reference docs. Take an engineer and remove their team, their search engine, and StackOverflow, and yes, they might look completely incompetent. That’s a fault of the interview, not them.

Actually, that’s the fault of the candidate. If you ever interview with Stack Overflow, we will test your coding skills in a way that prevents you from looking up the answer or depending on libraries. This is not to make the challenge extra hard; it’s quite the opposite. We believe that libraries and helper functions abstract away the true complexity and importance of code. Many developers can sling code from libraries all day (think LINQ or jQuery), but the ones that understand the computational complexity of what they’re doing under the hood are the ones that I want to work with.

If a candidate cannot solve a relatively simple (or even moderate) programming problem without the help of documentation and libraries, then they do not know how to code.

We need to move beyond the algorithm bravado to engage more fundamentally with the craft. If people are wired for engineering logic and have programmed in some capacity in the past, they almost certainly can get up to speed in any other part of the field. Let them learn, or even better, help them learn.

Agreed, fully.

No one ever offered me a book. No one even offered advice, or suggestions on what was interesting in the field or what was not. No one ever said, “Here is how we are going to bring your skills to the next level and ensure you will be quickly productive on our team.” The only answer I ever got was, “We expect every employee to be ready on day one.” What a scary proposition! Even McDonalds doesn’t expect its burger flippers to be ready from day one.

This is the saddest part of the article to me, as it reveals the true experiences of the author.

I believe that empowering developers is how you bring out the best in them and get things done. This involves mentoring in positive ways: offering and suggesting books (countless devs have loaned me books over the years), offering advice (also countless), and suggestions and talk of what’s hot in the field. It makes me angry at the industry that the author had this experience, and I agree fully that it’s bullshit and needs fixing.

As ambassadors to future developers and engineers, we should be more welcoming and willing to teach. If the candidate has the right attitude and aptitude, they can learn – quickly. I leave you with this: while I disagree with the author on many of their points, this one is at the crux of the problems in the IT industry.

The Recruiting Competitive Advantage

Let’s say you were walking down a street one day and noticed an ad for help wanted. It is posted in the window of a bakery. It reads:

Need a baker for FT work. Must be familiar with modern baking methods such as ovens, barbecuing, and deep fryers. 5+ years experience with the Super 6 commercial baking oven required (aside: came out in 2014). Nice to haves include experience with butcher’s blocks, chopping meat, and making candles.

Given that most of us understand the high-level job of a baker pretty well, it’s easy to see how totally ridiculous this job listing is. Let’s break it down:

Need a baker for FT work.

Doesn’t say too much, but it makes sense and describes your need accurately.

Must be familiar with modern baking methods such as ovens, barbecuing, and deep fryers.

Most bakers would be familiar with ovens, but no baker in their right mind would ever “bake” with a barbecue or deep fryer. At this point we begin to question whether or not this bakery has any idea of what it’s doing at all.

5+ years experience with the Super 6 commercial baking oven required (aside: came out in 2014).

Well, they want me to have 5 years of experience (or more) with an oven that has existed for only 1 year? That’s just silly. Now I think that they’re sort of out to lunch and don’t really want to work here.

Nice to haves include experience with butcher’s blocks, chopping meat, and making candles.

A baker is a very specialized position. There’s rarely going to be one who has specialized in not just baking but also butchery and candlestick making (catch my sly joke there?). A place asking for all 3 is really asking for 1 person to do 3 jobs for the price of 1 job. This isn’t fair and further dissuades the candidate.

This job posting sounds funny because it’s plain to see just how insanely off-kilter it is. However, recruiters are out there right now posting tech job listings that are just as ludicrous. The problem is that they haven’t bothered to learn much about the field that their job is focused around. So, they end up sounding as silly as the bakery owner does above.

Recruiters: this is how silly you sound to developers when you post a listing full of jargon that you don’t understand. Most of us don’t want to ever work on both C# and Java at the same time, and the odds of finding both an iOS and Android pro in one human being are slim-to-none.

All that is required for a recruiter to gain a significant competitive advantage over their peers is a little knowledge. Knowledge that could be learned in weeks. Knowledge of a standard tech stack, and the ability to Google technical acronyms like MVC and EF when they show up. If you just took a little time to make sure that your job listing was not a walking contradiction – full of statements that counter each other, technologies that don’t work together, and demanding 5+ years of experience on things that have existed for less than 2 years – you’d have a huge leg up on your peers.

Developers are rational, logical people. We will engage in the jobs that make sense. If your listing is irrational or illogical, we will avoid you like the plague. We will also make fun of your job listing to our friends, especially when you spammed e-mailed us with it directly.

So, if you’re a recruiter reading this, and you want to get ahead, it’s very simple. Learn the tech that your listing is based around at a high level (in my opinion a basic proficiency of your profession), or failing that, consult a developer to make sure that your listing doesn’t sound crazy!

On Credentialism In Software Development

We’re just two days from a brand new year and yet the primary measurement of a developer’s skill seems to be the same as it was 20 years ago. The most important classification to most companies is job title, as I talked about in great detail in my last post. The job title is acquired via working for a veritable slough of credentialist companies whose HR departments break it down very simply:

  • You’re a Junior Developer if you have 0-2 years of professional experience
  • You’re a Developer if you have 2-5 years of professional experience
  • You’re a Senior Developer if you have 5+ years of professional experience
  • You’re a Team Lead, Architect, or Manager once someone promotes you from Senior Developer

The problem with this sort of classification is obvious. The truth is that one person has 10 years of development experience, and the person standing next to her has 1 year of development experience repeated 10 times. The people that end up in the latter category tend to be “company [wo]men” – the ones who stick with a job forever and never try something new.

I am not one to believe that rockstar developers are valuable. As Scott Hanselman writes, rockstar developers do much more harm than good. I do, however, believe that the proper classification of developer skill lies in my paraphrasing of Nate Waddoups’ description:

  • A Junior Developer creates complex solutions to simple problems. You see these people across all companies and in all kinds of positions: from Junior Developer to CIO. They take a one-off batch service that processes requests and make it into a 40 class, 2000 line monster that involves a ServiceFactoryFactory and a ServiceDecorator.
  • A Developer creates simple solutions to simple problems. They’ve gotten past the pattern-itis and realize (for the most part) when to use design patterns, and when to just write simple code that works. These people tend to write the batch service in 100 lines and it works correctly 99% of the time (and is easy to maintain too).
  • A Senior Developer creates simple solutions to complex problems. These people have begun to truly master the art of software development and can whip up a highly scalable e-commerce app in fewer assemblies, classes, and lines than most of us would have used to create “Hello World” as a Junior Developer. They would be incredible role models if only they’d drop the ego.
  • A Truly Exceptional Developer is a rare thing. They don’t just make complex problems simple – they make complex problems disappear entirely. These people wield code like I imagine ancient Samurai wielded the blade: with great precision and skill. They dropped their ego years ago. In doing so, they empowered themselves to continue to learn from others which ultimately caused them to excel far beyond their Senior Developer peers. They are incredible role models and all around must-haves on any high performance team. They love to teach as much as they love to learn.

Notice that I never gave a time frame to any of these levels of skill. I don’t believe that 1 Truly Exceptional Developer can be faster than 10 Senior Developers. I do believe that in the long run they save you 10x your time and money. They write extremely maintainable code which has few bugs and even fewer scaling issues. They can quickly learn and do anything asked of them. They are truly versatile and efficient.

What would be required for companies to finally start hiring based on skill as opposed to credentialism? The reality is that some already do. To hire skill takes nothing more than ignoring the number of years of experience written on paper and simply administering a few code tests to a candidate that appears to have the desired personality traits. These tests should be moderately difficult and focus on a problem that has many answers – only a few of which are good.

A great example (though well known at this point) is the FizzBuzz test:

Write a program that counts from 1 to 100. If the current count is evenly divisible by 3, output “Fizz”. If the current count is evenly divisible by 5, output “Buzz”. If the current count is evenly divisible by both 3 and 5, output “FizzBuzz”. Otherwise, just output the current count.

This task is fairly simple but has many solutions – only a few of which are good. In tasking a candidate to complete FizzBuzz, their skill (or lack thereof) will show itself immediately:

  • The Junior Developer will write a whole ton of if statements, possibly even hard-coding all of the multiples. This section of code is probably in its own class, injected via the constructor and provided by the DivisorCounterFactory. Also, there will be as many lines of comments as there are code.
    // Count to 100
    for (int i = 1; i <= 100; i++)
        if (i == 15 || i == 30 
            || i == 45 || i == 60...)
            // Write "FizzBuzz" to the console
        else if (i == 3 || i == 6 
            || i == 9 || i == 12...)
            // Write "Fizz" to the console
        else if (i == 5 || i == 10 
            || i == 15 || i == 20...)
            // Write "Buzz" to the console
            // Write current count to the console

    This is not a very scalable way to solve the problem.

  • The Developer will whip together a few if statements using modulus to solve the problem.
    for (int i = 1; i <= 100; i++)
        if (i % 3 == 0 && i % 5 ==0)
        else if (i % 3 == 0)
        else if (i % 5 == 0)

    Decent solution, fairly simple and by-the-book answer.

  • The Senior Developer will realize that they can combine the statements.
    for (int i = 1; i <= 100; i++)
        string result = "";
        if (i % 3 == 0)
            result += "Fizz";
        if (i % 5 == 0)
            result += "Buzz";
        Console.WriteLine(result.Length > 0 ? result : i.ToString());

    Clean, simple code that takes up maybe 10 lines when you get rid of my Allman style code indentation. Then, if the ego remains, they’ll ask you why you make developers jump through interview hoops, and possibly berate you for wasting their precious time and skills on such a remedial task.

  • The Truly Exceptional Developer, having never before heard of the FizzBuzz problem, will write the Senior Developer solution in a matter of 2 or 3 minutes. They’ll then discuss the ways in which it could possibly be improved. Things like how a case statement might technically be faster than an if statement in some cases due to omitting an op code at the assembly level, or how to optimize appending immutable strings together in order to avoid creating additional objects which would later have to be garbage collected. They’ll thoroughly enjoy the problem and be enthusiastic in the discussion.

A 30 minute code test immediately gives you more insight into the candidate’s skill than a whole day of discussions ever could. You can proceed to hiring with confidence (perhaps after a few more code tests administered by different people in order to observe the candidate’s ability to work with others). You can also reject a candidate with confidence. No matter how good of a salesperson they are, they will not be able to talk their way past the code test.

In summary, my unsolicited advice to you is this: if you want to work with good developers, just reject any interview process or job offer that doesn’t involve a code test. A lack of code testing means that all manners of developer will slip through that company’s hiring process (including those at the very low end of the bell curve) and that they will be your coworkers.

Via this hiring approach, you’ll meet Junior Developers with 25 years of experience, and Truly Exceptional Developers fresh out of school – and everything else in between.

Doesn’t it seem obvious that we should be tested on our coding skills, given that coding is literally the primary task that we are hired to do for 40+ hours a week? Do you think that a hospital would hire a surgeon without testing their skills? Would the NFL or NHL recruit a player without testing their skills (or at least seeing their skills in action)?

In all professions, the top tiers test their candidates for practical skills. This filters out the unskilled, resulting in awesome teams of incredibly skilled people. These are the teams we want to be on. These are the companies we want to work for. These are the environments in which we learn and become Truly Exceptional Developers.

PS – I hope that you had a terrific Christmas and will have a Happy New Year!

The Trouble With Job Titles

I’ve had a good career so far. I began working full-time as a programmer in 2008. At that time my title was Junior Developer. I had a decent boss and cool co-workers, and I cut my teeth on Java and .NET. It was a good experience. After 2 years at that gig, I felt that it was time to move on.

I contacted recruiters, and one eventually found me a promotion: Systems Analyst. It came with a decent pay bump and so forth, as well as the luxury of dropping “Junior” from my job title. As this was a good deal all around, I took the offer.

A few more years went by and I found myself once again looking for “the next step” in my career. Lo-and-behold my current company had appreciated my skill as a Systems Analyst and wanted to bring me on as a Developer. Before I knew it I was a .NET Developer which, as my other job changes had previously, came with a pay raise and better perks. Things were going great.

I did 3 years total with this company, during which I was promoted to .NET Development Team Lead – a terrific title in the realm of programming. I ran a small team of 4-5 people and things were going pretty well.

Eventually, having maxed out my skills and knowledge at this company, I moved on. I became a .NET Architect with appropriate pay and benefits. It was a reasonable gig.

This is where I’ll introduce a sideline fact: during my entire career to this point, recruiters (both in-house and third-party) had been cold-calling and contacting me with jobs that matched my current title (with more contact as I got further in my career). As a .NET Development Team Lead, I was offered jobs that ranged from Senior Developer to Team Lead to Architect. As a .NET Architect, I was offered titles from Team Lead to Architect to Manager. So far things made sense.

About 5 months ago I took a job with a company that I love, Stack Exchange. Things are going great so far, and I’ve never been treated better in my entire development career. My pay and benefits are top-notch, my job perks are incredible, and my boss is a genuinely competent, solid human being – as are all of my co-workers. It is the current high-bar of my career track record.

Where it becomes interesting is in my job title. At Stack Exchange I am a Web Developer. That’s the whole title. Not Manager, or Team Lead, or Architect, but Web Developer. The reason for this is that Stack Exchange is not a company that cares for credentialism. We hire smart people who gets things done (their words, not mine) and developers here handle projects from start to finish. This means that we sometimes act as a Manager of others, sometimes a Team Lead of others, and often an Architect as we discuss and debate the best way to solve a particular problem or design a particular system.

It was not until I got this job that I realized how broken the current recruiting industry is. Just 6 months ago I was receiving cold calls and offers to interview for Team Lead, Architect, and Manager jobs (with expected pay). Can you guess what jobs they contact me with these days?

Junior Developer and Intermediate Developer. Complete with massive pay and benefits cut. Offering these positions to me is a complete waste of both my time and the recruiter’s.

It’s pretty obvious why this happens: recruiters are usually not contacting me personally based on researching my career and goals. They are contacting me as 1 of 10-50 others that they will contact via cold-call or e-mail on any given day. A shotgun approach of “fire it off and see what hits” as it were.

I am certainly not egotistical enough to be offended by being offered titles and pay well below my current skill set. What does bother me, however, is the fact that I cannot convince most recruiters of anything otherwise. I took it upon myself to explain to one recruiter that Web Developer at Stack Exchange is about the equivalent (in my opinion) of a Team Lead or Architect at many other companies. Their response was that if that were true, it would be my title here. I was dumbfounded.

Given that there are no current standards for developer titles, it is plain to see that a Developer at Company A could be anything from a Junior Developer to CIO at Company B. It’s a crap shoot. Especially when you consider the fact that some companies inflate the titles of their employees as a “free” form of making them feel valued (as opposed to, say, paying them properly).

I don’t know what the solution is to the recruiting industry’s problem, but it does make me realize the value of Stack Overflow Careers. We match candidates with jobs based on experience, interests, and open source projects, not via titles and credentialism. We explicitly ban companies that spam candidates with a job offering. This means that every single message written to you as a candidate is personalized and written by hand by the recruiter. Very few recruiting companies can claim similarly. We continue to evolve this product, and I hope that one day it sets a new standard for recruiting where people don’t blindly call you up with jobs that match your current title.

This lack of standards is a difficult problem to solve. I don’t pretend that I have the answers. It does show me precisely how you end up working with incompetent people though.

John Doe is an incompetent developer who works for a small dev shop that gives him low pay but a big title such as Senior Developer. A recruiter eventually offers this developer jobs of a similar title but that have the appropriate pay. John jumps at the giant raise and heads to the next company. What happens next is something we’ve surely all seen a few times… John can’t hack it, John gets 3-6 months in and gets let go. John was cheated by the system of credentialism. Who can blame him directly for grabbing the highest value offering he can get? We all would.

This broken system wastes time, tons of money, and screws up company culture. Nobody likes working with John as a peer when he knows 1/10th of what they do, does even less work, and gets paid the same or better. That causes your good developers to run for the hills, and your workplace culture to suck as another John fills the now open role of a good dev.

The current state of the recruiting industry is fairly toxic. Most recruiters will put anyone anywhere to make a buck and meet their draw or quota.

The question becomes: how do we, with Stack Overflow Careers, completely dismantle this system and rebuild it properly? Time will tell, and I’m excited to see the results.

iPhone 6: Style Over Substance

Like many of you, today I watched the Apple media event in which they announced both the iPhone 6 and Apple Watch. I’m not going to talk about the watch, but instead about the phone.

For years Apple has been a true cachet brand. They are a luxury item that is sought after for status and image. I don’t blame anyone for owning an iPhone: they’re reasonably sexy and you get to show off the Apple branding. Good on you.

My smartphone adventure started with an iPhone 3 in 2008. It was an amazing, groundbreaking piece of hardware back then. Android was nowhere near it and nothing else came close. I was able to put my iPod Nano in my dresser drawer and use the phone for both music and talk/text. It was amazingly innovative and nothing at the time compared.

This morning I was very excited to see Apple finally innovate again under the direction of Tim Cook, after years of what seems like stagnation on the mobile front. Instead, I was disappointed. I’m going to explain why in terms of comparable hardware and cost, not in terms of opinion (because they’re cheap and everybody has one).

Let’s compare the bleeding-edge Apple iPhone 6 and 6+ offering with my Nexus 5 (a phone that is nearly 1 year old and was released on Oct 31 2013). I highlight the winner in bold for each spec:

Nexus 5 iPhone 6/6+
Processor 2.26 GHz quad-core Krait 400 “Snapdragon” A8 chip specs not released, benchmarked at 1.4 GHz dual-core
RAM 2 GB Benchmarked at 1 GB
Battery 2300 mAH 6: 1810 mAH. 6+: 2900 mAH
Screen Quality 1920 x 1080, 445 pixels per inch 6: 1334 x 750, 326 pixels per inch. 6+: 1920 x 1080, 401 pixels per inch
Screen Size 5″ 6: 4.7″. 6+: 5.5″
Storage 16 GB 128 GB
Fingerprint Sensor Nope Yup
LTE Bands 6 20
Front Facing Camera 1.3 MP 3.2 MP
Rear Facing Camera 8 MP 8 MP
NFC, Bluetooth Yup Yup
Wireless 802.11ac 802.11ac
Screen Polarization/View Range Sucky Sucky
PRICE $349 for 16 GB no contract, unlocked 6: $649 for 16 GB no contract, unlocked. 6+: $749 for 16 GB no contract, unlocked

Thoughts: Apple has some better specs, but they tend to be with respect to the cheaper hardware aspects (LTE bands which are redundant anyway, storage space, front facing camera). The iPhone 6 standard model has a really poor display resolution, surprisingly, since Apple has made strides in display technology with their retina MacBook Pros and iPads. The battery on the standard iPhone 6 is also poor compared to the Nexus 5, though the 6+ gets a much larger battery with its larger size. In terms of performance (CPU/RAM), Nexus 5 dominates.

Conclusion: Apple cheaped out on this phone, big time. It BARELY competes technically with the Nexus 5, an Android phone released almost 1 year ago. I cannot believe that for the cost of 1 iPhone 6+ I can buy 2 Nexus 5’s. It truly must be a cachet phone if people are willing to pay the price for such mediocre hardware.

How I Got A Job At Stack Exchange

Almost exactly 1 month ago today I found myself on a video call with Joel Spolsky. It feels insane to write that, even now, as it was a banner moment in my career. For me it was the equivalent of meeting a movie star who I had idolized since I was old enough to know what movies were. There had always been this Joel Spolsky guy throughout my career that I regularly read about and whose opinions on software development agreed with mine, and suddenly I was talking with him face to face. It was awesome.

Reaching this conversation was not the easiest thing I’ve done in my life. It took a few weeks and in all honesty it was a bit trying to find time to have so many interviews. How many interviews, you ask? Prior to Joel I talked with 5 or 6 other amazing people (Marc Gravell and Nicholas Larsen included). Somehow I managed to impress each of them enough to reach the end boss: Joel Spolsky.

The conversation lasted about an hour. It felt like 5 minutes to me, probably because of the excitement. Joel and I discussed the pros and cons of various software methodologies, mistakes each of us had made in our careers, some of the challenges of Dache (my open source software), and a few other topics. Then he said something awesome: “We’d love for you to come and work with us at Stack Exchange!” So much adrenaline hit me at this moment that I could have lifted a car with my bare hands. It was surreal.

A few days from now I officially start working with Stack Exchange. I feel very fortunate and excited for the opportunity. So far the Stack Exchange team have proven themselves an insanely skilled and professional organization that treat employees as human beings instead of expendable resources. I’m already loving the culture and interactions with my coworkers.

IMPORTANT NOTES: First and foremost, the commentary here consists of my views alone and not those of Stack Exchange or any other entity. This post is merely to reflect upon the interview process and discuss the aspects and traits of my career and knowledge which I feel helped me get the job. This is not a tell-all or any sort of shortcut or easy way out. If you want a job at Stack Exchange, you will have to endure the same technical and soft skills challenges that I did – the details of which I will NOT be disclosing. :)

So, with that disclaimer out of the way, here are my thoughts on how I got a job at Stack Exchange, and how you can too:

Ego is the mind killer, so kill the ego. Most developers that I’ve met (including some prior versions of myself) have massive egos. Egos so big that the room can barely hold them. Egos that even put the illustrious Kanye West’s attitude to shame. This is natural given that we spend all day creating things from scratch (which is a god-like quality) that often generate significant revenue for companies. We start to feel very powerful and even fawned over. We learn the entirety of the software and hardware vertical of our current job’s domain, and then make a Superman-like flying leap to conclude that we know EVERYTHING about ALL software and hardware.

Thinking you know everything is the easiest way to suck as a programmer. If you believe that you know everything, you stop trying to learn new things (since you already know them, duh). So, while you’ve mastered ASP.NET MVC 3 at your current gig, 4 and 5 came out… the catch is that your company never upgraded because it’s too risky, and so you never learned them (or cared to). Now a year or two later you’re so far behind the current development stack that you can’t even see it with binoculars. And did I mention those little things called Ruby and PHP and even Java that you’ve never written a single line of? And how about MongoDB, Couchbase, Azure, EC2, and the literally thousands of other platforms and programming languages? I should hope that by now you realize that you know a little bit about a handful of languages and hardware configurations amidst a sea of thousands… By percentage, you’ve conquered maybe 0.1% of all that there is to know about development. So have I, and that’s OK.

Don’t be a rock star developer. This is something that I did for a few years and it only hurt my career. Many companies employ a strategy of intentionally furthering the developer ego in order to make them feel valuable (often without handing out appropriate compensation). Being a rock star sounds cool, but really it’s a nasty strategy that can cultivate incredibly destructive developer attitudes. Companies seek out and hire rock stars, and rock stars have a sense of entitlement. They develop huge egos and run their mouths at meetings, interrupting and talking over others. They seem to love circular logic (they’re right because you’re wrong because they’re right). They feel that all other team members exist simply to serve their every whim… and everyone loathes working with them.

The thing is – while you may actually be a 1 in 1 million bona fide rock star developer – nobody cares. Talk is cheap and in my experience people will say nearly anything and everything to portray an image of who they want you to believe they are. If you are really good at what you do, telling people doesn’t do anything other than make them despise you… Hearing about how amazing your proprietary code is gets annoying – especially when it’s the 5th time this week you’ve said it. A good developer doesn’t need to brag about how good they are: their work speaks louder than any boastful words could. People around them will naturally do the bragging for them. Hallway conversations to the tune of “wow, he’s really smart” or “she knocked that out in hours when we thought it’d take days” will be fostered, and that isn’t a bad thing. Let people talk about you all they’d like, but maintain a sense of humility and reality. You might be the best developer on your team or even at your company, but you are still a human being and this is still a job. Nobody has been hired to serve your ego (even if their job is to serve you). Being a good developer doesn’t make you better than anyone as a person; it just makes you successful in your career. Never lose sight of the fact that thousands of other developers are great at their jobs too. What separates you from the pack is being a great developer AND modest. It is a very rare combination in my experience, and the complete package that many companies are striving to hire. So, while it’s cool that you’re the very best developer that there ever was, stop believing your own hype and telling everyone who will listen. They don’t care, and you shouldn’t either.

Know that you know enough to know that you don’t know enough. Know what you do know, and know what you don’t know, and never be afraid to say “I don’t know” when it’s the truth. A developer who isn’t afraid to say “I don’t know” in front of a room full of people is a rare gem. By being honest you create trust and credibility. You also foster positive relationships with your peers and company. Nobody will remember that you’ve never heard of Angular.js or Couchbase, though they’ll always appreciate that you didn’t waste their time or money by pretending that you did. You can’t trust a developer who doesn’t know what they don’t know.

Know your data structures and algorithms. High level programming languages such as C# abstract so much away from the modern developer that many of us have no idea what’s actually happening “under the hood” when it executes. It’s cool that you can sling LINQ everywhere, but do you know the computational complexity of what you’ve done? Do you know what a hash table is and why it is useful? Could you sort a list of things efficiently? Can you think of a scenario where a stack is the best option? Note that you don’t need to memorize things like sorting algorithms (hell, I couldn’t if I tried), but a working knowledge of data structures such as trees, hash buckets, lists, queues, and stacks combined with the rudimentary knowledge of things like sorting, searching, and caching is a very valuable skillset. It’s the difference between a good programmer and a great one. Anyone can write C#, but only those who understand even the low level operations of each deliberate method call will write good, clean, efficient code. You owe yourself a fundamental understanding of how data structures like stacks and heaps work, as well as by-value vs by-reference memory addressing. These core concepts apply to ALL programming languages. Too many developers ignore the complexity of their algorithms and just call pre-made methods without understanding the implications. Educate yourself on data structures and algorithms and suddenly you’ll be ahead of the pack.

Know why your code works and why your code doesn’t work. Have you seen this image circulating on sites like Reddit?


Despite being funny, the popularity of this image pisses me off. It claims that the essence of programming is having no freaking clue why your code does or does not run. I feel that this is unacceptable. A great developer strives for the WHY in every single thing that they do, not just HOW to quick-fix it. Code doesn’t compile? WHY? Race condition across threads? WHY? In asking “why” you further your knowledge and expand your skillset with the functional, rational “how” which allows you to become a better programmer. Most great programmers don’t repeat the same mistakes over and over, though they of course make mistakes… They just make new and interesting ones!

I remember the days of slinging shoddy code and then copy-pasting lines from blogs and sites like Stack Overflow until my code seemed to work (though I wasn’t sure if or why it did). Those days are long behind me. When my code doesn’t compile, 99% of the time I immediately know how to fix the issue. When my code has a bug, I usually know exactly how to track it down and resolve it, and in doing so I often learn how to avoid it in the future. Having no idea why your code works is like being a lawyer who has no idea why their client is not guilty: fairly useless, overpaid, and an amusing spectacle at times. Make sure that you know why your code works and why it doesn’t. In my opinion this is a basic competency of being a professional developer. It’s OK to create bugs and make mistakes – it’s not OK to make the same mistakes repeatedly.

At this point I feel that I’ve done a reasonable job of representing my skillset and core competencies. These are the things I showed to the Stack Exchange team in my interviews. I didn’t necessarily have the exact answer (or even most efficient answer) to each of their technical questions, but I was modest and never afraid to ask for help or say “I don’t know” when I got stuck. My answers involved efficient data structures and algorithms, and I was able to explain why the data structure was the best choice in solving the problem. When I created bugs I was mostly able to identify them and indicate how to fix them. In doing all of this, I demonstrated competency and confidence as a developer and fortunately ended up with my dream job.

If you think you’ve got the chops to join us at Stack Exchange, apply today!

How To Guarantee Dev Team Failure

The Problem

I think that most devs would agree when I state that the definition of success in the corporate world of development places less emphasis on “good” code and more emphasis on “working” code. Working code is code that can be released to production on or before the deadline, regardless of performance or even bugs in most cases. As a developer, you ultimately feel as if you’ve failed when you toil for nights on end to meet steep deadlines and churn out crappy code. As a business, however, you’ve succeeded when you hit the deadline. My experience tells me that the typical metric upon which development teams are measured is often not quality of code or unit tests or even performance, but instead ability to meet deadlines and deliver solutions to clients. You’ve failed when you do not meet the deadlines and thus piss off the clients/customers. Your job has become a veritable boolean result with the outcomes of true and false. Deadline met? True. Deadline missed? False.

Doesn’t it feel awful to be measured in such a binary way? All or nothing, success or failure, deliver or delay. These are the only outcomes according to the people who write and sign your paychecks.

The Conflict

Why does this happen? A little introspective thought brings light to the subject, at least for me. The reason for these types of metrics becomes obvious when you consider their source. You work for a company who pays you (often with I.T. seen as a cost-center or “money pit”) to accomplish things which the company can then sell to clients. You’re an expensive tool by which they accomplish their means. Though these companies often see software as a profit source, they see the means by which they get the software as an expense and cost. Kind of strange, really.

The problem begins at the very core of the organization; the structure of the company is the starting point for guaranteed failure. In my experience, the dichotomy that forms in most companies is “I.T.” versus “The Business” in a bout-to-knock-the-other-guy-out. The minute you create this relationship of opposing fronts, you’ve already guaranteed development failure. With competing and contrasting goals (the business wants to sell stuff ASAP while I.T. wants to build stuff properly which takes longer) it is not possible for trust to exist within the organization. The Business will not believe a word that I.T. says when it comes to estimates, deadlines, or things that need to happen to ensure stability of the product in the future (technical debt). I.T. will not trust The Business to make rational decisions when it comes to features, development timelines and ensuring product quality. The result is a boxing match where each side is trying to force the other into compliance. Now you have conflict. Conflict dismantles good companies.

The Measurables

The Business is used to tracking their sales teams by metrics like “how many calls did you make/receive today?” and “how many sales did you make?” and “did you make X sales by Y arbitrary date?” where Y could be the end of each month. These are things that they understand, and thus like to control. Ask your favourite sales person for their opinion on the metrics by which their success is measured, and I am confident you’ll find that most will sum it up as “the faster I sell things, and the more things I sell, the more successful I am.” This makes sense from an empirical, see-the-figures-on-paper-on-my-desk-in-my-executive-office point of view, but I bet that the sales person in this case is not loving their life. A constant push to sell more, make more money, and do more. Any success in the future just raises the bar for the success which must follow. It’s a losing scenario. Eventually, they either get promoted out of the trenches of sales or they move to another company, resetting the bar which has been set too high. This buys them another year or two of raising that bar, until they ultimately repeat the process again.

Sales people who are put under the gun in such situations often resort to employing any tactic that they can to reach their goals… One of these strategies is saying anything at all to sign the client up. “Sure, the software can create rainbows and unicorns, just sign on the dotted line!” they say. It’s unfortunate, because customers who are hooked into these contracts tend to be very unhappy with the product when they find out that the software does not, in fact, create rainbows or unicorns. Or even a colour wheel and horses. It doesn’t even come close.

In the above case, The Business fails to measure the things that, long-term, make you the most money: client satisfaction and relationships. A good sales person (they definitely exist) is one that keeps the client happy with rational discussions and promises, and who is very transparent about what can and cannot be done and why. A great sales person is one the client loves so much that they’ll keep using your product, even when a better product exists, simply because they fear losing the relationship. This client is a client for life (or at least a long while) and makes you a lot of money. But how do you measure “happiness” and “relationships” long term? It’s a hard problem. Dating sites have been trying to solve it for over a decade. The Business will likely not dedicate the time and resource to do so themselves. So, they measure phone calls, sales, and other crappy metrics to ensure that the sales team are doing their job.

Here’s where we get back to the topic: developers and failure. The Business, who in most cases pays I.T. to create things to sell, employs these same arbitrary measurements when grading development teams. They often only know how to see success as a measured outcome of facts, and so they create the only measurements that they can empirically apply: features and deadlines. Does the dev team build all of the features and hit the deadline? Great. Do they not? Not great. These measurements themselves are acceptable (even good), but the combination of them (lots of features on short deadlines) is the problem.

The Money Talks

Where it gets tricky is in the realization that “show me the money” is how business ultimately tends to run. The sales people very overtly make the money, so they are seen as successful and important people in the company. The dev team also makes money, but is perceived to cost money, and they are seen as a cost-center that must be carefully weighed and measured to avoid excessive spending. What this leads to is an unhealthy practice of allowing sales people the freedom to employ any tactics necessary to land sales and make the money. In a business such as The Business as described, your life as a developer begins to suck.

To close the deal, the sales person will often promise the client almost anything about the software that you develop. They may promise new feature X by the end of the month, they may even promise 10 new features by the middle of the month. Whatever makes the client sign on. Then, the client says let’s rock and your quality of life drops sharply.

The very next thing that happens is The Business casually tries to confirm what seems obvious and even mandatory to them. “So your team will have these 10 things ready to go by the 15th, right?” they say. “This is a million dollar client, and it would be horrible if we lost them because you couldn’t deliver!” and now the pressure is on to do the nearly-impossible in virtually no time.

The dev team might try to politely push back and say that this is practically impossible, but The Business sees the dollars on the dotted line and will not listen. Flip the kill switch. Forego the QA time, all developers must focus on all of these features, day and night, so that the deadline can be met. Why? Because that’s how the team is measured. If the team doesn’t hit that deadline, they’ve failed and the million dollar deal is lost with the dev team seemingly at fault. Developers don’t want to work extra? Order in pizzas and promise them time-in-lieu as soon as the deadline is over with. Note that they will likely never actually see this time-in-lieu because right after this deadline will be the next one, with similar outlandish expectations and even tighter deadlines. And after that, another one. And another one. And the cycle will probably never end.

The Mad Production Dash

So, as the developer, you develop it as fast as you can. The code starts to resemble Frankenstein as you tack on bits and pieces to make it work ASAP. You subdue your ego and uneasiness about the quality of code by commenting // HACK: undo this crap later everywhere. Somehow that makes you feel better as it creates the slight glimmer of hope that eventually you’ll have enough time to come back and undo this monstrous pile of garbage. But you never will get that time, because the next deal is coming down the pipe. And so the code becomes worse. Your development effort completes 1-2 days before the arbitrary sales deadline, and after your QA team flips their lids on having 48 hours to test 1000+ hours of work, they do “critical path testing” to make sure it at least does something correctly and certify it as “good enough.”

The team releases to production early in the morning of the deadline day, and though it takes 5 hours because there are 17 untested things to fix on-the-fly (and realistically they have no option to abort the release or roll back because the consequences will be dire), they eventually shove the hacked up code out the door and declare it done. The Business shows their appreciation in the form of a short, impersonal e-mail that doesn’t name any person of achievement specifically. The development team is feeling underappreciated and pissed off.

What does the future hold for such a company? The code will probably spiral into bug-filled oblivion until it can’t do anything correctly or in any reasonable amount of time. Despite the weeks and months during which the development team pleaded with the business for time to clean up the technical debt, they are brushed off because taking time off of features loses clients and thus money. Then, as it starts to come crashing down in production, they suddenly beg the developers for a quick fix. “Do whatever it is that needs to be done!” they plead as they see their sales going down the drain. And now, because it is on fire and burning to the ground, the dev team is finally given a moment to pay back some of the technical debt that has been accrued during this vicious cycle. Repeat.

The Solution

When a dev team has no say in the deadlines of the work they must do, they will usually fail. And when they are set up for failure from the start, they will likely get tired of being blamed for the problems without ever being given the time to devise the solutions. This leads to bad work culture, high turnover, and low productivity.

The way to guarantee dev team success is obvious at this point. It’s really as simple as trust between I.T. and The Business. They must keep each other in the loop as stakeholders. The Business has no product without I.T. and I.T. has no job without The Business’s clients. It’s a mutually beneficial relationship and it should be treated as such, rather than mutually parasitic.

A good company’s sales team will often consult with I.T. prior to promising any dates and deadlines when unknowns are involved. It is practical to ask the people responsible for a task how long it will take them to complete a task. This is much like how you might ask a waitress how long it will take for the food to arrive or a painter how many days they need to paint your home. This is a positive and productive discussion. Hallway conversations should become commonplace: “Hey dev team, I’ve got a client who wants to sign on but not until we build X, how long will that take?” The reply is as easy as “We’ll discuss it as a team and send you an estimate with some assumptions to confirm with the client” and just like that there’s a great working relationship that practically guarantees success. The team knows what work is coming, and also knows how long they have to complete it.

The Correct Measurements

If a dev team continues to fail in an environment where trust exists, then that team is likely not competent. They either cannot estimate correctly or cannot deliver within their own estimates. Sometimes devs suck at estimating because they’ve been making estimates under the oppressive sales gun for so long that they’ve effectively forgotten how to give themselves a fair amount of time. The blame for this remains entirely on the dev team, and they (or The Business) must repair the situation quickly and effectively to maintain the mutually beneficial relationship based on trust. As The Business owes I.T. input into the deadlines, I.T. carries the burden of being fair, accurate, and responsible with those deadlines.

Assuming that The Business now has a competent, skilled dev team, the question turns to the customers. If the customers do not like the estimates given to them, this may cost the company sales. Perhaps the customer wanted the impossible and The Business is giving them a dose of reality. Perhaps The Business does not want such a needy customer and they’re in a situation to be able to afford to tell them no thanks. Perhaps The Business realizes that the client’s request is reasonable but the timeframe of the estimate feels a bit long. In that case they can ask I.T. why. If the answer is not sufficient and justifiable, then perhaps the dev team is still not competent. No dev team should be let loose without checks and measures on productivity, but those metrics should be reasonable.

Ultimately, if you want to guarantee the failure of a development team, simply promise features to clients and customers without ever asking for (or trusting) the input of the team that is actually going to build those features. It’s just like telling the waitress that your food must be on the table in 10 minutes, without first asking the cooks how long it takes to safely and properly make it.

If this situation sounds familiar, try talking with The Business about it. Try to help them see it from your point of view. Ask them “how successful would you be if I demanded that you sell 20 new clients by Friday?” and perhaps some light bulbs will start to go on. Ultimately, we as developers often know nothing about sales and have no business dictating their measurable work expectations. They similarly have no business dictating ours, but a relationship of trust can be built to allow us all to work together and accomplish great things.