Any Questions for Us?

There was an article yesterday about a software developer who had been turned down by 38 companies and went through 120 interviews in a 2-3 month period, and then finally was hired.

It was framed as an uplifting story about this person's determination that he finally convinced a company that he was worthy of being hired.

I sometimes feel that stories like this perpetuate the "we're up here / you're down there" mindset that some folks take into interview situations.

I'm not the first person to say it, but I believe that as a job candidate, you should scrutinize your interviewers at least as thoroughly as they're scrutinizing you. Many articles about interviewing advice will tell you to ask questions, because it shows interest.

Um...no.

I'm trying to decide if I want to work here or not--that's why I'm asking questions.

CX: Candidate Experience

I’m not the first person to compare technical interviews to hazing—you know, those painful and arbitrary rituals that fraternities and sororities put pledges through because well, they had to go through them, too.

Hiring is hard; we all know that. But just as empathy is at the core of user experience, I believe it’s equally as important to how you treat candidates that are interviewing at your company.

I’m always heartened to read articles and blog posts by software people who are trying to replace the punishing whiteboard hazing that so many tech companies put developer candidates through.

In a recent blog post, Phil Calçado wrote about going the extra mile to improve the candidate experience while hiring at SoundCloud:

But we’ve also done something else. Something that would improve the candidate experience…

With the problem description, we sent to candidates a functional test suite, a binary that when started would try to connect to the candidate’s server implementation, open lots of sockets, sends lots of messages, and verify the results against what the problem description stated. The candidate was instructed only to send their submission once it passed the functional test on their local box.

Now, there is some controversy about whether asking candidates to code side projects for your company at no cost as part of the hiring process is appropriate. But I just wanted to highlight here by choosing the “on your own time” programming exercise as an alternative to the whiteboard grill-session, there are still ways to improve the candidate experience. I’m glad that people like Phil are actively working on this problem, and I hope to highlight on this blog other similar efforts that I come across of people consciously applying empathy to improve the candidate experience.

What Does a Tech Company Look Like?

Many software shops are desperate to mirror the popular notion of how these places operate: loud, boisterous bullpen type arrangements, whiteboards all over with various contrived things on them, street lights flashing the current iteration progress, desks littered with crazy toys and blimps and toy guns, and various nerdly hijinx. It is, in every way, cargo culting, putting the image of how it should work against the actual of how it works.

It looks like what many outsiders think a software shop should look like, all those geniuses doing their genius thing.

Impress investors. Impress potential hires. To the latter most will say "oh no! That wouldn't impress me", but the truth is that real work in this field occurs in the most boring looking way possible, so we all like to imagine that a vibrant office will be an amazing new experience. But in the end we're still wrangling code all day.

- Commentor corresation on Hacker News

Steve McConnell wrote in 2000 about “cargo cult software engineering”—the idea that software organizations often copy superficial aspects of other organizations they admire, wrongly believing that they are the cause of the company’s success.

Here’s a startup that works out of a garage because it’s too broke to afford an office:

Right now, somewhere in downtown San Francisco, a large tech company is designing its swanky new office space:

 

I guess some never leave the garage.

Humane Offices: MathWorks

MathWorks is a name that keeps popping up here and there when I read discussions about tech companies that respect the need for quiet and privacy amongst their software developers.

With headquarters near Boston, MathWorks is the maker of the venerable mathematical computing products MATLAB and Simulink.

I was tipped off to MathWorks when someone left a comment on my post, But Where Do People Work in This Office?:

Here at MathWorks everyone gets their own offices with walls and doors and a small desk and chair for people visiting your office! I love it, it’s very peaceful to work.

Employees mention the private offices in reviews on Glassdoor:

Private offices: collaborate with a co-worker on the whiteboard/computer without interruptions.

- Current Employee - Software Engineer in Natick, MA

Private offices, great tools, many talented colleagues, plenty of opportunities to learn new skills.

- Current Employee - Principal Software Engineer in Natick, MA

From a comment thread on Hacker News about private offices for programmers, MathWorks comes up again:

…the general goal is an office for every full time salaried (non-hourly) employee.

In a thread from the /r/cscareerquestions subreddit:

"MathWorks...[is]/[was] famous for providing private offices to workers."

Check out the open positions at MathWorks here.

Late Night Heroes

This post from Grand Rapids locals, Atomic Object, documents a phenomenon in the software industry that is particularly insidious as it can demotivate good developers.

No one thinks back to the root cause of the pain they don’t feel. There are new problems to solve, new features, or new projects. It’s very easy to miss a critical element of what got you to this point in the first place. Think about it. When was the last time you stopped and appreciated a piece of software that’s run smoothly for years? 

Ironically, less disciplined developers who commonly let bugs out into the world may be more likely to get the technical kudos. After all, they’re performing the software heroics of late night, last-minute debugging and patching. It’s their technical ability that a customer is held hostage to and rescued by. ...these efforts are highly visible to customers. I suspect some developers even get addicted to the opportunity to be a hero and save the day through their technical prowess. This isn’t really in the best interest of customers, but if you’ve headed down the path of undisciplined, unpredictable development, you’re probably thankful for the effort. 

Heroics are great when they’re needed, but it sure is better to not need them at all.

While overtime and late night heroics are highly visible to managers and non-technical higher-ups as extraordinary effort, one might step back and ask, "Why were these efforts necessary in the first place?" Quiet, consistent quality is distinctly un-sexy. It takes place at 2 PM on Tuesdays, not 2 AM on Saturdays.

Why is our software so buggy, our progress so unpredictable? Let's strive to eliminate heroics from our process, not encourage them.

When 10x is 0x

There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x.

- Erik Bernhardsson

Ah, the 10x Engineer™.

One of the most frustrating things I’ve witnessed in my career is smart developers working on stuff that just doesn’t matter.

Blistering progress toward a goal that does the business no good, is not progress at all. In fact, when you consider the opportunity cost, it’s negative value.

Perhaps more important than raw technical ability is a finely-tuned intuition about where to aim that talent.

Humane Offices: SAS

Located outside Raleigh, North Carolina, analytics software maker SAS is the largest privately owned software company in the world.





SAS is consistently ranked as one of the best places to work in the United States and is well known for its workplace culture and world-class employee benefits. One particular aspect of its culture might stand out to readers of this blog.

One example of employee-centeredness can be found in the fact that each employee has his or her own office. There are no cubicles. While SAS Institute describes this as a way to maximize productivity, it also fits in with the operating principle for [CEO] Jim Goodnight: that’s how he would like it were he “just” an employee.  - The Wharton Work/Life Roundtable

Everyone gets a private office. We're not talking cube farm here, either. These are real offices with doors that can be shut. All of SAS' 13,700 employees are encouraged to be creative and make their work space fun. A SAS senior communication specialist has turned her office into a shrine to Elvis with a velvet Elvis painting and a life-size standup of the King.  - The Huffington Post

SAS has incredibly low employee turnover of 3-5% annually, when the software industry average is 20-25%. If you want to get in the door (and get your own door), apply here.