Sunday, April 10, 2016

Tips for Interviewing at Software Companies

Here's another blog post in the "Rich goes off the rails and reveals a bunch of shit he's learned over the years while working as a corporate programmer" category.

Companies Must be Continually Reminded that the Interview Goes Both Ways

Many corps have an internal company culture that places the company in the superior position relative to job candidates. These companies feel they can choose who they want from a seemingly endless variety of potential employees, so who cares how they're treated right? The reasoning goes "we'll just hire someone else" if a candidate pushes back.

We need to collectively turn the tables on companies like this. Let's give them a powerful form of feedback. Let's exercise our right to "route around" bad companies and not apply or accept job offers from corporations that act like we are replaceable cogs. (Alternately, let's all talk between ourselves and collectively compare notes and boost our compensation rates and working conditions. They can't stop us!)

I'm hoping this blog post will help make people more able to discern the good companies from the bad ones. For the record, I do believe there are many good companies out there, but for every good company there seems to be a bunch of bad ones.

Remember: We Write the Software Which Runs the System

Here's a key concept to internalize: We write the software that literally drives this entire system. Food production and distribution, electricity production and distribution, telecommunications, government, finance, trucking, planes, etc. It's all ran by computers one way or the other, and we write the code that makes these computers work. Without computers this entire system crumbles into the dark ages.

As time goes by more and more of the system is becoming automated and computerized. This means we as programmers collectively have the power in these relationships with corporations, but we haven't effectively organized ourselves or figured out how to best exercise our power yet. We now have the technology to instantly communicate between ourselves, which if we all start using it can lead to massive changes in a relatively short period of time.

Interview Tips

Some corps are exquisitely designed to extract as much "value" from you as quickly as possible, your health and sanity be damned. Above all, I want to help other programmers avoid places like this. When applying for a position at a software corp, keep these things in mind:

- Follow your instincts.

Ask a lot of questions. Learn how to interpret body language. Are you treated with respect? Are your questions answered in a straightforward way?

Remember, the hiring pipelines of these companies are tuned to take advantage of the macro-level psychological profile of "typical" programmers. Get educated, fast. These companies are not your friends. They will try to get into your brain and "bend" you psychologically in order to make you conform and "fit in" to their brand of corporate utopia.

Trust your gut feelings during the interview! If you feel disrespected or not taken seriously, don't ignore it. It's not just in your head. Run away! You won't grow there, and it'll be a dehumanizing place.

- "You need us to achieve success, you are nothing so follow us!"

Run away fast! I've seen this tactic applied against dozens of developers after one company collapsed in Dallas. Sadly, it worked with a bunch of people and they ultimately all got screwed.

- Deeply analyze any critique given to you during the interview

Sometimes critique that seems merit-based is really bias in disguise. It's very important that if you get bad feedback, you stand back and think "Is this true? Or is there just something wrong with this company (elitism, sexism, they just didn't want to hire you, etc)?"

- How much is your time worth?

Ultimately, you are selling your time for digital digits in some bank computer somewhere. You will not get this time back, period. It's worth a lot, probably much more than you think.

How much income does the company actually make given your time? Some companies make millions of dollars per software developer, yet pay only a fraction of this to you.

Remember, this is a market and market principles apply here. By increasing our communication levels and giving feedback to the market (by routing around bad companies, demanding higher pay during negotiations, pushing back during interviews, etc.) we can collectively raise our salaries, compensation packages, and improve our working conditions.

- Are you gambling your time away trying to get your stock "lottery ticket"?

In this scenario, you're willing to be underpaid, but you're hoping the company will sell out in X months or years and make you millions. Just beware that this is a form of gambling with your time and finances.

I've seen a few companies exquisitely exploit and continually encourage this "gambler mindset" with its workers in order to suppress wages. Be careful!

- Admit that you probably suck at negotiating

Generally, in my experience programmers make horrible negotiators. The most important thing is to approach the negotiation with the proper mindset. They need you, not vice versa, and they probably have much more money (and the capability to pay you) than you suspect.

Some companies are full of sociopathic monsters whose job description (and honestly, their corporate duty) is to exploit you as much as possible.

Learn to recognize the signals. They will try to get into your head, quickly build a mental model of you, then play off your willingness to not rock the boat or be seen as a "troublemaker" to the corporation. They will find subtle ways to threaten you, if needed, to keep you in line.

Narcissists can be especially horrible to work around, especially when they are in management. Learn the signs.

"Elite" - Programmers willing to work endlessly in sometimes horrific conditions are labeled "Elite". Yes, we have a very screwed up system here, where people who get exploited and are worked until exhaustion are labeled "Elite". Avoid companies like the plague that use this word in their job descriptions or recruiting emails.

"10X programmer" - Someone who hacks up some shit (sometimes actually using stolen ideas), and then depends on other practicing programmers to do the actual work of making these (sometimes very sub-optimal) ideas actually shippable. These programmers tend to publicly take full public credit for things they only partially worked on or thought up. We don't need more of these "10x" assholes, instead we need to completely reboot our programmer culture so the very concept of a "10x'er" is totally alien.

"No bosses" - This recruiting shtick from 1999 means there are many powerful bosses in hiding, and/or that everyone is effectively your boss. Also avoid companies that advertise this like the plague. It's a recruiting tactic designed to attract programmers who had bad bosses in the past. (Believe it or not, there are many very good managers out there!)

Also, without managers, you will be directly exposed to the many wolves out there who can make your programming life a living hell. A good manager will shield their programmers from endless bullshit and insanity.

"Crunching" - This means the company externalizes the cost to your health and sanity of working endless hours. They may have bad planning, or bad business models, whatever. Avoid companies that crunch endlessly like the plague unless you just don't care about your health.

"Scheduled Crunch" or "we occasionally crunch" - Again, any company that schedules crunch just doesn't understand or care how to plan, or is ignoring the cost of working crazy hours on your health.

- Ask: Does the corp own all your work?

Can you work on stuff at home, like open source software or your own commercial software? Avoid companies like the plague that don't let you work on your own stuff.

- Ask or check for insane contract clauses

Is there a non-disparagement clause? If you quit, must you wait X months or whatever before you can work on something else? Push back and avoid companies that do questionable shit like this.

- Who contacted you first?

If the company reached out to you first, did a recruiter contact you, or an actual programmer at the company?

Ideally, a real-life programmer reached out to you. Only a programmer working at the company can genuinely answer your questions and give you a real idea about the working conditions and types of problems you will be working on there.

Remember recruiters are just part of the company's "hiring pipeline". The pipeline is basically "X Programmers In -> Y Programmers Out". You are just a replaceable number to these companies. Recruiters will say anything in order to get you to sign the dotted line.

- Is there a whiteboard interview?

Is there a whiteboard interview? Push back and say no. I've helped hire at several successful companies (easily over 100 people over the years) that didn't use whiteboard interviews at all. Anyone saying "this is just the way things are done" doesn't have perspective and is part of the serious problems our industry has.

After taking and giving way too many of these whiteboard interviews, I think they are total fucking bullshit. Whiteboard interviews test a candidate's ability to scribble uncompilable pseudo-code on a chalkboard (!) while being faced down by multiple adversarial programmers. (Who in some cases would rather be doing anything else, and who don't want more internal programmer competition in the first place!)

Some companies give programmers whiteboard questions from various books verbatim, like this one. This is just downright ridiculous, a waste of time for everyone involved, and a total demonstration that the process is completely bogus.

Whiteboard interviews are extremely stressful to candidates. I've seen amazing programmers just lock up and become dysfunctional in these conditions. We are testing candidates for the wrong abilities. I refuse to take part in any more of this insanity.

Some programmers use these bogus hazing ritual-like whiteboard interviews to help drive down the applicant's ego while simultaneously driving up their egos. This is a huge red flag -- avoid these programmers and the companies who employ them.

- "We only hire senior programmers"

Let's translate: We don't help train new programmers. The phrase "programmer empathy" isn't on our radar here. We probably treat each other like complete trash. We actually assume you are an idiot until you battle your way into a position of respect. Avoid companies like this!

Remember, all senior programmers at one time were junior programmers.

- What's the company's culture?

Ask lots of questions from people who work there. Is the official company message great, but when you pull programmers aside they actually hate working there? Search the web for reviews of the company, search linkedin and find former employees and ask them about the company.

- Talk to the executives
Are they sociopaths? Raging narcissists? Ask them what they look for in programmer candidates, and see how they respond. Do they treat you with respect?

I've known execs who thought programmers were literally crazy, and trust me the companies they ran were not healthy.

- Look around the office
Little things can give you a lot of information. Is the office a mess? How much space and privacy do employees have? Is the environment quiet or loud?

- Does this company give proper attribution for ideas it uses?
I'm throwing this out here because I've noticed one very well known VR company outright steal ideas from its competitors or academics working in the space. Explicitly ask the company about its attribution policy.

Personally, I will never involve myself in any way with people or corporations who outright steal ideas for personal or corporate gain. (I can't believe I have to even say this. We have fallen to the level of stealing and re-branding ideas from each other!)

- Master your fears
What do you fear? Recognize it and look past it, because these companies are designed to exploit your fears and use them against you as a weapon.

6 comments:

Good work Rich. There's much truth in there. I recognize one company in particular in many of those...

For negotiating I think that there are two things that programmers can do to greatly improve their salary when hunting for a new job:

1) Talk to your coworkers and peers and ask, bluntly, how much they make (salary, bonus, stock grants, *everything*) and tell them what you make. Most people will share when asked and this fights in information asymmetry problem.

2) Interview at multiple companies, try to get multiple offers, and make sure that the recruiters you work with *know* that they are competing against other companies. Multiple offers reinforces that you are worth hiring, and it forces them to compete instead of lowball.

Great advice. IMO, what we all need to do (like right now) is compile spreadsheets of wages, compensation packages, etc. We have the tech, let's use it! Everyone needs to start trusting each other a bit more and just compare notes. We have nothing to loose and the gains are potentially massive. Let's push back.

What do you think about programming exercises to be handed in before being invited to an interview?

I personally am not sure about that - it certainly has several advantages, like* it's better than whiteboard-coding or similar, because the applicant can do it alone, at home, without much time pressure, they can look up things etc, like they would when actually working* the employer gets an idea about the applicants coding skills (especially relevant for novices, I think) * you have something to talk about in the interview (let applicant explain the code a bit - also to make sure they wrote it themselves; discuss design decisions, ...)

On the other hand, it takes up the applicants time: an interesting piece of code will take at least a day to write and test and polish.If someone is looking for a new job (while still working full time at the old one) and applies at several companies and has to write code for each, that's probably pretty stressful.

This is what I did at one company, and it worked surprisingly well. On the flip side, these tests can take a lot of time for a candidate. It's effectively asking for free work. What if the candidate is already working one or more jobs or whatever? If the test is too long it could screen out good candidates who really don't have the free time.

Also, I had one candidate who messed up an intersection test routine in our take-home test. I could tell that he was interviewing at multiple companies and was juggling a lot of things at the same time. He did great in our on-site interviews, so we hired him anyway. He turned out to be a good programmer who immediately contributed to the team.

But what is your opinion on stuff like codility? As a candidate for a senior engine developer, I have been asked to solve stupid stuff like: prefix sums, arrays, stacks and queues, maximum slice problem etc. All exercises with complete code that fully controls for edge cases and very large values in a maximum of 30 minutes. I don't know if I should take the test since I find it insulting... Nobody is asking me about architecture, about previous projects, nothing. Just exercises like these: https://codility.com/programmers/lessons/11-sieve_of_eratosthenes/

Good work Rich. There's much truth in there. I recognize one company in particular in many of those...

For negotiating I think that there are two things that programmers can do to greatly improve their salary when hunting for a new job:

1) Talk to your coworkers and peers and ask, bluntly, how much they make (salary, bonus, stock grants, *everything*) and tell them what you make. Most people will share when asked and this fights in information asymmetry problem.

2) Interview at multiple companies, try to get multiple offers, and make sure that the recruiters you work with *know* that they are competing against other companies. Multiple offers reinforces that you are worth hiring, and it forces them to compete instead of low-ball.

About Me

Back in the day I worked for several years at Digital Illusions on things like the first shipping deferred shaded game ("Shrek" - 2001), software renderers, and game AI. Then, after working for Microsoft at Ensemble Studios for 5 years as engine lead on Halo Wars, I took a year off to create "crunch", an advanced DXTc texture compression library. I then worked 5 years at Valve, where I contributed to Portal 2, Dota 2, CS:GO, and the Linux versions of Valve's Source1 games. I was one of the original developers on the Steam Linux team, where I worked with a (somewhat enigmatic) multi-billionare on proving that OpenGL could still hold its own vs. Direct3D. I also started the vogl (Valve's OpenGL debugger) project from scratch, which I worked on for over a year. In my spare time I work on various open source lossless and texture compression projects: crunch, LZHAM, miniz, jpeg-compressor, and picojpeg.