The typical programming interview is unscientific and random. This is a blanket statement, but I believe it to be true. Your mileage may vary, but in general you will find yourself in situations where your success or failure is dependent on something random, like if you happened to get the question you on a whiteboard interview. And while the randomness may even out at scale, your individual outcomes are not going to be a pure function of your suitability for the job.
This kind of sucks. We would rather the process be more based on merit.
No amount of soapboxing—if you are not DHH—is going to meaningfully affect on your personal outcomes. You should continue to voice your thoughts about better scenarios, but you cannot sit around waiting for the process to improve. You need to get out and make the most out of the popular process.
That means considering this randomness a feature, not a bug, in your personal approach, and go from there. That means applying for jobs you may not feel totally qualified for. If you want that great job at the company of your dreams, apply for it and embrace the opportunity to swing and maybe hit a home run.
Even established companies will find themselves scrambling to fill certain roles, or stumbling into a poor communication rhythm where their hiring process is not as tight as they want it to be. Step in and take advantage. Critically evaluating whether you are ideal for the job is negotiating against yourself from the get-go.
How to make the hiring process as arbitrary and subject to bias as possible.14:34 PM - 04 Apr 2016
I am not telling you to apply for jobs you are blatantly unqualified for or prey on companies that are radically disorganized. Both these outcomes are terrible for everyone, including yourself. But if you find yourself staring down an opportunity and wondering whether you are capable, please step into the batter's box and take a few swings. Reasonable qualification gaps can be closed quickly once you start the work and jump into the code.
Resignation to fate is a tough pill for software developers to swallow. We, as a species, love determinism. But if your goal is to land your dream job—or just get your first job—play the game and take more risks. It is up to the hiring firm to disqualify you, it's not your job. Somebody is going to be the benefactor of randomness, it may as well be you.
Mastering the technical interview19:54 PM - 12 Jan 2017
As with anything, always be honest and ethical. Just because you are trying to play the game to your advantage, ripping people off is never worth it in the long run. This goes without saying, but I'll say it anyway.
Top comments (15)
I recently was at an interview that I think was actually good: they showed me a pull request of their code and told me to do a live code review on it. Not only could they determine if I have experience with the process, they could also see if I can understand what the code I would work on does.
I would use this on all the interviews in the future.
I had a similar one, it was the best tech interview so far! They left me for 10 minutes with some intentionally bad code and then asked to tell everything that I think was wrong with it. I had a blast there. :D
Walks into the interview.
Interviewer be like: here's my code, now roast me!
I will use this in my future interviews.
The interview process is completely terrible across so many companies. I think more people should stand up and try to change it. Whiteboard interviews came around the same time the whiteboard was invented. It's fake. No one can code fluently on a whiteboard - it's out side of the programmers natural environment.
And these stupid riddles - ugh.
Now with the rise of bootcamps, the line in the job description "4 year degree or equivalent work experience" is scaring a lot of perfectly qualified people away.
End rant.
But I completely agree Ben - You don't know what's going to happen, and you shouldn't hold back in fear. If it's an opportunity you're excited about, apply and prepare the best you can.
Well It's depends. On my first job as a development, HR was a external company, they work like for 30 companies and they don't know about the actual job. I saw the announcement online they needed a PHP MySQL developer with knowledge on linux, something simple. In the interview they asked a lot of common questions and technical questions were "do you know windows?", I said "yes and linux too" and they continue "but what is linux? Never heard of it". They just published the announce without knowing.
Then they referme to the company (the actual IT company) where I meet my future boss, he make me another interview asking "do you know about PHP and SQL?" and then "we use windows 7 and will upgrade to windows 12 soon" I just agree and leave.
Later they called me to do a practical test. A CRUD test for a small system. This test was to prove skills and to see how people work. The test was maded by one of the developers because people lie to try to enter. No time limit, you can use the internet and any tool.
Was easy and I started weeks later. Now I'm the one who does the interview and the one who aply the test. We encourage to use the same rules for every one, some people don't finish the test or takes more than 6 hours. So we try to look for someone who work clean and at least has knowledge about the basics, so we can train as a jr developer.
There is this one aspect of whiteboard interviews that is really interesting and is: logical thinking. You should be able to formulate a possible solution in pseudocode without it having to be correct. The problem relies on what the companies made out of it.
For example, implementing a well known algorithm in a whiteboard is kind of bullshit, trying to give a possible solution for some short problems like "is this word a palindrome"? Or that kind, I think is really important.
Lately I have been interviewing for some positions in India, and since I am in the US, I just let them use an IDE or what ever editor they feel like and try to work on the problem together. I have had some rough bumps so far, hoping that might work out. Soon we will be hiring some interns, and again will be interviewing them as well. So just need to work out the logistics so we do not do a white board problem. I am not so much looking for them to come up with the right solution, but can they work well with me and can they break the problem down. Bonus points if they know about TDD or at least try to test the code while we are working on it.
This post is excellent! I often disqualify myself all the time because I feel like I am inadequate, but reading this article makes me realize that I need to take more risks and not play it safe in my job search.
Yesterday got an interview that was a test for NodeJs, or that is what they say. Got 10 minutes to solve 10 answers of logic with mathematics, like really really hard problems. The test was with my cam on, in a moment picked a pencil and paper to try to solve them, moved out of cam and got an alert of suspicious behaviour and that my test will be revoked, moved my mouse out of screen to use a calc, same message... After these tests, where i only could complete 5 of the 10 answers, got a coding test where i needed to complete a function with javascript without googling or anything. I don't know if the rest of devs can, but i can't remember every function sintax, regex, etc. I know the tool i need, look for it in google and use it.
Anyway it was really stressfull experience...
Benefactor probably doesn't mean what you think. Still, I love the idea behind that sentence; it could almost be a line from a movie :D
This is a half-serious suggestion.
Why not do a cursory interview to check whether someone has the technical skills and cultural fit, and then randomly pick from the remaining pool of candidates? Such a system would be fair, since every candidate in that pool has an equal chance of getting accepted (after passing the initial check). It's also a formal process, which should please engineers' need for "order". And it's cheaper than calling people for repeated interviews and coming up with whiteboard puzzles, so you're saving the company money.
It's not an ideal solution. But it's better than pretending we know how to identify candidates' competencies accurately.
You're also likely increasing your talent pool by not maximizing for people who are interested in preparing for and going through with the whiteboard interviews. Good programmers tend to have good jobs and lots of options already.
Interviews and education suffer similar shortcomings, they are by definition both outdated (especialy given today's paces) and partially irrelevant. You can't possibly answer today, tomorrow's questions and no matter how many shorting algorithms you can dish out in x y z languages it's most likely you'll never need them in your day to day responsibilities.
So follow what comes more natural and promising to you (tech wise), take your shots and hope for the best.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.