Double Shot #2361

Interviewing Red Flags

Some more thoughts on the state of the software development hiring process. This is based on my own experience over the past several years on both sides of the call, as well as on discussions with folks on Twitter. I'd be happy for feedback, additions, or corrections. I'm sure I don't know everything.

It seems to me that there are huge issues in our industry with lack of respect for interviewees. So when I speak of red flags, I don't mean reasons why a company might choose not to hire someone: there's plenty of HR-oriented advice already out there on that. Instead, these are the things that might make you think twice about actually working for a company.

And let me be quite clear: not everyone has the luxury of being super-choosy. There are a variety of ways that you can choose to react to bad behavior on the part of the interviewer and their company: air your concerns on the phone call, send a follow-up email to the interviewer or their HR department, hang up the phone while making it clear why you are upset -- or do nothing at all. If you've got kids to feed and bills to pay, in this society, you may well need to take the job now and worry about trying to change the company later, and that's OK.

That said, here's my list of things that make me cross a company off my list of potential employers:

  • Racist, sexist, or other blatantly prejudiced remarks, no matter what tone they're delivered in. No, it wasn't a joke. no matter what they might claim, I don't want to work anywhere that normalizes that sort of behavior.
  • Whiteboard interviews that ask me to develop an algorithm to reverse a string, insert an item into a linked list, or similar nonsense. I've never worked somewhere that this was important to know, and if it was, I would look it up. Bonus "no thanks" points if the interviewer doesn't think something like string.reverse() is a good answer.
  • Showing up late, taking calls during the interview, or otherwise making it clear that they have better things to do than talk to you. In rare cases an actual emergency might come up, in which case I'd expect an apology & reschedule.
  • Quizzing me on CS fundamentals (which too often is just "trivia") on the grounds that you need to know how things work behind the scenes. Yeah right, and can they explain the quantum physics behind semiconductors to me? If not, then this is just a "my abstraction is better than yours" argument.
  • An unpaid takehome coding exercise that's either open-ended on time, or designed to take more than an hour.
  • An expectation that people who get hired should not have a life outside of software. This can take the form of pushing you to explain your side projects, insistence that you justify every six-month gap in your employment history, or remarks that "we have unlimited vacation but no one takes it."
  • More concern with your references than with your skills. To me, this is a sign of a lazy hiring manager looking for reasons to say no instead of trying to let you show your best side. Anyone can come up with good references, so as a hiring signal their worth is close to zero.
  • Refusal to discuss compensation, even to the point of not being able to set a range. Why should I invest time in your interview process if you won't tell me what to expect when it's over?
  • Lack of a clearly explained follow-up process. Unfortunately you won't know this until the interview is over. But basic respect says the company should tell you when you'll hear back (and actually get back to you!).

Finally, I really don't know what the state of interviewing is in any industry other than software. I'm told it's not this bad everywhere. I certainly hope that's true.

Double Shot #2360

Double Shot #2359

Double Shot #2358

Double Shot #2357

Double Shot #2356

Advice to Less Experienced Developers

I seem to have picked up a fair number of Twitter followers lately who are just getting started in software development. Perhaps I've been in this game long enough to offer some advice. Here are some things I think are worth sharing with folks who are new in their software careers:

  • This stuff is hard. Nobody gets it right the first time. You're creating things by just pulling them out of thin air, mental effort, and sheer cussedness. If that takes you a while, that's OK. Even people who've been writing code for years and years still look stuff up all the time. Without search engines, I'd barely be able to add two and two together, let alone write code.
  • There are a lot of companies looking for software developers right now. There are also a lot of software developers looking for jobs. It can take a while to find your match. Don't get discouraged! No matter how experienced you are, it takes time. I've been in this business essentially forever, and over my last two job searches my personal pipeline looked like this:
    • 75 applications
    • 38 responses (Yes, half couldn’t even be arsed to set up an email autoresponder)
    • 14 interviews
    • 5 offers
  • No matter how new you are in the field, there is absolutely no excuse for a potential employer to treat you badly. Keep in mind that they way they act during the interview tells you something about the work environment, and you're interviewing them as much as they're interviewing you. Tip: Keep records of your job search, even after you land a job. You’ll want to refresh your memory next time you’re on the market, because some of the same people will still be hiring. And you’ll want to remember which ones were jerks last time so you don’t waste time on them.
  • Many interviewers in this industry are untrained in interviewing, and there's all too much "I suffered so you should too" attitude out there among some developers. You probably will hit a bad interview at some point. If it's bad enough (overt harassment, questions about your personal life, trick questions...) you can just thank the interviewer for their time and end the call. Then email their HR department and calmly explain why you left, and how the company's poor interviewing processes are hurting their chances to hire from a large applicant pool. You probably can't afford to publicly shame them, unfortunately - that's both legally fraught and likely to hurt your chances at other jobs, even with more enlightened companies.
  • By the same token, if you have a great interview experience, encourage it! Post a good review of the company's process to Glassdoor, and email your interviewer to thank them (this is good practice even if you're sure you won't get the job). As an interviewer, I always appreciate getting a thank-you email too. Bonus points if it shows additional thought with follow-up questions or ideas.
  • Job listings routinely lie about what's "required" because the people writing them don't know what the job really requires. Rule of thumb: if you hit 75% of the bullet points, go ahead and put a resume in. The worst that can happen is they'll tell you you're not a good fit. But be honest about what you really know!
  • As a hiring manager, there are things I look for besides code trivia. I care a lot more about whether you can reason through a problem and communicate then whether you know the syntax of a React component without looking it up.
  • An online presence helps. Put your sample projects on GitHub, just to start getting something out there. Start blogging as soon as you know anything. Even if yours is the 100th explanation of a particular API, the fact that you bothered to write it up shows that you can communicate, and sets you apart from the pack. Tweet links to your blog posts. Someone will amplify one, and you'll start building up a network.
  • Figure out what type of code you like to write, and write more of it. "Full-stack developer" is increasingly a myth.
  • Figuring out things on your own is good, but it's OK to ask for help. This applies on the job as well as when you're learning before your first job. But do figure things out! Progamming knowledge tends to build on what went on before. Take a walk, ask on Twitter, read some blog entries...but try not to move past things until you've got some idea what's going on.
  • There is plenty of software life outside of the Silicon Valley bro culture. Nobody has the right to ask you to work 100 hours a week, go out drinking to be "part of the team," or belittle you for being less experienced or somebody who doesn't look just like the founders. Don't work for people who act that way, and if you end up accidentally working for one of them, quit. It won't hurt your prospects for the next job.
  • Any honest developer is still learning. Any developer who tells you they know exactly how you should tackle every problem is lying. If they don't know they're lying, that's even worse.
  • In a collaborative environment, knowing how to write the code is only part of the job. You also need to learn how your team handles things like source code management, automated testing, deployments, downtime and incidents, feature and bug tracking, planning, and a host of other things. Be prepared for a huge rush of information your first few weeks. Almost everyone feels lost when getting started with a new job. Don't worry, it will pass. Tip: Spend part of your time revising the onboarding document that you're given, because most of the time some part of it will be outdated. The _next_ person to get hired will thank you.
  • Think about remote work, because being willing to work remotely will vastly increase the number of potentially available positions. Take any chance you get to collaborate remotely when you're learning, whether this is contributing to an open source project or pair programming over the internet with a mentor. But also: think about how you will handle remote work psychologically. Are you able to focus all by yourself all day every day? Do you need to explore coffee shops and co-working spaces? Are you a person who will only thrive in an office?
  • It's OK to compromise when you need to. From a position of privilege, it's easy for people to say things like "never work for a company that has a poor interview process." But life looks different when you are down to your last half jar of peanut butter with no money in the bank. If you need to make compromises, try to know that you're doing so, and have a plan for improving things when you can.
  • Your career doesn't need to look exactly like mine, or anyone else's. It's easy to give advice, but you don't have to take all the advice you get.

Double Shot #2355

Double Shot #2354

Double Shot #2353

Double Shot #2352

Double Shot #2351

Double Shot #2350

Double Shot #2349

Double Shot #2348

Double Shot #2347

Double Shot #2346

Double Shot #2345

Double Shot #2344

subscribe via RSS