Follow-up to “The dystopian world of software engineering interviews”

I think this really explains much of the mystery of the 20 years of experience engineer who can't pass fizzbuzz. Writing code on paper/whiteboard is completely different from a text editor.

Just think about how you write code. You write a few lines. Run it in your head. Notice a mistake, add a newline, remove some brackets and it's all good. Oh wait, you just noticed this can be simplified. Ctrl-A delete all, reduce entire 20 line function into 5 lines.

None of this is possible on paper/whiteboard, especially in a timed interview setting. Paper/whiteboard is effectively immutable. You get one chance to write it down correctly and that's it. There's just no time and it's too difficult to even add a newline somewhere.

So you put a 20 year programming veteran in front of the whiteboard and they can't do fizzbuzz because writing code like that is so foreign to what they do. They can't just write something and fine tune it, which is how software is written. It must be perfect on the first try. they freeze up and fail.

There is zero excuse for companies to not give a laptop for interview coding. Even if it's Linux boot CD with nothing but vim and nano, that's still so much better than whiteboards. And these days companies use hackerrank during the phone screen. Just use the same website on a chromebook during the onsite!

Writing code on whiteboard is just really stupid. Can we all agree on this at least?

2. If that’s HR policy and you request for an exception and it’s denied, that may be a sign to start asking more questions.

3. You’re assuming that’s HR policy. Again, example dictates you have one option without actually thinking through how an organization could position themselves differently. Of couse salary is a component and rightly so, but at a certain point it’s just not everything

Think of it this way: lifestyle, ancillary benefits, “perks” etc can be all valid reasons to stay a place that treats you well and displays real loyalty (which is often displayed in more generous long term planning like big 401K contributions and fully paid health insurance for the family, open source software time etc). Can’t say I would just arbitrarily leave that for an extra 20% because that 20% can be easily eaten in other ways. Not to mention transparently knowing that your job won’t evaporate if the economy gets soft is a win. All this salary gloating is fine until that happens. 1999-2001 was not a fun time to be in the upper band taking pay cuts

Let’s not grossly oversimplify this. I’m never going to say don’t maximize your value, you should, I’m saying there is more than one (salary) way of doing that.

FAANG or not.

Oh and one dirty secret FAANGS don’t tell you? They happily underpay on salary once you’re in, or freeze you into a specific department etc. it’s not all roses.

1) Terrible Algorithmic interviews, AI-based evaluations, whiteboard coding.

2) Hey you are hired! Now move to $BigCity, with expensive real estate, schools, transit and everything else.

3) So, welcome to the job. You'll be maintaining this shitty old python 2.4 CRUD app that multiple people have tried and failed to upgrade. And one of the web guys wrote his own UI framework for it, kinda based on Backbone but with a lot of custom stuff. Yeah he doesn't work here anymore. Anyway that part is in coffeescript, no we can't change that, too expensive to rewrite.

4) But don't mind that, because you'll spend half of your time in Agile meetings! How are you with story point estimation?

5) Hmm also we're behind on the schedule. You don't have a problem with 10-12 hour days right? And no we can't cut back on the Agile meetings, that would hurt productivity.

6) Open floor plan! We think this will help productivity a lot. But sorry, no noise cancelling headphones, that will hurt interactions. Also the VCs love it when they tour. Nothing like butts in seats.

7) Here are some options! But they are probably worthless, because we'll never be successful. Even if we are, we probably won't go public. Even if we go public, your share is probably worthless because of preferred shares and liquidation preference. Oh yeah, there is a 4 year vesting schedule and its ridiculously expensive to buy the vested shares if you leave the company, which is of course intentional since we don't want people doing that. Anyway maybe you'll make enough money for a new car, eventually. Imagine commuting in some sweet new wheels, 5 years from now!

8) Sorry, only a 1% raise this year. Health insurance costs and all that. But if you like, goto step 1 with a new employer to try to get a real raise.

9) Yes we are aware that the expense ratios on the 401K are 2%, and you are only allowed to invest in target retirement 20(fn($YourAge)). Indeed that sucks, for you.

10) By the way you only have maybe 10-15 years of useful programming life before age discrimination kicks in. So you better get crackin'

In my company (totally remote) we decided to automate hiring (also remote) as most as possible and we are happy with the results. We also value the candidate's time very much so we made the hiring process very straightforward. It works like this:

- First the candidates must do some online tests, which are mostly multiple choice questions. The subjects are logic, english and a specific test for the coding language. All of these tests were hand made to us and customized to our needs. The candidates spend about 2 hours in total doing theses tests, and they know immediately their score in the parts of the tests that can be accessed automatically (which are the most part)

- The candidates approved in the theoretical tests - about 10% of the candidates that applied for the job - do a practical coding challenge that was also made from scratch by us. We have looked at the available solutions in the market and thought they are too focused on textbook algorithms that are rarely used in the job market. So we made our own tests that contemplate practical problems a programmer has to solve daily in our company. The questions are NOT too complex. The objective of this step is to weed out the candidates that can't code in the language, not to get the best. We design this challenge to take about 2 hours. The implementation was a lot of fun: we use the Docker API to run the candidate's code against the automated tests we made and the score is calculated as the number of tests that passed. Using Docker means we can work with any language that runs on Linux. So far we have made tests in Javascript, Typescript, Ruby, Postgres and Elm.

- The candidates that are approved in the previous step - about 2-4% of the candidates that applied for the job - are called for an interview. Now is the time when we take a look at the candidate's resume and look at the human side of things. Given that we have very few candidates to look at and we know they all meet some minimum skills we are very confident when conducting the interviews. By now we usually have a very clear signal to tell who the best candidate is even before we conduct the interviews. So in practice the interviews are NOT used to select the best candidate. They are there just to see if a red flag doesn't show up.

We are very proud of our coding challenges app. If someone wants to collaborate on it just drop me a message. It's a Rails app on GitHub, but it probably not good enough for an open source project yet - one needs to know a lot about Docker and Rails to make it work.

>At least from our current knowledge of interviewing practices