In this episode, you’ll learn how to identify fake New Yorkers from real New Yorkers by simply asking, “What is Gray’s Papaya known for?” You’ll also learn how many licks it takes to get to the center of a Tootsie Roll Pop. Finally, you’ll learn a new word: Recruitersplaining.

Launching this week, Startup Or Shut Up, our new game where Joel, Jay, and David have to guess which one of three startup descriptions are fake. Spoiler: Jay gets a participation award for “trying.”

But what really grinds our gears? This week, the gang rants about awful recruiter questions and responses, specifically from Google's (alleged, possibly outdated) "Director of Engineering" hiring test, such as

Recruiter: Why is Quicksort the best sorting method? Interviewee: It's not always the case, nor even suitable. Recruiter: Quicksort has the best big-O. Interviewee: "big-O" ignores data storage latencies, topology, volume, available memory, and even the computational cost of every CPU instructions involved in a given implementation – instead, it merely counts the number of algorithmic operations! Big-O can be a valuable indication when designing algorithms but the best performing and scaling solution depends on the particular constraints of any specific problem and environment. Recruiter: Wrong, you had to give me the Quicksort big-O score.

Aside from listening to the episode, if you want to learn how to do interviews the right way, go to Joel on Software and check out The Guerilla Guide to Interviewing.

More important that interviewing, however, is our future legal system. As you all know, we’re preparing the Stack Overflow Constitution week by week, amendment by amendment in this podcast. This week’s amendment: Should you hold the door for a colleague if you know it's going to make them run? Go to Twitter and use #StackOverflowPodcast to vote Pro if you hold the door, and Con if you don’t.

Notable Links:

• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

In this episode you can learn way too much about the New York Transit Museum, the word "Stack" at Microsoft, and the etymology of Channel 9, where Joel was interviewed last week with the help of gender neutral robot cameras.

We have two new segments debuting this week:

• Introducing Stump Nick Craver! Here's how it works, we call Nick Craver (@Nick_Craver) and he will have 60 seconds to answer 5 questions about servers. If he answers all correctly, he will win a 6 month supply of Clorox Toilet Wands. As it turns out, a 6-month supply is exactly one wand.

• Developer Stories! Where we talk to developers who have cool or interesting stories to tell about how they got into computers and what they build with them. Our very first guest to tell us her developer story is the brilliant Dr. Omoju Miller (@OmojuMiller), a data scientist who is interested in data-driven, machine learning approaches to solving business problems. In discussing one of her blog posts that Jay was particularly struck by, she says:

"I am the kind of person that had a very different, non-stereotypical upbringing. I had toys that were not gender specific. I had planes that I could fly down the street... I had robotic little rats… I had Legos, I had Barbies, I had Easy-Bake Oven… In our house when we were playing it was like we were building worlds. So you had to do the engineering to figure out how to build your building, you had to figure out what was going to be your power generation supply. After you built the house, you had to figure out what you were going to eat, what you were going to wear... It was a very holistic thing. Maybe because of that kind upbringing I have the ability to imagine worlds that don’t exist and just invent them. However, for a lot of people they’re bound in their imagination by what they’ve seen. And a lot of the ways in which we consume knowledge about who we can be is actually true media. If you keep on seeing images that don’t reflect a certain gamut of who you can be, then you have a very narrow view of what you think you can actually do in the world, especially when it comes to technical professions.”

For this week’s installment of building Stack Overflow’s Constitution, our hosts ask the controversial question, “Are you allowed to stand over the IT person while you wait for them to reset your password?”

Listen as our hosts talk it over and then tweet to us using #StackOverflowPodcast: PRO if you think that you should be able to stand over them and wait, or CON if you think that you should go back to your desk and wait for them to notify you. The best explanation, whether you are on the winning or losing side, will be read next week on air as well as win a fabulous Stack Overflow sticker and no Clorox Toilet Brushes.

Last week's winner for the question, "When you are at the supermarket, should you be able to eat an item BEFORE you get to the cash register?" is:

"Pro, the only problem is fitting on the scales after snacking by the bulk bins. #StackOverflowPodcast" - Jonathan Lisic, @jlisic

Congrats Jonathan, you win a thing!

See you next week!

Notable Links:

• Developer Story: s.tk/story
• Backchannel.com on Medium
• Stack Overflow Salary Calculator, now with International flavor!
• Le.Taxi info. (Editor's note: We are really, really sorry about the bad accents in this segment.]
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

In this episode: Rant Soup™, now with Trello! If you would like to make your own Trello board of rants, or soup, go to Trello.com. Also, according to Joel, Jay is still not getting a raise. (Don't worry buddy, you'll get there someday…)

Today's special guest, calling in from not-so-sunny London, is Stack Overflow PM Kit Karrau. Kit is the driving force behind our new product, the Developer Story, launching today. Developer Story shows what you’ve built, not just where you’ve worked or went to school. It’s your story; tell it your way. Go to s.tk/story to create yours now.

As part of our favorite story about a developer in this week’s episode, we learn that Joel's hands are very small in a certain photo on a certain website (so you should definitely NOT go there right now to point and laugh).

In the News this week, the gang finds out that developers rant the most about product managers, and that AI is going to put tax preparers out of business.

It's also the third week of the Stack Overflow Constitution. Vote on this week's amendment: When you are at the supermarket, should you be able to eat an item BEFORE you get to the cash register? Listen to our hosts' points of view and then tweet to us using #StackOverflowPodcast: PRO if you think that you SHOULD be able to eat it before you leave the store (and pay for it at the register using the wrapper), and CON if you think that you SHOULD NOT, along with a brief explanation. The best answer will be read on the air next week, and by best, we mean which one made us chuckle the most.

Last week's winner is Michael Berkowski with a great tweet story culminating with:

"My request was denied, so I got to learn a little French instead #StackOverflowPodcast" - Michael Berkowski, @mberkowski 9:33 AM - 3 Oct 2016

See you next week!

Notable Links:

• Developer Story: s.tk/story
• Devrant: https://www.devrant.io/
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

It’s your story; tell it your way.

Get yours today at s.tk/story. It only takes a few minutes, and you do NOT want some other joker snapping up the good URLs. Take it from me, stackoverflow/story/J@yH@n10n.

Technology has evolved. Tech resumes? Not so much.

The resume was invented by Da Vinci in the 15th century. It mostly served as a letter of introduction for traveling lords… and it hasn’t changed much since. What do you see when you scan the bold stuff on a resume? Employers, job titles, schools, and degrees. And a lot of small bullets. Plus maybe an other-stuff-intended-to-round-me-out-as-an-actual-human section at the bottom.

In the roughly five centuries since resumes were created to help nobility vouch for roadbound gentry, they’ve stayed mostly optimized for one thing: conveying the importance of your pedigree.

The emphasis is all on the seniority of your titles and how impressive your companies or schools have been. Which is a great way for some developers to put their best foot forward. Have a Masters in CS from Yalemouth? Cool! That’s one good signal. But it ain't the only one. Heck, even politicians know that fancy schools are only one of many ways to signal potential:

“It turns out it doesn’t matter where you learned code, it just matters how good you are at writing code.” — President Barack Obama

Show, don’t just tell.

Developers, fundamentally, are makers. Like designers… or architects… or jugglers! You wouldn’t hire any of them based on a list of titles or places they’d worked. ("Oh, a Senior Associate Juggler? Get her! I bet she can do those flaming sticks and stuff!") So why hire a developer that way? Makers' skills are conveyed by showing, not telling. Portfolios. Blueprints. This awesome juggling video.

Be more than bullets: Your best work, front and center.

The Developer Story lets you share what you've worked on by linking to actual features you’ve worked on, blog posts, or public code. Those things shouldn’t be described in the second clause of a tiny bullet, or relegated to the “Other interests” section of a resume, to sit unassumingly next to your second-place trophy in intramural tetherball.

The Developer Story puts the work you’re most proud of where it belongs: at the grownup table, right alongside your roles or schools.

No reputation points? No problem. Posting answers or contributing to Documentation is one way to build up public artifacts of your coding experience, but it’s not the only way. Your Developer Story lets you show off whatever you work on. So you’ll look good, no matter how much rep you have on Stack Overflow.

Find a job you'll love, on your terms.

If you’re ready for your next challenge, the Developer Story makes it easy to learn about jobs that fit your personal criteria. And since developers are in demand, we know it’s not about finding a job — it’s about finding the right job. The same way Stack Overflow Q&A put the right answer right on top, when you fill out your profile, Stack Overflow Jobs shows you roles that match the technology or projects you want to work on. (Even if they’re not what you’re using today.) And we always puts the developer in control. No spam, no BS. (Did you know that Stack Overflow Jobs actually penalizes blind messaging by employers?)

And it's 100% backwards-compatible with those crusty old resumes - it can still highlight fancy schools and fancy titles, and anything else you'd include on a traditional resume. So if you're like me, and still just a little proud that you got off the waitlist and eked your way into a school above your intellectual weight class, you can still show off your alma mater off with pride.

But don’t employers just want role, schools, and keywords? Nope. It turns out that they’ve just accepted that that’s all that they can generally get from a resume, leaving them stuck using “seven vs. eight years of JavaScript experience” to determine whom to interview. The employers we’ve shared it with love the way the Developer Story gives them real, tangible ways to understand what a candidate has actually worked on.

It's not just for developers who are job hunting.

Happy at your current gig, but open-minded? According to our 2016 developer survey, 63% of developers aren't actively looking, but are open to learning about new opportunities to level up. If you’re enjoying where you are, but open to finding that perfect new challenge, the Developer Story can help you keep an eye on what’s out there, and we’ll only send you the best opportunities that match your goals.

Completely not interested in jobs, but proud of what you’ve made? Listen, I get it. I never want to leave my job. The Developer Story is for you, too. Like most people who make things, devs often like to share what they’ve built. So it’s designed so you can use it as your own “coding central," even if you’re not job hunting. Just create a Developer Story, but set your job preference to “Not Interested.” You can share the features you’ve worked on, Github repos, blog posts, or even books you’d recommend. It’s your story. Tell it your way.

Once your Developer Story is beautiful, let’s work on your wardrobe.

We think one of the best ways to inspire other devs is by sharing some of the awesome stuff their peers are building. Or by showing a curious twelve year old what someone else who loves breaking machines can grow up to be.

So, for the next two weeks, if you tweet a link to your developer story, and include the #mydevstory hashtag, we’ll enter in you in a contest to win one of two hundred gen-u-ine Stack Overflow tees (50 mens and 50 women shirts each week.) And don’t forget the link to your Developer Story - we need it to contact you if you win.

Take a minute to start your story now.

(We hope you’ll indulge our use of Rear Admiral Hopper’s incredible biography as a case study for the images in this post. You should not take this to mean that the Rear Admiral endorses Stack Overflow in any way. You can, however, take it to mean that we endorse her. Wholeheartedly.)

Thanks to Abby T. Mars, Elaine Wang, Kaitlin Pike, Kit Carrau, Rachel Maleady, Taryn Pratt, and Tim Post for helping to improve this post.

Today we shipped an update to the calculator, which includes:

• International salaries
• Two new positions: Creative Director and Data Scientist
• 2016 market adjustment
• Skills now have a resolution of 0.5 (previously whole integer)

Setting the US market salaries

Our base salaries are updated once a year based on the best available information “market” rates. Sources we look at:

• Industry reports. We purchase salary data from a third-party, aggregated by job title. This gives us rough data for e.g. Software Engineers or Graphic Designers (though it isn’t specific to startups).
• VC surveys. All of our main VCs do yearly compensation surveys (which we participate in) and then share the aggregated data with us. This is our best survey data because it’s more specific to startups, though the sample size is smaller.
• Competing offers. For anyone hired in the previous year, we take into consideration any competing offers they received that they’re willing to share.

Setting the international salaries (new!)

As of 2016, we also benchmark international salaries.

Our People Team (which I lead) researches and establishes a base salary in the local currency for each country in which we have a presence. This salary is determined the same way we do it currently in the US – by researching the appropriate market rate for the country. We anchor it at skill level 1 and 4 years of professional experience.

We recognize that some countries have market salaries that are lower than the US – therefore when determining the local salary, we not only look at the local market, but also the “remote developer market” rate, i.e. the salary you would get if you were paid by a US company in USD.

The international salaries are updated yearly. If we hire someone in a new country mid-year, we’ll research and establish the base salary then.

Try the updated Stack Overflow salary calculator...

In this episode, Joel complains about things. How is that different from the other podcasts, you say? This time there's singing.

Our hosts also talk about a few recent blog posts concerning the declining quality of Stack Overflow while trying very hard, and failing, to not quote the first U.S. presidential debate. Jay and Joel break down what these posts got right, what they got really wrong, and what we can learn from them in our mission to make Stack Overflow a better resource for the world's developers. (Disclaimer: no Kewpie dolls were harmed in the making of this podcast.)

Speaking of the debate: Both candidates had something to say about tech, and we can't let that go without at least discussing the yuge problem of using "cyber" as a noun. Check out this week's “In The News” for this and much more, including hearing David ask "Grandpa Joel" to tell him more about the Xerox Alto.

Also, it's the second week of our new feature (not a bug!): the Stack Overflow Constitution. Vote on this week's amendment: Should programming languages count toward your college language requirement? Listen to the podcast to see where our hosts stand and tweet at us to weigh in yourself. Use the hashtag #StackOverflowPodcast and give us your Pro or Con with a brief explanation. The best answer will be read on the air next week, and by best, we mean which one made us laugh.

Last week’s winner, commenting on whether socks should go on before pants or pants before socks, was Bryan Bedard, who said

"Con. I tried to put socks on before pants but got an InvalidOperationException #StackOverflowPodcast" - Bryan Bedard, 3:53 PM - 26 Sep 2016

See you next week!

Notable links:

• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast
• Fascinating Xerox Alto restoration information
• Check out Esperanto on Stack Exchange and Lindsay Does Languages segment on Esperanto.

Before you listen, please note that this is episode #88, not to be confused with what should have been episode #73 since we last left off at episode #72. That episode was for The Stack Exchange Podcast, and this is The Stack Overflow Podcast. Confused? You’re literally the only one who is. Bury your feelings of embarrassment and don’t let anyone know.

This week, our usual hosts Joel, Jay and David are joined by Documentation team lead Kevin Montrose and product creative director Kurtis Beavers to talk about all the updates to Stack Overflow Documentation including the REPOCALYPSE (i.e. reputation apocalypse). Also joining this week is Ilana Yitzhaki, the show’s new News Editor.

A big change to pay close attention to: We’re writing the Stack Overflow Constitution, and we’re asking you, our listeners, to vote on the various elements of this new pivotal document. This week’s extremely important amendment says that one must put pants on before socks and NOT socks before pants. Listen to the podcast to hear the pros and cons of this amendment, then head to Twitter and submit your vote - with commentary - using the hashtag #StackOverflowPodcast.

Also be sure to listen if you want to hear the gang talk about, but not in, Esperanto (or you could check out the new Stack Exchange Esperanto site instead). By listening to this week’s show, you’ll learn what you should never say to a designer as well as what flight simulators have to do with Excel. You’ll also find out what the gang would do if they had access to a time machine (spoiler: They really, really need to revisit their priorities here). Finally, in a great show of kindness, Jay compliments David on his correct use of the phrase “for which.”

This week, our usual hosts Joel, Jay, and David are joined by Stack Overflow engineering manager Matt Sherman, who recently led the launch of our salary calculator. If you’re interested in working at Stack Overflow, or you just want to know how much our engineering, design, and product roles make according to years of experience and skill level, the salary calculator offers transparency into our compensation methodology.

Comments about the calculator were split on Reddit and Hacker News between us paying too much and us paying too little so… we’re doing it right? The gang goes deep on developers’ problems with salary negotiations, and they share an epiphany about the meaning of the classic board game, Monopoly, that they probably should have realized years ago.

As is now officially tradition — because there’s been two of them in a row — we have another One-Minute Tech Review from Joel for you. This week’s review is of Google Flights, where you can search for cheap flights in seconds. Will David throw shade on his review again? As is now also tradition, perhaps.

Finally, Jay talks about our recent decision to stamp out use of the term “rep-whore” in the community. From now on, “rep-whore” will be treated like any other term that’s inconsistent with Stack Overflow’s “be nice” policy: it will be removed.

If none of this is your cup of tea, make sure to listen anyway just to hear Joel tell a joke about the pluperfect tense. Memorize it and make sure to reuse at the next grammarian cocktail party you attend.

Remarkably, we learned that job listings which include a salary range got 75% more clicks than job listings that don’t. With this experiment, we’re even more convinced that transparency isn’t just the right thing to do, it’s good for companies, too.

Along with much of the tech community, we were impressed with Buffer’s boldness and leadership in salary transparency. So…

Introducing the Stack Overflow salary calculator

We’ve created a salary and skills calculator for Stack Overflow’s engineering, design and product roles. This has been transparent internally for a while; now it’s transparent with you.

Those who know Stack Overflow know that we work hard to work in public. This is a continuation of that tradition.

What we hope

We hope that moves like this will inspire other employers to greater transparency.

A lack of transparency is what economists call an information asymmetry: it’s in companies’ interests to keep these numbers close to the vest. Individuals are uncomfortable talking about salary sometimes, too.

We believe that conventions can change. If more companies become open on salary, perhaps openness will become expected.

Work in progress

Our salary calculator doesn’t cover every role at Stack Overflow. It doesn’t include equity, and only describes US salaries. (International employees use the same system but it’s not merely a currency conversion.) In the spirit of “default public”, we would rather share an incomplete system than not share at all.

The experimental details: 75% more clicks

(By David Robinson and Bret Copleland)

For our experiment, we redesigned the Stack Overflow Jobs ads to display salary ranges. We were curious: just how much effect does this information have?

We ran an A/B test, where for a random half of our users we hid the salary information from the ads they were shown, and measured the difference in clickthrough rate. Visually, it looked like this:

We expected to see an improvement, but we were surprised by the size: a 75% average increase in clickthrough rate (CTR) when we showed a job's salary range.

What if a job has a relatively low salary – is it still worth showing? Generally speaking, yes: we found that showing any salary range led to an increase in CTR, though higher salaries led to a greater bump. For American jobs, we saw roughly a 60% increase for jobs with salary ranges centered below $100K, and about a 100% increase (doubling) for salaries above $100K.

Is this just an effect of novelty, where users were surprised to see salary? Unlikely – we didn't see any decline in the effect, and it has been consistent in the months since. We've tried many other changes to ads and have never seen anything this dramatic.

Clickthrough rate isn’t everything, but it’s an encouraging sign that advertising a salary range will help draw developers to a position.

Try the Stack Overflow salary calculator...

Further reading

• Joel on How much should you pay developers?
• Stack Overflow Developer Survey on job priorities.

"Together, we believe we can do the same thing for technical documentation that we did for Q&A."

Documentation is community-curated, example-focused developer documentation, based on the principles of Stack Overflow.

If you ever wanted to contribute to Stack Overflow but weren't sure you could, now's your chance to give back. Whatever technologies you work with, whatever your experience level, there will never be a time your contribution is more valuable than it is today.

So, why will this be better than how documentation is today, exactly?

Examples, examples, examples - show beats tell. In Stack Overflow Documentation, examples are the star of the show. Anyone can add one, so good topics will eventually have several useful examples. And much like answers on Stack Overflow, the most helpful ones will usually be voted up to be right on top.^*

It's need-driven and self-healing. The best, most diligent technical writer out there still can't beat thousands of actual users trying to learn a function or concept while writing real code. They'll determine what topics or examples are needed most. And whenever something fails to explain something clearly, they can ask for it to be improved.

It builds on what made Q&A work, but recognizes where it can be better:

• Familiar elements, so you're not starting from scratch. Voting, requesting a topic, adding examples all mirror Q&A elements (voting, asking, answering)
  

• More emphasis on collaboration, and ensuring most developers can contribute. The more canonical nature of artifacts created means:

  • More "shared" ownership of posts and more collaboration
    
  • Small edits and contributions are encouraged
    
  • Everything is reviewed by other helpers, so you can't "break" the page trying to help
    

• More recognition for more people - More collaboration means more helpers need recognition. And documentation shares a feedback and reputation system with Q&A, so contributions to either earn you reputation and privileges on both.

• Your generosity, your content. All content is covered by the same CC-SA license that SO Q&A always used. And our regular data dumps will now include Documentation content.

• "Be Nice" still applies. We know that occasionally some folks can get a little prickly, but this is who we still are:

  Whether you've come to ask questions, or to generously share what you know, remember that we're all here to learn, together. Be welcoming and patient, especially with those who may not know everything you do. Oh, and bring your sense of humor. Just in case.

So, why does Documentation belong on Stack Overflow, exactly?

Go back and read Jeff's original introduction of Stack Overflow, you'll find this pitch:

[Stack Overflow] is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

_{(emphasis mine)}

This was a great starting place, but over the years we've made tweaks as we've learned from the community - both from direct feedback on Meta and from observing how people use Stack Overflow. We learned that our Q&A works best when you've got a real problem, specific to the code in front of you. By coming to terms with that, and tweaking Stack Overflow accordingly, we've become much better at Q&A but have left some programming knowledge out in the cold.

Documentation gives a home to a lot of this good content that has been turned away, or very hard to "get right" in the Q&A format. Namely, the canonical, general reference, instructional content.

Once word got out Stack Overflow was expanding, the developers responsible for some of our favorite tech got a little excited. The Meta community got first dibs with the private beta, but now that Documentation is live on Stack Overflow I'm pleased to announce developers from:

will be participating in Documentation right alongside the community. They'll be watching to see what kind of great examples and documentation are created to inform their own work and help answer or clarify anything that needs it. They're Stack Overflow users like everyone else, we're all working together (to help developers everywhere), so you could see your change reviewed by a Microsoft-y or find a request from a Dropbox-er.

Ready to help?

Whether you've been posting on Q&A for years, or have always wanted to give back if you could, now's your chance. Docs today resembles Stack Overflow Q&A was right when it launched - there's a lot of white space to fill in, and plenty of chances to "actually write the book on" your favorite tech.

Oh, and since we really want to use this launch to expand the Stack Overflow Community tent, we've got some silly/shiny fun to encourage folks to jump right in!

All users who contribute to Documentation the next four weeks:

• Will get a silver "Documentation Pioneer" badge
• Will be entered in a drawing to win one of 100 Stack Overflow T-Shirts

Let's go build this thing together.

• Browse Documentation
• Take the tour
• Jump in and handle (or make!) requests for
  • .NET Framework or C#
  • Dropbox API
  • PayPal
  • PubNub
  • Twitch
  • Meteor
  • Xamarin iOS or Android
  • Twilio
  • .. or browse all tags in Documentation

_{* We literally almost called this "Stack Overflow Examples", but then we thought about having to constantly explain that it serves the same purpose as 'Documentation' used to, but we didn't call it that because the important part of documentation is the Examples, which are central to our thing. So we stuck with the term folks know.}

Our annual surveys ask developers what they’re up to, what tech they care about most, and what they want. This year, for instance, we found that JavaScript remains the most popular programming language in the world, 46% of developers don’t have a bachelor’s in computer science or a related field, and job satisfaction is highly correlated with pushing code to production.

While we like to think we know software developers better than anyone, we’re eager (and curious) to see what you come up with in your own analysis of the data. The launch of our new research site means you can compare what developers have said about the state of the programming world and workforce since 2011.

You’ll be able to answer questions about how technology preferences have changed over time, whether particular demographics correlate with certain developer job types, and even what programmers think of Stack Overflow.

If you do find something interesting while digging through the data, let us know on Meta. And if you’re ambitious enough to make it an academic paper, we’d love to add it to our collection. Finally, if you’re curious about adding even more data related to Stack Exchange sites, check out our Stack Exchange Data Explorer, designed to make it easy to query and browse the public data we periodically release for all Stack Exchange sites.

Happy data diving!

But before we talk to the guests, our esteemed hosts run through some interesting tech news. (Or maybe just tech news. -Ed.) First up: .NET Core! Microsoft is trying to turn a gigantic ship around toward open-sourciness and community-friendliness. (Said ship is apparently unrelated to the arm of Microsoft that forced you to upgrade to Windows 10.) Also: did Microsoft build their own version of Trello? You decide.

And now it's time for the first and possibly only but definitely first monthly One-Minute Tech Review with Joel Spolsky! This week's OMTR is Wallcat. It's free. You can install it. (If you know your Apple password.) It changes the background image on your computer every day! Amazing.

Let's turn from tech news to Stack news. What's shipped since our last podcast?

• A new and improved Stack Overflow Enterprise! It's for big companies with lots of proprietary code who want to run private Q&A for their development teams. Companies with 1000+ developers who want this can get it by sending an email to enterprise@stackoverflow.com.
• We updated the sitewide Terms of Service. It forbids companies from going onto Stack Overflow to scrape profile data, which protects our users from spam.

Our guests have been waiting very patiently through all this, so let's turn to them! Daniel X. and Gareth work at Fog Creek Software, the first company Joel founded. They're currently working on HyperDev, the easiest and fastest way to get your idea developed and deployed on the internet. You can get an app up and running in less time than it takes to listen to this segment--without shaving any yaks. So go check it out! We talk about the story of the product for a long time before we remember to talk about how it actually works, but rest assured, we do eventually dig into that part.

So what's next for Stack Overflow?

• Running some tests on the /ask page. This hasn't been touched since the dawn of time, more or less. The community has been discussing ideas here, so read up and weigh in!
• Documentation. We'll cover this in more detail next podcast.

And that's it for this podcast. Thanks for tuning in!

For the past several months, Monica—who writes documentation for programmers at her day job, and even holds a tag badge in technical-writing on Writers SE—has been spending some of her free time putting together a tutorial for people who are completely new to the Data Explorer or SQL. Thanks to her efforts, and those of another awesome community member, Tim Stone, the de facto maintainer of SEDE (and the SE election stats page), version 1.0 is finally live!

This new tutorial introduces the basic concepts of relational databases, and teaches the fundamental SQL statements that go with them. Examples all use the design of the actual Stack Exchange databases. And for those who find themselves getting really interested, digging into more advanced queries and having some trouble, well, there's a great place nearby to get help.

About the Stack Exchange Data Explorer

In keeping with our founding principles, all user-contributed posts are always available for reuse with minimal restrictions, and we even package up "data dumps" of all the content on Stack Exchange regularly for researchers and others who want to work with large chunks of the content.

Of course, not everyone has the time or expertise to download massive data dumps and then install SQL locally or write custom code to get what they want. So we also provide a web UI to the same information: the Data Explorer. It's essentially a publicly accessible copy of the databases behind the SE Q&A sites. It gets updated weekly with all the latest changes, minus a few sensitive things like users' e-mail addresses and voting behavior.

People have mined all sorts of interesting information out of SEDE. Ever been curious how much reputation you would have if the 200-points-per-day rep cap didn't exist? Or wondered how true someone's claim that "downvoters are ruining everything" really is? Maybe you have an idea for a new badge, and want to see how many people would meet its criteria before you propose it on meta. For all of these situations, SEDE is the answer.

But even though SEDE is nicer to work with than a raw data dump, it can still be pretty intimidating to new users, especially those who aren't trained database engineers. Up until now, the Data Explorer's own help docs have been a little thin, and mostly covered very specialized, advanced features. We've wanted to expand the guidance there for a while, but never quite got around to it. Then Monica rewarded our procrastination by helpfully volunteering to take on the writing.

So please check it out, try your hand at answering that question you've always had about your favorite site but never knew who to ask, and let us know what you think on meta. And again, a big thank-you to Monica and Tim for their work in creating this great guide!

On May 26th and 27th, Stack Overflow has the privilege of participating in the inaugural White House Foster Care & Technology Hackathon. This event - hosted by the White House, the U.S. Department of Health and Human Services, and Think of Us - will bring together child welfare leaders, non-profit organizations, and foster care families and alumni, as well as engineers, technologists and leaders from the technology sector.

At the Hackathon, Stack Overflow will team up with subject matter experts to "hack" on the topic of preventing unplanned pregnancy for foster youth. We will create a prototype solution to try and ensure that youth in care have access to culturally relevant information and resources about sexual health, including pregnancy planning and prevention. Our hackathon team - Adam Lear, Kirti Thorat, Geoff Dalgas, and David Haney - are very excited to put our skills to use in a field that is deserving of positive change.

Over the past few decades, it has become clear that technology brings about positive social change. From bringing education to underserved populations, to printing medical devices for third-world countries, to raising awareness of social inequities, technology is one of the best resources we have to solve the problems we face as a global community. As humans we have a responsibility to help each other in whatever ways we can. As software engineers, we're equipped to create technology that can change lives. To that end, our proposed solution is a mobile app - easily accessed by foster youth via smartphones - that can provide geo-aware addresses, information, and ratings about trusted resources, clinics, and support groups that foster youth can access and learn from. A major issue identified in the field currently is uncertainty about who foster youth can talk to - often on short notice - about a broad spectrum of sexual health topics; this app can become a powerful on-demand resource for social workers and foster youth everywhere.

Stack Overflow will continue to serve programmers of all ages and upbringings. We are honored by this amazing opportunity to improve the lives of foster youth, and look forward to meeting - and being a resource to - the many foster youth that will pursue careers as developers in their future.

We fundamentally believe that developers are writing the script for the future. The work that developers do every day is transforming industries and shaping the way we all live, work, and experience the world around us. We also believe the professional generosity of developers is unmatched; Stack Overflow wouldn’t be what it is today without the contributions of millions of developers and their desire to help one another while advancing the world’s collective programming knowledge.

We’re thrilled we have a veteran storyteller like Adrianna on board to help us show the world just how important we believe developers really are and what we’re doing as a company to support them. Beyond Q&A, developers can go to Stack Overflow Jobs to find opportunities targeted to their interests while connecting with recruiters (no spam allowed). We also want to make sure businesses know that the best place to source technical talent and gain insights about the developer community is through Stack Overflow Careers. We have a ton of exciting products on our roadmap, all of which support our mission to help developers learn, collaborate, and advance their knowledge and careers.

Adrianna will drive our global branding, communications, digital marketing and demand generation – basically raising awareness about Stack Overflow and sharing with the world the industry-changing work being done by the Stack Overflow community. As part of her responsibilities, she’ll join the Stack Overflow executive team, helping support our continued expansion into services that make developers’ lives better.

Please join us in welcoming Adrianna to the Stack Overflow team!

Source

This is our starting point for this article. We have the Stack Overflow repository on a developer’s machine. For the sake of discussing the process, let’s say they added a column to a database table and the corresponding property to the C# object — that way we can dig into how database migrations work along the way.

A Little Context

We deploy roughly 25 times per day to development (our CI build) just for Stack Overflow Q&A. Other projects also push many times. We deploy to production about 5-10 times on a typical day. A deploy from first push to full deploy is under 9 minutes (2:15 for dev, 2:40 for meta, and 3:20 for all sites). We have roughly 15 people pushing to the repository...

Read the rest of Stack Overflow: How We Do Deployment - 2016 Edition on Nick's blog here. It's the second in an extensive series of blog posts on Stack Overflow’s technical architecture.

In the context of servant leadership, it’s our job as managers to ensure that our time together meets this high bar.

Optimize for presence

Meetings are synchronous communication. In programming parlance, they are blocking, which is to say they prevent other work from being done. They are expensive in terms of both actual time and context switching.

Therefore, meetings should be reserved for interactive communication that requires presence. This is especially true at Stack because our engineering team is majority remote and distributed across time zones.

Reciting status while others listen is not good use of presence. A list of facts can be read just as easily as it can be heard. Can we do better?

Question-driven

My particular team (Careers) does something a little different. We update a status document ahead of time. We block out 5 minutes of silent reading at the beginning of the meeting.

Then, we go to every team member and ask if anyone else in the meeting has a question for them. There is no status recital. A conversation must be prompted by a question. There are usually plenty.

No questions? Great! Let’s get back to things that aren’t meetings.

Talk-show host

That said, we want to tease out conversations.

When I run that meeting, I will do my research ahead of time and have questions in my back pocket if others aren’t forthcoming. I ask follow-ups. A bit like a talk-show host.

Also? We like guest hosts. We pick a new team member to run the show every two weeks. Running a meeting is FizzBuzz, remember? Nice opportunity to broaden skills for future managers.

Managers like to talk

A further advantage of the question-prompted format is that we managers don’t get to talk in an open-ended way.

Talking needs to be about something someone wants to know, and which is worthy of our valuable, synchronous time together. Managers set an example here, by deferring to the team to choose the direction of conversation.

Every team is different

To be clear, what I describe above is what my team does. Others at Stack share these principles but go about it their own way.

The question-driven format has been good for us on Careers. We’re a big team (13 developers!) so it’s especially important to ensure that meetings are lively, informative, and time well spent.

My final attempt (which is among the fastest) ended up using a lot of tricks, which I think may be of general interest – so I’m going to walk through how the code works.

View the full post at kevinmontrose.com...

According to the proposal on Area 51 at the end of the beta, the site had:

• 115.7 questions per day
• 82% answered questions
• 1,499 avid users and 33,678 total users
• 1.7 answer ratio
• 42,464 visits/day

While I was writing this post, the site was in fifth place by questions per day, it is one position above Server Fault (which, among other things, is one of the trilogy sites)! To build a community of this size, it took us only nine months! Well, not really, actually. We, the community of Russian-speaking developers, have been building up our professional culture and the knowledge base for several years now.

We started our story with three issues in mind.

• Compensate for the lack of professional communication at work. Some of our colleagues (I mean, physical ones) are not willing or able to be engaged in professional communication in their spare time. Experts and those seeking new knowledge and skills often have to search for knowledgeable programming enthusiasts outside their company, and, moreover, sometimes they even have to change companies because of the absence of necessary skills and passion for the profession among their peers.
• Collect a base of notes ready-made solutions for work. Whether we’re working with new or very old technologies, we are faced with the need to seek a solution by browsing through vast volumes of documentation, and finding it, just to forget in a few days; not just the solution itself, but also where it was found. This process may drag on until someone responsible publishes, in a public place, a minimal solution with comments and appropriate links to sources.
• Share experiences with colleagues. How many times have we experienced frustration after looking for the right gcc options for a week, realizing that lots of people had spent weeks solving the same problem? Problems like this could be solved within a few minutes, if you knew where to look for the solution. It would be wrong not to share the solution with colleagues!

We did not just think about how great it could be to solve all these problems in the scope of the Russian language, we have started solving them! Together.

Graduation allows us to say that Stack Overflow in Russian is no longer a site for a couple of enthusiasts who strive for excellence in their profession. Stack Overflow in Russian is now a big crew of enthusiasts who strive for excellence in their profession!

Perhaps it is not visible at first sight, but by the words “Stack Overflow in Russian" we mean real people. Those whose efforts would be hard to overestimate: @VladD, @Nofate, @Nick Volynkin, @Etki, @andreycha, @Suvitruf, @Discord, @alexander barakin, @ЮрийСПб, @PashaPash... These are just a few randomly selected folks. Cannot believe that the community is so strong? Check it out – http://ru.stackoverflow.com/users.

А few facts:

• Per month, more than 2,000 developers join the community.
• The site is most popular in (descending): Moscow, Kiev, Saint Petersburg, Minsk and Kharkov.
• Monthly, more than 3,000 developers get correct answers from their colleagues on the site.
• To get as much developer attention as on Stack Overflow in Russian, you would need to hire 23,000 developers full-time.

Imagine how many person-years are being saved each month due to these people who ask questions and answer them on Stack Overflow in Russian. It's amazing, isn’t it?

We think it's not a secret that professional growth is only possible among more advanced colleagues. With the launch of Stack Overflow in Russian, the Russian-speaking developers can constantly improve their skills without needing to change jobs again and again in search of an exemplary team (if it is not the goal, of course). Today, no matter where you work, — at a Google or at a Mickey Mouse company, — you will still be able to grow professionally in a community of experienced colleagues!

What People Are Saying:

The strategy of looking for an answer in the Internet is easy. I type a question in a search engine and usually I see the answers on the first page of the search results.

I ask questions on Stack Overflow in Russian because there I can get very quick answers to my questions. Also, the interface is nice and user-friendly.

I see plenty of benefits :) Because of the users’ answers I learn a lot. Thanks to Stack Overflow in Russian I learned almost everything that is required for my work and so I do not ask stupid questions anymore.

The questions I asked, of course, are helpful to others. Many questions have gained lots of views, most likely from the search engines, and some questions got upvotes, which means that colleagues are interested in the same topics, too.

Once in 2012, if I am not mistaken, I had to find an answer to a question and typed a search query into Yandex. Along with the search results list, a block of advertisements appeared, and the first advertisement lead to Stack Overflow in Russian. Since the search results did not contain the right answer to my question, I clicked the ad and asked the question on the site. That was the first time I visited such a site. Of course, I got an answer almost instantly. I have been here on the site ever since :)

Currently my profile is 3 years 9 months old :) I visit Stack Overflow in Russian every day to look through the questions and answer them, if I can. On my mobile, Stack Overflow in Russian is the first in the "Last Visited" list!

The site is certainly useful for everyone, and I am delighted to have found it just by chance. Thanks to Stack Overflow in Russian, I have learned so much!

– ModaL

I found answers to all (!) my questions here. Even when I expressed myself, perhaps, not entirely clearly, I was guided in the right direction and to a suggested plan of action. I studied the programming on my own, and each time I had questions (frankly, I had a lot), Stack Overflow in Russian helped me to answer them.

Within a few hours, up to one day maximum, all my questions were answered. I'm fascinated by the founders of the site and the colleagues who helped me.

– Rakzin Roman

Glad to see how Stack Overflow in Russian is gradually growing and accumulating knowledge. It is even more pleasant to realize that I had a hand in it.

I am glad that we are, compared to the same Stack Overflow in English, somehow more democratic and kinder.

I have been on the site for a long time. I have noticed a gradual trend to systematizing and organizing knowledge. I am really amazed with how much time people contribute to Stack Overflow, which is very exciting.

I am glad that I am part of a community that helps people. And, answering questions, we also systematize our own knowledge and discover something new for ourselves.

So, thank you all, and let's make Stack Overflow in Russian even better :)

– Suvitruf

We can proudly say that together we are gradually building the best place on RuNet, where everyone can get a detailed answer to any programming question. And please, don’t take my word for it, check it yourself — ask your question or answer someone’s! (After all, all professional software developers know Russian, don't they? Or are you not a professional developer?)

Still here? Awesome. Or your browser is crazy slow, in which case you should think about some new hardware.

I've repeated many, many times: performance is a feature. Since your code is only as fast as the hardware it runs on, the hardware definitely matters. Just like any other platform, Stack Overflow's architecture comes in layers. Hardware is the foundation layer for us, and having it in-house affords us many luxuries not available in other scenarios...like running on someone else’s servers. It also comes with direct and indirect costs. But that's not the point of this post, that comparison will come later. For now, I want to provide a detailed inventory of our infrastructure for reference and comparison purposes. And pictures of servers. Sometimes naked servers. This web page could have loaded much faster, but I couldn't help myself.

In many posts through this series I will give a lot of numbers and specs. When I say "our SQL server utilization is almost always at 5--10% CPU," well, that's great. But, 5--10% of what? That's when we need a point of reference. This hardware list is meant to both answer those questions and serve as a source for comparison when looking at other platforms and what utilization may look like there, how much capacity to compare to, etc.

How We Do Hardware

Disclaimer: I don't do this alone. George Beech (@GABeech) is my main partner in crime when speccing hardware here at Stack. We carefully spec out each server for its intended purpose. What we don't do is order in bulk and assign tasks later. We're not alone in this process though; you have to know what's going to run on the hardware to spec it optimally. We'll work with the developer(s) and/or other site reliability engineers to best accommodate what is intended live on the box.

Read the rest of Stack Overflow: The Hardware - 2016 Edition on Nick's blog here. It's the second in an extensive series of blog posts on Stack Overflow’s technical architecture.

Because of this, we like to think we know software developers better than anyone — and we have the data to back up that claim. Each year since 2010, we’ve asked developers what they’re up to, what tech they care about most, and what they want.

With more than 50,000 responses fielded from 173 countries, this year’s Stack Overflow Developer Survey is the largest and most comprehensive survey of the programmer workforce that has ever been conducted.

View the full results here.

Key Findings on Technology:

• JavaScript remains the most popular programming language in the world.
• React is the fastest growing technology on Stack Overflow. Swift is exploding too, and Objective-C is in decline.
• Rust is the most-loved programming language. A higher percentage of developers who program with it want to continue to do so more than any other programming language.
• Visual Basic is the most dreaded language. A higher percentage of devs who program with it don’t want to continue with it more than any other programming language.

Key Findings about Developers at Work:

• 91% of developers in the workforce are "gainfully employed" either full-time, self-employed, or freelance.
• 46% of developers don’t have a bachelor’s in computer science or a related field. So if you’re an employer requiring one of these degrees in order to consider a developer candidate, you may want to reconsider your strategy.
• Developers just want to code. Job satisfaction is highly correlated with pushing code to production. And 57% of developers told us they check-in or commit code multiple times per day.
• Make it rain! Cloud technologies like Spark and Cassandra pay better than anything else. The median salary for developers in the US who know Spark is $125k, and there are plenty of cloud devs who are making a lot more than that.
• Don’t call programmers “rockstars” or “ninjas”. Only about 10% of devs call themselves ninjas, and 7% consider themselves rockstars.

Thank you to everyone who participated in our survey and shared information about yourself. We’ll be releasing the full data set in just a few weeks. Do you have ideas for what we should ask about next year? Tell us in the comments.

Oh, and one more thing. Here’s the answer to how many pennies were in that piggy bank.

Developers come from all walks of life, and have many unique interests, passions, and hobbies. Often the only thing that developers have in common is their love for programming. It follows that some are good negotiators; others get the double digit percentage finance rate at the dealership when they go in to buy that new car.

How Does Your Company Determine Compensation?

When you hire developers, how do you decide on their salary? Do you allow for negotiations to take place? Is there a strategy in place where you offer a low value, expecting the candidate to counter with a higher number? Are you pleased when they don't counter, and you get good talent for cheap?

The thing is, developers are the linchpin in your tech company. They make or break your products - quite literally, in fact. They're worth a lot of money. You should be paying them what they're worth as one of many strategies to keep them happy. If you're low-balling developers with a salary strategy that rewards negotiation skills, you're probably underpaying them while overpaying the developers who are good negotiators (but maybe not amazing coders).

Your underpaid talent might not feel comfortable asking for a raise to the income that they are worth. Can you guess what happens then? They leave your company for another that values them correctly. The result is that your department has high turnover, lots of churn, and high costs around replacing the fleeting talent.

Stack Ranking: Upsetting Developers Everywhere

One of the most common ways to compensate employees is by employing a stack ranking system. There are varying approaches to stack ranking, but a typical implementation of a stack rank system is as follows:

• A company employs a ranking system, often a scale of 1 to 5, to assess employees.
• These numbers often come with generic and impersonal descriptions. The scores themselves are bucketed with percentages that limit the number of employees that may receive a given grade:
  • 1: Exceptional (10% of employees)
  • 2: Highly Effective (20%)
  • 3: Consistently Strong (40%)
  • 4: Partially Effective (20%)
  • 5: Not Effective (10%)
• Managers are given a fixed $X in raises to hand out for annual reviews.
• The $X budget for raises is distributed per the grading, with the 1's getting the biggest chunks, and 5's often getting nothing.
  • Note that this is how stack ranking is used to control budget costs. You always know exactly how much money is being given out in raises.
• The 4's are warned that they're on the way to being fired if they don't shape up.
• Typically, the 5's get fired or put on a performance plan.

This system - also known by the endearing terms "rank and yank," "forced distribution," and "grading on a curve" - is popular because it control costs, both in terms of annual raises and also under-performing employees. It serves as a system that forces the bottom 10% (or whatever the bucket is set at) out of your company regularly. This is not a bad thing in-and-of itself, assuming that the replacements hired are any better. Of course, this is where one of the major problems becomes evident.

Why Stack Ranking Sucks

Here's the thing: someone always has to be a 5. This system is built on the false assumption that there's always someone who is Not Effective on your team. It institutionalizes the idea of mandatory mediocrity.

It is easy to see how ridiculous this concept is when you apply it to objects instead of people. For example, let's review 5 cars with stack ranking: a Ferrari, a Lamborghini, a Maserati, a Porsche, and Rolls Royce. Which one is the exceptional one? Which two are under-performing and mediocre? In this all-star set, they're all great, but stack ranking demands that one is worse than the others by a large margin.

What happens if you employ good hiring practices and recruit a team of 10 amazing developers? What if they're all 2's and 3's, but you have to give out 4's and 5's? You end up having a difficult annual review where you find yourself apologizing and telling your developer how great you think they are. Because you really do think that. But your words are hollow, and their raise and review are the actions that speak louder; at this company they are thought of as mediocre, because someone has to be.

Have you ever had a review where the actions of your manager didn't match their words? You're being told what an all-star and amazing player you are on the team, how important and awesome you are, and how everything you touch turns to gold, but your review says "you're average" and that big fat 3 rating is searing itself into your brain. You're wondering "if my boss thinks I'm so great, why is my rating average?" That's what stack ranking gets you. This review probably upset you, and now you're contemplating your options. Not a great outcome for you or the company.

Stack ranking also stifles the desire of your developers to try new things, take on new roles with more responsibility, and take risks to grow their careers. This is because a 1 or 2 player won't want to take on the risk of joining a new team, or getting a new boss, who might rank them as a 3 or lower compared to their more seasoned colleagues. Indeed, the smart play is to stay right where they are, and reap the benefits of being on the good end of this ridiculous bell curve.

My biggest concern with stack ranking is the fact that compensation is relative. Your assessed performance depends entirely upon the performance of your peers, as subjectively assessed by your manager. You might have been a 1 if it weren't for that person who happened to claim it. Now the best you can be is a 2. But if they didn't work there, perhaps you'd be a 1. Doesn't seem fair (or even rational), does it?

My Personal Experience With Stack Ranking

I have had a few jobs in the past that employed stack ranking. At one of them, developers picked 3 projects to be assessed on, and then both they and their manager ranked their performance on the projects from 1 to 5. One of the projects that I picked was something that I had built from scratch with a team of 4 people. The thing we built had made the company millions of dollars that year, and I was the lead on it. Naturally, I gave myself a 1 on it. My manager gave me a 3.

I asked him how I could possibly be average at the thing which I created, was the most experienced with at the company, and which had led to millions in additional revenue. His reply was that I was awesome and not to worry too much about the grade. It was very confusing; what he said didn't match what he wrote.

The review continued, and I ended up being given a 3 out of 5. I got a small raise. This was all conveyed to me as my boss happily told me that I was awesome, to keep up the great work, and that to keep it between me and him but I got the biggest raise on the team.

The idea of having the biggest raise made me feel less wronged... Right up until I found out that it was a lie. My team and I were at lunch a few days later when one person bragged that he got the biggest raise on the team. Another immediately said "what? I was told that I did." I began to laugh as I realized what my manager had done. He had told us all that we received the biggest raise, and to keep it to ourselves. Perhaps as damage control for the pain that the mediocre grades had inflicted, but unfortunately for him we talked to each other. The jig was up, and now most of us were madder than we would have been had he said nothing to us at all.

A side note: leaving that job was one of my favorite resignations. When I quit, my boss was distraught, but I said (paraphrased) "hey [boss], don't worry about it! I'm a 3 out of 5, so you should have no issues hiring any other average developer to take up the work I was doing." The look on his face told me all I needed to know: he had now realized for himself why stack ranking sucks.

How to Properly Review & Compensate Developers

The key to happy developers is fair compensation. Fair compensation is all about transparency. At Stack Overflow, we have a transparent system for assessing employee skills and compensation, which is lovingly called Be More Awesome. There is no magic in employee compensation here, and all developers know exactly what they're getting paid, why, and what they could get paid in the future. There are no negotiations, no bell curves, and no quotas.

Be More Awesome (BMA) is pretty simple. It is meant to measure skills; we use performance as evidence of skill. A person may rate highly on their BMA for a skill, even if they haven’t used it in the previous year. There are 4 possible grades that can be awarded for each skill:

• B: Could be more awesome. This is a good thing to work on over the next year -- and your manager will help. This can also be applied for new employees who haven't been in the company long enough to demonstrate that they deserve a higher grade.
• A: Does as expected, at our high Stack standards. Completely, utterly able to accomplish what is needed.
• A+: Does more than your team expects, even at our high level. Exceptional and noticeable skills.
• A+++: Widely recognized level of amazingness. Does and teaches. When people think of this skill, they think of you (or would if they knew you). This will be rare, even on our amazing team.

You might notice that there is no grade below a B. We don’t have C's or lower because we believe that everyone that works here is awesome. If one of our developers were doing C, D, or F level work, we would already be working closely with them to correct it - prior to reviews.

It's also not uncommon for people who are earlier in their programming career to receive a lot a B's. This doesn't mean they're doing poorly at all. It just means they're closer to the beginning of their career than the middle and there's a lot of opportunity for them to grow.

The actual skills that we assess each year change, but the 2016 BMA chart for developers currently looks like this:

There are descriptions that explain what each of these categories are, and they are available for all employees to review at any time.

Once a developer is assessed on a BMA, their letter grades get converted into a numeric score by using a formula that is also published internally for all developers to review. This formula outputs a numeric score between 0.00 and 5.99 (with 5.99 being the best grade), which is then rounded down to the nearest whole number. In short, a developer can receive a score of 0, 1, 2, 3, 4, or 5.

Next we assess the years of programming experience. This is a value that falls in a range from 0 to 25. Naturally, this goes up by 1 at every annual review.

The score and years of experience are then looked up on a chart that has years of experience on the X axis and score on the Y axis, and details salary amounts at each cell. It's worth redundantly noting that this chart is published internally also and can be reviewed by all developers at any time. Unsurprisingly, the cell that your score and experience points to is exactly what you get paid.

Make Compensation Transparent

There are no secrets or magic in our compensation system. All aspects of it are published internally for all developers to review at any time. They also get input into the changes to the BMA skills each year, well in advance of their annual review. They know the formula that we use to calculate salary. Most importantly, their compensation doesn't depend on the performance of anyone else. Everybody can be a 5 in our system and everybody can be a 0.

Above all else, our system is fair and evaluates individual performance, not team performance. If you want happy developers and low turnover, I highly encourage you to try adopting such a system yourself. If your company is unwilling to do so, perhaps evaluate why. Are there secrets and magic in the compensation system that you don't want your employees to know about? Why do you value these hidden metrics? Do your employees feel valued?

A happy developer is a productive developer, and while a fair system does not allow you to easily control salary costs in terms of budget (because everybody can be a 5), it does help increase job satisfaction, lower turnover, and maintain a relationship of trust with managers. And as I've written about before, if you don't have the trust of your employees, you will fail.

EDIT (7/27/2016): We have published a salary calculator based on our internally transparent compensation numbers! Take a look.

PS - hate stack ranking but love Stack Overflow? Come and work with us!

Follow David Haney on Twitter at @haneycodes

As I write this, Donald Trump is well on his way to winning the Republican primary even though most people predict he'd lose a two candidate race. The problem can be summed up with this (hypothetical) chart:

Trump supporters tend to be pretty adamant about their candidate, so let's suppose they wouldn't bother to vote if he weren't running. And let's suppose that Cruz and Rubio supporters would rather have the other candidate rather than Trump. And let's suppose Bush, Kasich and Carson are stealing votes that would go to one of the leading "not-Trump" candidates. In this scenario, it's clear that Trump is only in play because the rest of the field is divided. He'd lose to Rubio in a two-candidate race.

This is precisely the sort of paradox that single transferable vote (STV) systems are designed to resolve. While the math can be daunting, the idea is rather simple. Instead of waiting for candidates to drop out, an STV system allows voters to rank their preferences and resolve the voting accordingly. So in the example above, Carson, as the least-supported candidate, would be dropped and his votes would be transferred to Cruz.¹ The new tally would be:

Then the process of dropping the candidate with the least votes would continue until some candidate gets a majority:

It's as simple as that.²

Moderators on Stack Exchange are elected using single transferable vote because we believe it provides the best method for representing the interests of broad and diverse communities.³ Instead of forcing voters to judge whether a candidate might be popular among other voters, the system allows people to vote their preferences without throwing away their vote on losing candidates.

Footnotes:

1. To simplify the explanation, I'm assuming all of the supporters of Carson would have identical preferences. In reality, other candidates, including Trump, would pick up some of those votes.

2. Again, the real world is a bit more complicated because some people would have Trump as their second or third choice over Rubio. There would also be people who leave both Rubio and Trump off their ballots resulting in "wasted" votes. Finally, the party might decide it worthwhile to award delegates proportionally to, say, the top three candidates. On Stack Exchange, we use the more sophisticated Meek algorithm that solves all of these problems.

3. Even the fact that we allow our users to select moderators at all is a bit unusual.

First: it’s hard

Technical interviewing is hard. The best companies in the world haven’t cracked this nut.

Here’s what Google had to say about the process.

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess...

This is coming from a company that interviews tens of thousands of engineers, and knows a thing or two about analyzing the data. If it’s hard for them, it’s hard for all of us.

Smart and Gets Things Done

Even so, we have some strong opinions about how to hire (and keep) good developers -- our founder wrote the book on the subject, called Smart and Gets Things Done. This forms a framework for our process.

Mostly Remote

We perform most of our technical interviews remotely, using Google Hangouts and a shared doc for code. It’s quite rare for a technical interview to happen in person.

Stack Overflow has a strong culture and history of remote work, and our interview process reflects that. More than ⅔ of our technical staff works remotely.

A conversation, not a quiz

Our interviews are designed for conversation, and to learn how the candidate thinks. We don’t want our interviews to feel like a quiz.

To be clear, the interview is highly technical and challenging. However, we work hard to make sure the questions lead to productive exploration and conversation.

Fairness and comfort

The interviewing process is artificial. We know this. In real life, no one expects an engineer to program on the spot, in an hour or less, with someone watching.

It is in our interest, and the candidate’s, to relieve their nervousness as much as possible. A relaxed interview is much more informative.

We explicitly tell them to think out loud, take their time, and if they need to back up and fix something, that’s great. That’s how programming works.

We reiterate that we are not looking for the answer to the question, per se.

Decisive

After each interview, the interviewer must make a clear decision: Hire or No Hire.

We don’t do “maybe” – that’s not good for us or the candidate. If the interviewer is on the fence, that’s a No Hire.

We would prefer to risk losing a good candidate rather than hire the wrong person.

Mitigating subjectivity

We also work to mitigate the subjectivity of the process. We standardize on a small number of technical problems, and we write out a script to guide the interviewer. We want to give every candidate a fair shake.

But we also acknowledge that every interviewer, candidate and interview is different.

When the answer is No

We want the candidate to feel respected, even when it’s not a match. Programmers have friends! It’s important to maintain our employer brand.

OK, now tell me about the interviews...

Sure thing. Watch the video above.

• 209,420,973 (+61,336,090) HTTP requests to our load balancer
• 66,294,789 (+30,199,477) of those were page loads
• 1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB) of HTTP traffic sent
• 569,449,470,023 (+282,874,825,991) bytes (569 GB) total received
• 3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB) total sent
• 504,816,843 (+170,244,740) SQL Queries (from HTTP requests alone)
• 5,831,683,114 (+5,418,818,063) Redis hits
• 17,158,874 (not tracked in 2013) Elastic searches
• 3,661,134 (+57,716) Tag Engine requests
• 607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries
• 10,396,073 (-88,950,843) ms (2.8 hours) spent on Redis hits
• 147,018,571 (+14,634,512) ms (40.8 hours) spent on Tag Engine requests
• 1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net
• 22.71 (-5.29) ms average (19.12 ms in ASP.Net) for 49,180,275 question page renders
• 11.80 (-53.2) ms average (8.81 ms in ASP.Net) for 6,370,076 home page renders

You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That's due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves. Please don't forget: performance is still a feature. If you're curious about more hardware specifics than I'm about to provide---fear not. The next post will be an appendix with detailed hardware specs for all of the servers that run the sites (I'll update this with a link when it's live).

Read the rest of Stack Overflow: The Architecture - 2016 Edition on Nick's blog here. It's the start of an extensive series of blog posts on Stack Overflow’s technical architecture.

What’s the deal with ad blockers?

At this point, it’s pretty clear that ad blocking is a big deal. A recent study suggesting the advertising industry is set to lose over $22 billion in 2015 alone as a result of ad blockers is setting off alarm bells. That is a LOT of money. Companies are scrambling to ‘fix’ the ad blocking problem, as active users of ad blocking utilities hits nearly 200 million. But it’s not just that tiny stop sign in the toolbar raising alarms. Apple caused a panic when they announced that iOS9 would permit the use of ad blockers, as many see mobile ads are an important piece of revenue for the industry.

First, the ad industry went up in arms over ad blocking, offering suggestions like developing ways to deliver specific ads to users employing ad blockers. Then, they considered going after Apple when they announced iOS 9 would permit ad blockers. Later, they began asking users to turn off their ad blockers as a sign of good faith. That did not go so well for some. Finally, they prevented Ad Block Plus from attending an industry event. Through all of this, those of us at Stack Overflow sighed and shrugged our shoulders. Clearly, many in the industry just don’t get it. Publishers can’t win by forcing ads -- especially low-quality ads -- in people’s faces. But some in the industry do get it. Eyeo (the company behind Adblock Plus) outlined in their ‘Acceptable Ads Manifesto’ some strong ideas for how to improve digital advertising-- not to mention the iAB’s L.E.A.N Ads program. While there is criticism for both of these solutions, the positive takeaway is that powerful organizations are finally moving toward addressing the problem. Reddit is proactive in their public outreach with their ads. Quartz is trying new and interesting ways to engage with users, to mixed reviews. I’m going to toot our own horn by saying that Stack Overflow started doing these things a long time ago via a numerous channels on our Meta sites for both Stack Overflow and Stack Exchange.

Ads at Stack Overflow

The display ads team grew from just two in 2012 to nine today. In that time, traffic on SO tripled, and sales have grown with it. One of the attractions for new hires on our team is the unique relationship we have with our users and the challenge that represents for a salesperson. We entered into an agreement with Stack Overflow users long ago that we wouldn’t subject them to low-quality ads. Think scantily-clad women selling flight deals, weight-loss supplement promos or wacky waving inflatable arm-flailing tube-men promoting car dealerships. But really: anything that doesn’t speak specifically to the Stack Overflow audience is not permitted. We also don’t accept rich media like animated ads, expandable ads, or video, which are the norm for most publishers today. This strict policy means we leave money on the table, but our team wants to protect Stack Overflow from those kinds of ads, as they run the risk of alienating that established trust.

Salespeople and campaign managers on our team do much more than they do at other companies. They’re more involved with a campaign from start to finish. From explaining to a new client how reputation works to working with ad ops to suggest a shift to a new and popular tag like [tag:swift] because it is attracting many new users. This may seem irrelevant to the ad blocking debate, but it’s not. It encourages edification and awareness for people who otherwise would have little or none, which in turn breeds respect and appreciation. This works for a new member of our team much better than simply saying ‘Stack Overflow is important for reasons x, y, and z.’ And they grow to learn over time what IDEs and SDKs are, and it’s remarkable to watch. This acquisition of knowledge really just means that our team cares about keeping ads useful and relevant on Stack Overflow.

We don’t care!

The truth is: we don’t care if our users use ad blockers on Stack Overflow. More accurately: we hope that they won’t, but we understand that some people just don’t like ads. Our belief is that if someone doesn’t like them, and they won’t click on them, any impressions served to them will only annoy them-- plus, serving ads to people who won’t click on them harms campaign performance. That focus on relevance and performance arrives early in the QA process. Whether it’s our sales people explaining that ads must have borders, or our campaign managers checking landing pages to ensure they adequately inform, we are thorough.

An important part of the QA process is ensuring that not just the creative, but the advertiser is relevant to our audience. Every single ad to appear on any of our sites is vetted by the operations team.* We check copy and content on the ads as well as the landing pages. What we repeatedly ask ourselves in this QA process is quite simple: is this relevant to users? ‘Kiss your hosting problems goodbye’ with a provocative image is not something we want on our sites, and I’m sure our users don’t either. The purpose of this heavy QA is to ensure that our users get the most out of their experience on Stack Overflow. The content is helpful-- why can’t the ads be the same?

This ad tries to be relevant, but falls on its face. Also it’s fake. Sorry, future herpetologists.

The Value of Valuing User Experience

User experience is always on our minds. Indeed, others believe that putting user experience ahead of revenue is a path toward long-term growth for publishers. As the chief revenue office of The Washington Post said, “...the product experience has to be every bit as good as the content.” Our approach is in harmony with that belief, as we keep ads confined to certain areas, and we permit users to downvote or close ads that they don’t like.* This allows users control over their experience. QA, curating content and advertisers, and a consideration of the user experience have been successful tools preventing ad blockers from hindering our growth.

The recent resizing of the sidebar from the non-standard, completely made up, for reasons unknown to us 220x250 to the industry standard 300x250 went through thorough research prior to launch. The problem boiled down to this: we wanted to increase the sidebar size, but wanted to ensure that the content wouldn’t be harmed in any way. Bret and the ad server team dug in and investigated screen size of every user across the Stack Exchange network and concluded that only about 2% of users would be affected by the change. As a result, we proceeded confident that our new increase in size would be a net gain for all involved.

Stack Overflow’s mission to make the world a better place for developers remains a central tenet for the Display Ads team. Everyone on our team considers the impact on our users in most of our primary functions. This dedication to keeping content relevant and beneficial to users is what makes the Big Scary Ad Blocking Problem not so big or scary for us. We want advertising to benefit our users and be a resource, not an eyesore. We want advertising on Stack Overflow to be better for our users and advertisers than anywhere else. I’m proud of what we’ve accomplished so far, and I’m excited to see what’s next.

*Special props to the sales support team, as they manage these functions but for the Careers sales team. This QA process used to go through the ops team on the Display Ads side, but it became too much for an army of two to handle. Sales support now consists of seven excellent support specialists.

I think we have to enjoy what we do if we are to succeed.—John Wooden

Looking back on the past year across the network, it strikes me that we are very fortunate that so many people take pleasure in sharing their knowledge with others. Everything we (as a company and as a community) accomplished was made possible by that singular reality.

Since last year’s report, we changed our company name (back) to Stack Overflow and got an epic new logo. Partly it’s simple branding; causal visitors recognize Stack Overflow and other individual sites rather than the network as a whole. Another reason reflects the reality of our (current) goal: building programmer Jerusalem.

This year alone users asked 2.5 million questions and contributed 3.2 million answers on our flagship site. People gave out 16 million upvotes last year and for the fourth straight year more than a million questions were answered to the askers’ satisfaction. That's a lot of programming puzzles solved. Not every post started as a gem of perfection (there were 2.3 million downvotes), but nearly 10 million comments and 3.4 million edits sorted many of them out. (These statistics come from public data. Feel free to look up the results for your favorite site.)

Nearly two years ago we expanded the Stack Overflow community beyond English. This year the experiment paid off: Stack Overflow em Português graduated from beta status. Building on that success, we started a Japanese-language Stack Overflow, absorbed a Stack Overflow in Russian, and Stack Overflow en Español began its beta. Non-English Stack Overflow sites collectively field 159 questions per day. None of this activity seems to have come at the expense of the English site—people just enjoy sharing knowledge using the language in which they are most comfortable.

Have you ever looked at your digital collection (books, movies, music, games and so on) and realized you have titles you’ve never consumed and don’t even remember obtaining? Stack Exchange is like that except all 150 communities prove to be amazing. As a Community Manager, I’m obviously biased in my evaluation—except the quality of these sites has almost nothing to do with us. Instead credit goes to the thousands of core users who write posts, improve them and vote up the best content.

Excluding Stack Overflow, users asked 967,039 questions and provided 1.3 million answers. Over 4 million comments helped clarify those posts and people submitted 1.6 million edits. There were 7.1 million upvotes and 1 million downvotes to rank posts and reward authors with reputation. In addition to the 3 million reviews completed on Stack Overflow, 1.5 million posts were reviewed on other sites. Askers "accepted" 402,647 answers as particularly helpful in 2015. Answers don’t just benefit the people who ask the questions either. Last year the Stack Exchange network (including Stack Overflow) racked up 8 billion page views. Nearly all of that traffic came from people searching the internet at large and discovering an answer on the network. Quantcast ranks the stackexchange.com domain (excluding the trilogy and sites with custom URLs) in the top 50 US sites.

In order to handle that much activity we need a massive data center, right? Well, not really. After serving faithfully for four years, we upgraded the hardware in our "New York" data center. Instead of failing over to our backup data center in Oregon (which was moved to Denver in June), the Site Reliability Engineering team updated hardware live. This requires careful planning and plenty of redundancy: 11 web servers, two SQL clusters, two Redis servers, etc. Most of the time those machines run at single-digit CPU load. We expect the new hardware to keep up with the load for the next four years.

We used to joke that all of our sites should be named "$topic for programmers". But as sites and the network mature, that’s getting less true. Last year the network expanded to 17 new topics, including Woodworking, Music Fans, Health, and Law. Instead of renaming to Stack Overflow, we could have gone with Socratic University: there just aren’t many topics you can’t ask about. Several of our sites, especially the mathematically oriented ones, boast serious academic chops. Papers regularly cite posts from Theoretical Computer Science, Mathematics, MathOverflow and Physics.

A tiny sample of the smörgåsbord of tasty content posted last year:

Gaming wins the title of most viewed question with:

1. How do I deliver a baby? Presumably a fair number of the 867,960 views were to figure out what game the question is about.
2. Why does "effective. Power" text crash the iPhone OS? (Apple, 448,473 views)
3. How to disable the "Get Windows 10" icon shown in the notification area (tray)? (SuperUser, 416,421 views)

The top voted answers?

1. New warnings in iOS9 (Stack Overflow, +812)
2. On OS X, why does sudo ls show hidden (dot) files? (Super User, +378)
3. Leaving intentional bugs in code for testers to find (Programmers, +374)

The top posts by anonymous feedback:

1. Is it 'OK' to use the root user as a normal user? (Apple, +783)
2. How to make Windows 10 File Explorer open "This PC" by default? (Super User, +693)
3. How do you raise an intelligent and happy daughter in a sexist world? (Parenting, +353)

The community team used to imagine that we could individually evaluate every site in detail. But even after hiring four more people we just can't scale as quickly as the network has. Fortunately, our subjective evaluations of Stack Exchange sites, small and large, show they're exceptionally committed to quality. As a result we’ve switched to objective site evaluations (Daniel Kahneman would be proud) and graduated a record number of beta sites:

1. ExpressionEngine
2. Movies
3. Chemistry
4. Stack Overflow em Português
5. Biology
6. Network Engineering
7. Cryptography
8. Code Review
9. Stack Overflow на русском
10. Raspberry Pi

Our designers worked with each of these communities to come up with pleasing designs that fit the aesthetic of each topic. In addition, WordPress Development and Skeptics got beautiful redesigns. Additionally, most sites were updated to use the Less preprocessor, polished for higher-resolution monitors and have new profile pages. This very blog got an overhaul too. We've been hiring designers, but not as fast as our sites are growing. So the following sites elected moderators while awaiting their designs:

1. Blender
2. Computer Science
3. Anime and Manga
4. Magento
5. English Language Learners
6. Japanese Language and Usage
7. Software Recommendations
8. Musical Practice and Performance

After five years of democratically electing moderators, it’s mind blowing that Stack Exchange is still the only major network (with the notable exception of Wikipedia) that embraces this form of self-governance. It’s a strategic advantage we wish more internet communities would adopt. We simply cannot thank our 476 volunteer moderators enough for their patience and dedication.

At "Stack Exchange, Inc doing business as Stack Overflow", we think of our communities as our partners. The company’s responsibility is to provide our users with the very best platform for helping each other and creating lasting artifacts. This year, we plan to roll out some mighty big changes that we expect will improve the lives the world’s software developers. (If you are a programmer, please take our survey to help us know how to serve you better.) As with Q&A, we intend to open these features up to other domains as makes sense.

We aren’t finished with our existing products either. Each week, the community team asks our developers for three or so improvements often selected from the various Meta sites in the network. Some of them are small, such as allowing privileges links to be clicked without JavaScript. But we’ve also fixed highly upvoted requests such as preventing canonical questions from being deleted. JNat put together a report describing the 75 requests directly benefiting either the community or moderators. He also reports 433 community-requested features and 1,267 community-reported bugs were marked as completed in the year.

Our users pay attention to these changes too. Feedback, whether encouraging or critical, reminds me that what happens on Stack Exchange matters to the daily lives of folks around the world. That enthusiasm and industry made 2015 our most successful year (so far).

Punyon started working at Stack Overflow on the Careers team in June 2010 (back when Careers developers were *de*valued associates). His interview process involved a party and a change of pants. You should listen.

So why are we having Punyon on the podcast, anyway? Because of Jobs on Stack Overflow. (We talked about this last podcast, too, and Donna wrote a blog post as well.)

And now, a story about how David was wrong and Jason was right! Basically, we made a wrong decision a long long time ago and built Careers as a completely separate application. When at last we decided to fix this, we thought it was more or less insurmountable, or that it would take years. But then we had our annual company meetup at a hotel in San Diego with weird showers (take our word for it) and everything changed forever... because Dalgas and Punyon put their heads together. The summary: Careers is putting on a Stack Overflow outfit. (Jason does a better job of explaining it, don't worry.)

Then Punyon went home and crammed years worth of work into a week. At least that's how I think it happened. It's live for everyone now, and you can go look at it, and it probably won't break because we did a lot of work to make it perform better for Stack Overflow's scale. Anyway. It's here: http://stackoverflow.com/jobs.

Lest we make it sound like Jason singlehandedly shipped Jobs on SO, David made him recite the list of his co-conspirators from memory: Donna, Dalgas, Nick Craver, Dean Ward, Kirti Thorat, Nick Larsen, Roberta, Ana, Shog, Mike McGranahan... and if you worked on this but aren't listed here you should go yell at Jason and not me.

Anyway, this was a cool project for Jason, who spends most of his time interpreting whale songs (which is apparently what the data team does). It was also cool because he gets to ship it and immediately run away to parental leave - babby #2 arrives on January 8! Congratulations, Punyon family!

So! Is there anything else going on? There was some kind of bash going on at the time of this recording. A Winter Bash, you might say. Also, Stack Overflow en Español is in beta público, Stack Overflow на русском is graduating, and Stack Overflow スタック・オーバーフロー is continuing to flourish. And check out the new design on the Raspberry Pi site!

Thanks for joining us for Stack Exchange Podcast #70. See you next time!

Who Wore It Best?

Most of the fun of Winter Bash is, of course, seeing the actual hats on avatars. So let's kick off with some pictures!

And a very honorable mention to Role-Playing Games SE's BESW for taking the Timey Wimey hat and really running with it!

Numbers, We Want Numbers!

The most commonly awarded hat this year was, of course, Every! Body! Gets! A Hat!, the hat that was automatically given to all Winter Bash participants on a site once any 20 hats were unlocked on that site. A total of 99,388 of them were distributed across the network, to 70,103 unique users. Sadly, that means the hat didn't quite live up to its name, and a couple thousand people did not get to look like Oprah… or sport fabulous mustaches, like this fancy gentleman:

Congratulations to Mathematics SE for being the first site to unlock this hat, less than 18 hours into the event! Also to Code Review SE and Blender SE for technically needing only three users each to get this hat (i.e. at the time that the hat was earned, one user had 16 or more hats, and two other users had enough hats that the first user didn't, filling the number up to 20). The biggest "team efforts" occurred at Aviation SE and English Language Learners SE, on each of which ten users came together to get the site past the 20-hat mark. All in all, 90 communities managed to "get Oprahed."

Not surprisingly, the next-most-common hats were "participation hats," given for doing little more than showing up on a given date: A New Hope was earned the most total times, at 35,329, but Sufganiyot was earned by the most distinct people, 27,050. The most common hat for an actual achievement was Cerro de Potosi, with 21,720 awarded users for earning silver badges; fortunately, our badges don't require any destructive real-world silver mining. Actually, more people earned silver badges during the event than visited on Christmas; Cerro de Potosi edged out O Tannenbaum, which was earned 20,104 times.

Many Explorers (4285, to be exact) used Winter Bash as an opportunity to venture to new sites, where they were welcomed with upvotes by the natives. Some 1994 of those natives may have been designated Greeters as a result.

On the other end of the spectrum, the rarest non-secret hat was Living in the Future, which only 42 people earned, and nobody got more than once. It was doubly challenging, requiring users to have learned enough to solve their own problems and preventing them from custom-designing questions for the purpose of the hat by requiring the question to predate Winter Bash.

People were much more likely to close questions than to reopen them, with 10,015 Melpomenes going out compared to just 1556 Thalias. However, given that the only questions that can be reopened are those that have been closed in the first place, and that many closed questions never get improved to a point where reopening is appropriate, that's not a bad showing.

While many users enjoyed playing along casually, there was a strong corps of "power users" as well, as evidenced by the numerous awards of Specialist Hatsman (earned 1911 times, for earning 11 other hats; a play on "specialist batsman" from the game of cricket) and Fan-hat-ic (earned 20,469 times, for visiting on ten consecutive days; a play on our badge "Fanatic").

Do You Want To Know A Secret? Do You Promise Not To Tell?

Well, actually, at this point, you can tell. There were a total of 13 secret hats this year (or 14 if you count the white and blue Flip Flop variants separately… which is highly recommended, because it results in an even 42 hats for the year).

The first one awarded, and first one the community figured out the trigger for, was Odinson. It ended up being awarded 1817 times, and was triggered by closing a question as a duplicate using the "dupe-hammer" privilege or voting to close a question as such that was later closed by hammer.

The first user to correctly explain Odinson was Undo. In doing so, he earned himself a second secret hat: Archimedes, the hat given out for correctly identifying another secret hat's trigger. Veteran Winter Bashers may remember it being called Eureka in past years. This year's only manually awarded hat, it was earned by 18 people.

Next to fall was Hairboat's Revenge, which was given to any user who replied to everyone's favorite Community Manager, Jon Ericson, by answering one of his questions, commenting on one of his posts or replying to one of his comments. A total of 516 users did this, and it was apparently so fun that many did it on multiple sites; the hat was given out 614 times.

Soon afterwards came 007, for posting an answer that received 0 comments to a question that had 0 comments and reaching a score of at least 7 for the answer. A simple reward for posting a good, clear answer to an equally clear question, it was awarded 402 times.

The final secret hat to be deciphered on day one of the event was Sun Wukong, for posting a meta question or meta answer that attracted at least five upvotes and at least five downvotes. It was a lightweight test for a moderately popular old badge request, and it was given out 165 times.

Day two kicked off with a team of users solving Amazing Grace, another nod to one of our favorite people. By asking a bug-tagged question on a meta site, scoring at least 10 and attracting an answer that also scored at least 10, users could make themselves look like Admiral Hopper. This was one of the rarest hats, as only 30 people earned it (32 total times).

Returning to the realm of fantastical headgear, users could get It's Over 9000! for racking up a total of 9000 views across all of the questions they asked during Winter Bash. This turned out to be another hard one; only 48 people did it, and nobody managed it on more than one site.

After that, things quieted down until Friday, when It's Always 5 O'Clock Somewhere first appeared. It was awarded for asking a question at exactly 5:01 pm on Friday, though it didn't have to be 5:01 in your local time zone, just at some standard time zone currently in use in the world. It was earned 170 times, by 167 users.

That was followed by another break, and then the arrival of the Flip Flop hat(s), triggered by posting or voting on Dec. 22 (the solstice). As expected, it was a pretty common one; 17,531 users got the blue and black version (13,489 distinct) while 17,446 got the white and gold (13,112 distinct).

It took until nearly the end of the event for three more secrets to be cracked. Flying Tiger was a successor to last year's Red Baron. The original trigger was to find a question with a score of -3 or lower, post an answer that reached a score of 5 or better, and bring the score of the question up to 3 or better. This year, the trigger was the same, except that your own votes didn't count. Because of the natural difficulty of the hat and the late date at which the community realized the trigger, only 11 were earned (all by different users), making this the rarest hat in the history of Winter Bash!

Next up was Cleanup Crew, which probably produced a greater variety of trigger theories than any other hat this year. It was earned by deleting ten of your own comments that were left under someone else's post, before the author edited the post. In the end, the crew was 195 users strong, though a few of them pulled duty on multiple sites, bringing the total hat count to 198.

The last hat to be successfully solved, Edward Edwards, was awarded to users who won a bounty even though a competing answer had already met the criteria for the bounty to be automatically awarded. This was another uncommon hat, with 47 going out to 47 people.

And now, what you've all been waiting for: the mystery of the Onion Knight, revealed! This hat sparked debate almost immediately, with most people split between whether it referred to the Final Fantasy job class or the Game of Thrones character (and a couple people piping up for a Dark Souls NPC). Who was right?

None of them! A hint midway through the event directed guessers to focus on the word "onion," but it probably should have done a callback to 2009 and prodded them to do so "as a programmer." The hat was meant to make people think of Tor (now a proper name of its own, but originally an acronym standing for The Onion Router), and evoke the concept of anonymity. Users who received the Onion Knight hat posted questions that received at least three anonymous feedback pseudo-upvotes from visitors who did not have full voting privileges on the site. There ended up being 369 Onion Knight hats, awarded to 361 distinct users.

Mad Hatters

Finally, even though it's not a competition and the points don't matter, this post couldn't be complete without declaring some winners. This year, nobody earned all of the possible hats, but three people tied for "most hats" at 39 each:

Thanks to everyone who got involved for another fun year!

For those who are especially interested, I've posted additional statistics and analysis on Meta Stack Exchange (along with more screenshots).

Here's to a great 2016!

We've been doing this since almost the beginning of Stack Overflow; and still, when the call goes out to our Moderators — "Make your charity selections now!" — the outpouring of enthusiasm for giving back grows stronger with each passing year.

It is a precious gift to have the means of helping someone who desperately needs it. Whether it's an organization providing clean water, a warm blanket, or a light in the dark for families fleeing violence; these charities make it possible for another year of school in a war-torn country, while others are defending our very way of life. There is a lot of emotion and heart-felt concern in deciding which causes most need our help each year. And when violence rocks our biggest cities and millions of refugees have nowhere to go, moderators coming together to "give back" takes on an especially meaningful tone.

But came through, they did!

This year, on behalf of the 483 moderators of Stack Exchange, we were able to make the following donations to charity:

And on behalf of our engineering and IT team, we also like to remember the organizations and tools that make what we do possible:

We are immensely grateful for the incredible year we've had at Stack Overflow. Stack Exchange was conceived out of a crazy idea that people would be inspired to create and share information online in the spirit of peers helping each other — and to see that kind of passion spill out into the real world to help others overcome real adversity is truly heart-warming.

With the holiday season upon us, it is a good time to reflect on what we've accomplished this year. With almost 100 million users visiting us each month, we are literally changing the way people work and learn. Our fellow community members are generously contributing their time, their passion, and their leadership to make these sites worth visiting and participating in.

So as we enter this new year, let's tip our glasses and make 2016 the year to share in our good fortunes. It's a year of new beginnings… so set aside some time to learn something fun, take pride in what you do, work because you love it — and most of all… enjoy!

Cheers!

We believe that all programmers need and deserve jobs they love. Last week, we added a Jobs tab to Stack Overflow in order to help you do just that.

What’s changed?

You’ll no longer need to login to a separate account on a separate site in order to use Stack Overflow Jobs. This means that the family of products we’ve built with the goal of improving programmers’ lives - Q&A, Jobs, and soon-to-be Documentation - will live side-by-side on Stack Overflow.

Tim has already summed up the problem that this decision was designed to solve:

Many of you reading this have great jobs that you love, but many more do not, and don't realize that Stack Overflow has a product that could help get them a much better job. Some might have poked at it, but got lost in the hassle of having to sign up all over again and tell us things they thought we already knew about them.

I already have a job I love. Why should I be interested?

You don’t have to be. In Tim’s words, this is our attitude toward bringing Jobs to Q&A:

It's all there when you need it. For many users, it should be a lot easier having all these things in one place. For those who only choose to use Q&A, or Docs, the rest will be waiting patiently out of the way.

If you are interested in a new job - and based on an experiment we ran earlier this year, we learned that 40% of you are - we’d like to help you. Because even though the demand for skilled programmers is on the rise, only 1 in 3 of you told us “I love my job.”

In the last few months, we’ve focused our efforts on several key features designed to help you land the job you love.

1. Better job matches

About a year ago, we began a long-term experiment that used our machine-learning technology to surface more interesting jobs to our users. This drove a 40% increase in overall applications, which was awesome - it meant that we were making it easier for you to find and apply to jobs you found interesting.

This experiment taught us that we can help the programmer community by showing relevant jobs without asking anything of the user. But how could we make the experience even better? What about specific criteria that you’re looking for? How could we better empower you in your search for not just a job, but the right job?

We believe that we can serve up even better jobs if we allow you to define your own preferences for important things like tech you’d like to work with, where you’d like to work, and desired compensation. Our matching algorithm uses this information to sort the latest jobs for you, putting the best matches on top.

To start seeing jobs that match your criteria, just login and visit the “matches” tab.

2. Better job listings

Last year, we asked you what you care about most when looking for a new job - and this is how you responded:

We’re working hard to get more companies to provide this info in their job listings. So far, we’ve focused on tech stack - and today, about 80% of our jobs offer tech stack data. Now we’ve set our sights on compensation. Currently, about 30% of our job listings provide compensation data - but we’re working hard to bring this closer to 100%.

3. No recruiter spam

If you’re a programmer, you’ve probably never tweeted this:

Because chances are high that you’ve received a message like this:

My associate forward me your contact info. and the hiring VP of Engineering is interested in your technical background for a senior position. The company I’m working for is very successful, profitable and well funded by several top VCs. Also can you please email me your current resume in word so I can forward it to the hiring VP of Engineering so he can review it, the resume he has is a bit dated... The compensation is excellent with great stock options, bonus, 401k and comprehensive package. I can call you with all the details on the position and company, please let me know the best # to call you at.

We’ve taken a few measures to help ensure that Stack Overflow users only receive personalized, high-quality messages from companies - and of course, only after you’ve given us explicit permission.

1. Our Job Search Status feature gives you full control over who is allowed to talk to you, whether you want to hear from companies right away or not at all.

2. We limit the number of outstanding messages that a company can send. This feature helps us control generic, copy-and-pasted messages to candidates, while encouraging companies to send messages that are relevant to the unique interests and background of each user.

3. We refund company subscriptions when we receive reports about bad behavior, and all of our job listings are required to disclose a company name. Furthermore, we seek out opportunities to work with developer-friendly companies that would be appreciated by the Stack Overflow community.

Okay, but how does this affect Q&A?

As Jason neatly summed up:

That ^ is about the extent of the changes to existing Stack Overflow. There's nothing else changing about Q&A. We aren't going to put jobs that look like questions in the middle of a question list, or jobs that look like answers in the middle of the answers for a question, or any other dark pattern garbage. The Jobs tab will be there for you should you need it, and otherwise Stack Overflow is essentially as it was.

We also won’t start hassling you about things that aren’t relevant to your interests. That means we’ll only push relevant Jobs content to users who’ve indicated to us that they’re interested in looking for a job. For everyone else, it’s there when you need it.

Stack Overflow Jobs is now live

Each of us has a different dream job. Some of us want to work quietly from home; others want to build products in offices filled with colleagues and free perks. Some of us want to make more money, while others want to push the first line of code on a product that will eventually be used by millions. Whatever it is that you’re looking for, we hope that your search starts with Stack Overflow.

Starting now and going until the end of the day on Jan. 3, 2016, you'll once again be able to earn and show off hats for all sorts of things you're already doing across the Stack Exchange network. As in previous years, we're rolling out an all-new array of hats for this year's event. (For those who are wondering, this is entirely because we on the SE team love our communities and think you deserve the best, and not at all because we forget where we store the old hats every year.)

That means we owe another big thank you to amazing freelance designer Elias Stein, who deftly handled the conversion of all hats from crazy vague concepts into beautiful digital reality for the third year in a row, and our very own unicorn lord balpha, who once again worked tirelessly behind the scenes to perfect the hat distribution process.

Hats, for those who don't know, are sort of like badges, but better, because you can "wear" hats on your avatar, displaying them wherever your avatar appears, network-wide! (And thanks to a labor of love by Brian Nickel, that includes the iOS app this year!) The triggers for hats are a little different than the triggers for badges; to find out what you have to do to get some headpieces, check out the Winter Bash mini-site. There are 28 total hats you can earn over the next few weeks… that we're telling you about. How many secret hats are there this year, you ask? You're on your own. We're not spilling the beanies.

After you've earned some hats, you can visit your profile on any site to choose the hat you want to wear (or simply admire your own personal hat rack). Just click on the bobble hat adorning your badges section to bring up a dialog.

(No, you can't wear the bobble hat yourself. Your badges would get cold!)

Once you've picked a hat, you can resize and reposition it in the selection window to suit your avatar. Last year's example image for this was so perfect that it just has to be reused:

Finally, you don't need to worry about tracking all this stuff yourself. You'll get notifications about new hats via a special, Winter-Bash-only top bar inbox: .

Of course, if you think all this is weird and don't want any part of it, that's okay, we won't judge you (much). You can opt out of the event by clicking on the snowflake icon in the top bar——and then the "I hate hats" link at the bottom left of the box that pops up. (NB: the reverse is true on Stack Overflow; fans of hats on SO will have to go through the same procedure but click a link to opt in at the end.) You're welcome to change your mind about wanting hats at any time during the event.

Just remember, all the hats will vanish again after three weeks. Now go! Other people out there are already working on their degrees²!

1: As in the past, tradition defeated accuracy in the naming decision. Hopefully some of our summertime audience will be at least partially mollified by the fact that the Winter Bash site will be available in Portuguese, Spanish, Japanese and Russian this year, thanks to the efforts of our international Community Managers.

2: The University of Winter Bash has not been accredited by any organization recognized by the Council for Higher Education Accreditation or the United States Department of Education. Yet.

In part 1 of this blog post I talked about getting a better job by building awesome stuff. In this part, I'll talk about how to communicate your awesomeness.

Write for humans

Applying for a job normally involves writing a cover letter and CV. The whole process can feel very impersonal - filling in online forms, typing words onto a screen, hitting the Submit button and maybe never hearing anything back. Yes, it sucks. But remember where your words will go, as you send them off on their journey. They will be read by another human being.

Sometimes I've seen people applying for a job who must have thought that their cover letter and CV would simply be fed into some kind of computer that would check their skills off against a list of requirements. While it's true that some companies have systems which automatically check your CV against a list of keywords, you don't want to optimise your job application for their simplistic software.

Software is not going to get excited by your CV, but a human should. Unfortunately, human beings are flawed - they sometimes come to irrational decisions, they are clouded by emotions, and they get bored. Humans like stories.

So tell your story. You want to make that person on the other side interested in who you are. You want to make them excited because they've found a promising candidate for the job they're trying to fill. You want to give them a clear idea of what you're all about. You want them to be on your side.

Who are you?

I've been involved in recruitment a few times, both at Stack Overflow and elsewhere. When I'm reading your cover letter and CV, I'm trying to answer one question - "who are you, and why should I care?". It might sound harsh but that's what it ultimately comes down to, especially when you have a big pile of applications to go through.

There is no "correct" way to write a CV or cover letter - you can read lots of advice about structure and formatting, but the sole purpose of these is to answer the question. If you fail to answer it, you'll have a hard time getting a great job.

To answer it, you need to communicate a story about yourself. Who are you? What have you done that's interesting? What excites you about the job you're applying for? How can you convince somebody that you're capable of doing the job?

It's a story about you, so write in your own voice. Don't waffle - anything that doesn't add to your story only detracts from it. Get to the point and keep it simple.

You want to leave the reader with a clear, convincing message. They should be left with a clear feeling that you're obviously a great candidate for this position.

What we're looking for

So, what things should be in your story?

At Stack Overflow, when we hire developers, we're looking for people who are passionate about coding, have an appropriate level of experience (both breadth and depth), and who Get Things Done. Other companies will have their own criteria, but if you're the kind of person who is smart and gets things done, and you want to work with other people who are smart and get things done, then your cover letter and CV should be all about that, whichever company you're applying for.

How do you convince us you've got what it takes? We want to see that you're passionate, experienced, and get things done, so you should just say that, right? Wrong. You don't get to inject thoughts into people's heads just like that. You have to give us the evidence that leads us to that thought. You want us to come up with the thought ourselves. If you tell us what to think, it's not just patronising but boring.

Here's the kind of thing people write in cover letters all the time:

As an outstanding senior-level software engineer with over 8 years of experience using Microsoft technologies, I believe I possess the skills, qualifications and vital experience necessary to make a very profound contribution to your business operation. In my current and previous roles I have delivered substantial improvements in creating high quality systems and streamlining operations, resulting in improved revenue, increased profits, and a high rate of client satisfaction.

This is just tiring to read. And it doesn't even say anything! There is no actual information in there, just a list of things this applicant wishes us to think. Tell us an actual story, give us the evidence, and let us come to our own judgements. If I read something that makes me think "this person must be really passionate about coding", that's a lot more convincing than simply telling me you're passionate about coding.

It all boils down to that classic writing advice - "show don't tell".

Be interesting

Chronology is not the most important thing, so you don't need to start at the beginning of your story. I often see people start cover letters with things like:

I started computer programming 18 years ago as a hobby ...

Sure, this is the first thing that happens in the story, but it's not the most important thing, and it's not a great hook. You know how movies tend to start with something exciting happening, and then fill you in on the background later? Try doing that instead. Hook me in with something interesting and unusual about you. A lot of programmers started programming as a childhood hobby, so lead with something else.

Don't waste time on things we already know

Another common way people start cover letters:

I recently came across your job posting on your company website for the “Full-Stack Web Developer” position. After reviewing the details of the position I found that the requirements necessary and my experience could be a great fit if given the opportunity.

This doesn't tell me anything at all. It's even less interesting than why you started programming - you're just telling me you're applying for a job. I knew that already. You think you fulfil the requirements of the position - well, of course you do!

Don't waste time on things we don't care about

There's no need to give us your complete life history. One applicant included this on their CV:

Drove dump Truck, operated machinery, all manner of physical construction work.

What did they think they were adding by giving us this information? You don't need to include every detail of every job you've ever done. You don't want to distract from the overall story you're telling.

An example

Here's an example of a cover letter that worked - it's my own, from when I applied to work at Stack Exchange almost two years ago.

Looking back at this now, what's interesting is that it's not brilliant. At all. In fact it's embarrasingly short - I clearly didn't spend as long on it as I should have. However, it does demonstrate the points I'm making. The first sentence just gets straight to the point, saying who I am and what I'm all about. There's a link there to all my open source code so anybody can go and look through that. It explains why I'm applying now, to this company, and why I'm excited at the opportunity.

Completing the cycle of awesome

That's it! In part 1 of this blog post, I talked about breaking into the "cycle of awesome" by building awesome stuff. If you build awesome stuff, it's a lot easier to tell people how awesome you are. You're much more likely to be passionate and excited about stuff you've built yourself, so it's actually easier to write your story - it's much easier to write about things which you care about.

Now you can complete the cycle, and find your way to an awesome job. It's not the easy way - there is no easy way to be awesome - but it is possible, and you can do it.

By the way, we're changing everything. We should talk about that! First, let's review: you may remember how the last time we had a podcast, we talked about Documentation. It's now in private beta, and you can sign up.

So here's the new stuff: we're working on something we're calling integration, or possibly unification. The legend has it that once upon a time, Stack Overflow was invented, and so was this bolted-on Careers site where programmers could get jobs. But they were two separate things, and if you wanted to get a job through Stack Overflow, you had to go to a whole different website and make a whole different account. Our unification project will move all of that stuff back into the Stack Overflow fold, making it an unobtrusive part of your day-to-day experience on the site. (Which you can just ignore if you aren't looking for a job.)

We asked a sample of people signing up for Stack Overflow today if they were actively searching for a new job, not searching but open to opportunities, or not interested in jobs at all. We found that of those who answered, 23% were actively looking for jobs and 38% were open to opportunities. (There's a point here, but we digress to talk about Twitter's new hearts.) Oh, here's the point: 61% of new Stack Overflow sign-ups might be interested in the right new job. What all of this means for the average Stack Overflow user is that you no longer have to bother to keep a second profile on a separate site. Oh, and if you're at all interested in finding a new job, we want to be able to help you look for one in--here's the kicker--a way that isn't awful.

We've been thinking about ways we think we can continue to help help make developers' lives easier. We're not about programming on a boat or making designer shoes for programmers. We're just about helping programmers learn, improve, and share their knowledge, and that's why Documentation and Jobs feel like natural fits into what we're already doing well with Q&A.

[Producer Alex is now eating delicious seaweed snacks. Further bulletins as events warrant.]

So! By now we've talked about integration a little bit on MSO. We're trying to take the pain out of the Jobs piece as quickly as possible while we're building out these other features.

But wait. Joel makes an excellent point: why are we working on all of this new stuff instead of going back and fixing all of the problems with Q&A? Well, the answer is... why not both? Let's be clear: this is not about any shift in our focus on Q&A. Q&A is the thing that we're confident that we've done really well, and it's what our community is built on and uses to teach a new generation of programmers in a new way. Q&A is the killer feature, and it will stay that way. You know what? Just listen to David for this part, because my attempts to summarize his impassioned monologue are coming off cheesy and/or arrogant, and he's really nailing it. (Don't tell Jay I complimented David; he'll kick me off his team.)

Okay. Moving on! Teams is in private beta and you can sign up to participate if you want, or just check out the teams that have already signed up. (So far, NetGuru is winning the non-competition.) Tune in for more Teams talk. We're gonna get a lot of stuff wrong at the beginning, like we always do, so we look forward to community input on how Teams should evolve.

Here's the post Joel is talking about when he says "Harley Davidson Bike Buckle" a bunch of times. Also, Joel is a hypnotist. Also, we're done now, so thanks for wasting another hour of your life listening to the Stack Exchange Podcast!

For hiring developers or for developers looking for jobs, we’re able to show jobs to the right developers based on the content they look at on Stack Overflow. This behavioral targeting is more accurate than profile-based targeting, and something that Stack Overflow can uniquely do to provide the best experience for both candidates and recruiters.

When you post a job on Careers, we show the job on Stack Overflow, the world’s largest developer community. There are lots of different kinds of developers out there. Providing us with some descriptions of the kind of developer you are looking for helps us advertise directly to the right people for your company.

The targeting screen

On the targeting screen you have a few options for how to describe the role you need filled.

Developer types

Developer Types is the most general role: “Full Stack Developer” and “Mobile Developer” are examples. This is the most impactful feature you can select. Although two selections are allowed, you are almost always better off just choosing a single option here. Only if your job requires developers to be very proficient in multiple roles will two selections help. If your job sees a second role as a benefit or you are willing to train for it on the job, selecting just the more important one will help find more qualified candidates.

Technology ecosystems

In this category you will find stacks or collections of technologies that roles might require. You might have heard someone say “I’m a Node developer,” or “I’m an Android developer.” They are describing the set of tools with which they are most proficient – and we can target that directly.

In addition to ecosystems, there are many complementary tools listed in here such as “SQL Server” or “Cloud.” While these are not the primary stack, they are helpful to know. Selecting any choices that apply here is encouraged.

Region

This allows you to specify the list of countries in which we should advertise your job. We only show your job to developers in these locations. Developers browsing Stack Overflow from anywhere else will not be able to see your listing and we will not show ads for your job to them. Use this if you are looking to recruit developers from specific countries.

Potential targets

As you modify these high level targeting features, you will see the Potential Targets widget on the sidebar update. This number is a rough estimate of the size of the market for developers you want to hire based on your targeting criteria.

In this expanded details view, you can see a breakdown of the market. Total targets are the developers in the area around your Targeted City. Close matches are the developers who match any of your targeted criteria, and strong matches are the developers who match most of your targeting criteria.

If the number of Potential Targets drops too low (depending on location, there are just very few developers in some of the more remote areas of the world), then you are made aware of that up front with this tool. You can alter your targeting criteria or consider offering flexible work options such as allowing remote workers to increase the size of your targeted market.

How we know

Nearly every developer in the world uses Stack Overflow to find solutions to the coding problems they encounter in their daily lives. That’s important. Stack Overflow sees what developers actually use, not what they say they use on resumes and online profiles. There are no other companies in the world with direct access to this quality and quantity of data on developers.

Our advanced targeting technology makes use of this data to determine the tools and roles each developer is proficient at. As developers use Stack Overflow, we show them ads matched using your job’s targeting criteria. Targeting your jobs leads to more qualified candidates applying to your job as well as a better, more relevant experience for Stack Overflow users.