It's entirely bullshit, and I regret being on both sides. I used to do coding screens, but I feel like some moderate knowledge of syntax and a decent education is enough to skip the rest. The whole cargo cult of coding screens came up during the 00's when Google made it look important, and you're correct that it's largely an exercise to convince the team that they're special.<p>Software engineering is the science of avoiding coding! And the code that these elite teams produce is often pure shit anyways.
I would fail utterly at a real coding interview. I've been out of school too long for that crap. And also, my tolerance for it has dropped as well.<p>But, I'm now a dev manager so I get to sit on the other side. I've been doing interviews in the last week for a dev position and I don't subject candidates to coding. I talk with them about what they work on, one of my senior devs sits in and goes even deeper -- learning what they know without even really asking formal questions, for the most part. Past that I care more about them being smart enough and willing to learn new things, and easygoing enough to get along with the rest of the team. Hell, that's at least half of what I care about to be honest.
We absolutely should. Here's what I'm doing to help change it:<p>I'm launching a new venture that will try to help connect great engineers with great companies. Companies with great teams, competitive benefits, and the belief that engineers shouldn't have to go through bullshit interview practices and shouldn't have to study 150 hours for a round of interviews.<p>The flow is pretty simple: a quick Skype/Hang out call to learn about you, what've you done, what you want, and what you like/don't like.<p>Next, you'll get access to a git repo. In that git repo is a project with real code and a few features/bug fixes for you to implement. You commit against that repo just like you would at work. After a certain amount of time, you'll lose access to that repo.<p>One or more engineers will review the repo with no knowledge of your age, gender, work history, etc. Based on that engineer's feedback, we match you with companies that we think there will be a good fit. If there is mutual interest, you meet the companies in person for a final round where you can't get rail-roaded with bullshit questions.<p>Email me @ interviewingisbroken@gmail.com if any of these are you:<p>1. You're in the Bay Area or NYC and interested in fair interviews with great companies<p>2. You're in the Bay Area or NYC and work for a company that wants to offer fair interviews to get great engineers<p>3. You're a great engineer who would like to get paid to help create interview projects or perform reviews of candidates code - we're paying up to $100/hr. Great side hustle opportunity.<p>I wasn't planning on announcing anything about this yet but this post got me so fired up.
I personally like the way we currently do software interviews. I got a nearly perfect SAT/GMAT through rote preparation (despite not doing so well in school generally), and brought this skill to bear on software engineering interviews. As such, I’ve had job offers at some of the best companies in the world, something my pedigree otherwise wouldn’t have allowed. I’m not able to get a job at McKinsey or BCG, no matter how well I do in case interviews, because they weight academics and prestige of school highly.<p>I get that many people, especially seniors, are annoyed by the general software engineering process because they feel entitled to certain positions. But for the most part it seems to make things as meritocratic as possible (aside from holding back certain populations because of bias, something people seem to be working on fixing).<p>So yeah I agree several day-long interviews for a company is draining and a huge time suck, but aside from that relatively minor inconvenience it puts everyone on a level playing field, and those who are “too good” for the game are free to opt out.
Absolutely. I've seen companies send an intern to do a technical interview for someone with over 10 years of experience. The intern's feedback was that the guy had a lot of experience, but made some syntactic error on a whiteboard exercise so it was a pass. I don't know who gets to dictate shit like that, but it's absolutely broken. For reference two days later I overheard the same intern saying that JavaScript was fully synchronous.<p>As a fun aside, I've seen people send out HackerRank evaluations for entry level positions and I think that's ludicrous.<p>The best interview I have had was me Skyping with one of the devs and he gave me a link where we were able to share a browser session (for the life of me I can't remember the name of the site), but he described the problem and as I typed he could see what I typed. There was no emphasis on result that I can remember, just the process of writing code, talking it out loud and seeing code evolve and asking whether certain edge cases should be considered.<p>What's most broken, I think, is the fact that interviewing is an uneven, broken experience that's different everywhere you go because no one really knows how to interview. I haven't seen any company take metrics on whether their process is good or helpful or filters out too many people or not enough.
Personally I'm very defensive against more academic interview processes (like Google's) because I'm a college drop-out and feel some amount of insecurity being ranked among peers with better academic backgrounds who might excel at such tests. In truth it is a personal failure of mine, and something i'll eventually get over through study/training the next time I'm looking for a job (hopefully years from now).<p>Sure it would be great if we found some super-magical process that didn't irritate or inconvenience incumbent and new developers alike. But you probably can't please everyone, and in the meantime we need to do the best we can because hiring still has to happen. Companies with slightly better processes will be rewarded (hopefully) and companies with more painful processes will face some penalty from losing candidates that would move their company forward. Hopefully this is enough of an incentive to keep companies continually working towards better hiring practices. But I kind of doubt it.
I actually really like the way that my company does software interviews. We do an initial resume check and screener phone call. After that, we send prospectives a take-home code sample that they can work on. The problems are very small and well-scoped and they can take as long as they want to work on it.<p>We do an initial code review. If we have notes for improvement, we give the candidate feedback and ask if they'd like to do one more pass at it. If they don't want to, but we think that the general thinking and instincts behind the logic is sound, we bring them in for an in-person where we ask them to go over their code review on where the pitfalls are and where they think they could potentially improve.<p>That gives us the most realistic sense of how well a candidate is going to do at the company, since this is essentially our process.
My impression of the big 4 interview process I went trough for my current position wasn't at all that it was all about having done a lot of preparation in the form of hackerrank problems etc. On the one question that most closely looked like something from my preparations, I did worse than the others. This was because I didn't actually think the solution trough properly and mostly repeated what I "knew" was the answer.<p>My conclusion was that it's mostly about being able to solve novel (which means preparation matters less) problems in code and explain the reasoning behind the solution. It is of course possible that I was just lucky in having good interviewers, in which case I guess that would answer the question, more of that and less of syntax checks or finding the one true answer-type of questions.
Most people hate them when they get rejected, consider them fair when they pass. Like anything, they are mostly subjective and very gameable (compare it to getting accepted at a college)<p>It's not remotely scientifically-objective, but most things in life aren't. I'd liken it more to dating. Both parties are evaluating each other on innumerable criteria through their own subjective lenses, and trying to reduce it a scientifically-quantifiable measure is dubious.
I especially love being asked questions from university CS courses that I completely forgot in the 20 years since I graduated - because they were completely irrelevant in the real world. It's like reliving the exam nightmare throughout your entire life.
I'm getting a bit frustrated with the talk about interviews, as we repeat the basic message every now and then, but nothing changes. I feel we all agree that the current status quo is not good, but so far there has not been any good alternative:<p>- Whiteboards are unnatural. Besides, you don't want to check their knowledge of university-grade algorithms or data structures.<p>- Problems to take home are an artificial setting - you can't be absolutely sure that they did the work themselves, and you have no idea how the mesh with other people. And you probably get some false negatives because they're stuck and can't ask their colleague.<p>- On the other hand, if you're using real code from your project, you're just asking for unpaid work. And paying every candidate is a significant expense.<p>- Using a proxy measure like HackerRank or a Github portfolio excludes people from minorities or who only want a job and not a mission.<p>- Not doing any coding opens you up for people who can talk, but not code.<p>Have I missed anything? Is there a good alternative to find the right people? I'd love to improve my company's interviewing process, but sooner or later we always hit one of the mentioned problems.
My opinion is we need to have more variety of interview options. Everyone has their strengths and weaknesses and any given Dev has to have some kind of idea of what they excel at. Some people are really good at tough algorithms.<p>I recently went through a job search and I ended some coding tests because they took too much time and the questions I was asked seemed more like a random candidate filter rather than a test of developer knowledge.<p>My personal opinion is to make an easy coding exam similar to triplebyte or other apply once talk to many companies and randomly accept a portion of candidates.<p>That way people will know it's not their skill and can optimize for market exposure rather than arbitrary coding problems.<p>Then have an in person where you see if communication can happen. Ask them to walk you through the code used on the entrance test.<p>Can the industry move towards something like match day for doctors, but more ongoing?
Whiteboarding is a waste of time in my opinion. The problems are recycled anyway (reverse singly linked list, needle in haystack search, etc). It doesn’t give you a useful signal about the person’s coding ability when they can just do rote memorization on a toy problem.
These two below resonate after hiring dozens of engineers:<p>> – What kind of quality work does this person produce in a normal work environment where someone isn’t breathing down their neck?<p>> – Can I work with this person on projects that span weeks, months, or years?<p>No matter how well they anwser questions, how they whiteboard, how high is their IQ, or how well they do homework - none of it would tell you anything about their work quality or actual on the job performance.<p>Just ask them a for loop question and give them a contract to work on something. If it works, maybe hire them.
I've thought a lot about this (and I'm sure others have to); I think candidates generally fall in two buckets:<p>1. Can code:<p><pre><code> a. Gifted: </code></pre>
These have a natural talent for coding and can crank out code at the drop of a hat<p><pre><code> b. Persistent: </code></pre>
Have moderate-good talent for coding, they make up the gap with gifted coders
with sheer persistence and relentless pursuit for making themselves better<p>2. Cannot code/haven't coded in a long time<p>How can you test for coding?
In my view it's certainly not some academic question or the in-vogue programming interviews book. This is clearly proven to be red herring. Also at least in the bay area, there are set questions that FANG and other companies have which are shared all over the internet and amongst friends who work there. So an interview becomes a casting process for a role, where the script is the questions you have "rehearsed". This is an absolute facade and needs to stop!<p>I ask simple programming questions and look for "naturalness" in the way they answer and talk through the solutions. No complicated brain teasers or the smug "look at me, I know this obscure/complicated algorithm invented before I was born" questions.<p>Coding is one facet, the other one is design. No matter how good a coder you are if you have bad design skills it doesn't matter.
How do you test for design?<p>1. Resume experience: Talk through technical issues/challenges, pros/cons etc. of projects they've done before<p>2. A simple-moderate design question: If someone lists distributed systems as one of their skills, ask them a question on it. A decent amount of determination can be made about a candidate they way he/she answers.<p>I'm refining my process after each interview I take and would love feedback.
I've been through and used several different styles of interview and the one that stands out as being "the best" at predicting whether a person will fit on the team is just to bring them in and work with them for a day on <i>your actual product</i><p>1) You don't do problems you've already solved that they have to come up with same answer to.<p>2) You don't do algorithm / problem testing that they're never going to use on the job.<p>3) You don't do whiteboarding except as you would in real life.<p>Engineering teams are people working collaboratively to solve complicated problems where nobody knows the "right" answer. Any interview that's going to tell you something is going to measure along those metrics, and not "can you invert this b-tree on a whiteboard."
There are tons of threads on HackerNews on this and they all usually follow the same exact pattern of discussion.<p>Everyone hates interviews and how they are useless but in the the end we settle for the status quo.
There is no right answer to this. Every company is different, so there is no right way to do software interviews.<p>Enterprise SaaS, Consumer Social and ML API companies will all have different working environments. Add on to that options of remote vs on-prem, CI/CD vs TDD, customer integration requirements, staff numbers, perks etc... and you have completely different needs for workers and teams.<p>A team earns their hires, and people will naturally gravitate to environments that suit their work styles.
I conduct this style of interviews. It's easy to complain, but much hard to propose better options. Most alternative hiring proposals do not meet the fundamental criteria of Big 4 hiring: they must reject approximately 99% of applicants while consuming an average of two hours of engineer-time per candidate.
I would like to offer a partial list of practical ways to make software engineering interviews better.<p>1. As a candidate, if you are in a strong enough position to refuse the job, then refuse to do white board exercises with no resources. No one codes like this in real life so refuse to do it in an interview. Be willing to walk out. I just say "I'm a good programmer and your interview process is broken. If you want to hire good programmers it's your interview that needs to change. We can start that right now and talk shop as programmer to programmer about coding, or I can leave. I'm happy with either option but I'm not going to waste your time or my time with whiteboard exercises that don't find the best programmers. How often do you use composition over inheritance here? I've been learning a lot about that and it's really helping me write better code. Can I show you some of my recent code where I've been doing that and get your opinion on where it could be improved?" Remember that your job on the interview is not to follow their script. It's to prove to them that you are the best candidate for the job. Go off script and take control if they are bad at interviewing. If good programmers are regularly walking away from these types of interviews, the interview process <i>will</i> change.<p>2. Unless you've been trained to interview people, you are probably really bad at it. Think about how bad someone is at <i>coding</i> who never did it before and has no training. Interviewing people is no different: it is a skill that takes time and effort to learn. Get trained up, and practice with role playing with colleagues. As much training as you have time for. Educate yourself in your free time on a regular basis with articles about best practice. Adding more words won't make this sink in more, but I will end by saying I can't stress this point enough. You are bad at interviewing. You need to fix that before anything else if you want to hire good devs.<p>3. How are you measuring success as an interviewer? This is a really difficult thing to measure because how can you find out that your interview process is rejecting candidates who would make great employees? I'm not going to try to answer this here, but it's an excellent question to think about. One thing that might help is the next point.<p>4. Whatever your first impression is of the candidate, spend a good part of the interview trying to prove yourself wrong. Candidate seems like a perfect fit for the team and a great coder? Instead of relaxing because you're sure you already found the right person, see if you can figure out why they might be a bad fit or if their coding skills aren't as good as first impressions. Same for someone who seems weak at coding. Maybe they are just nervous. Can you make them relaxed enough so their awesome skills can come through? Maybe in both cases your first impressions will be proven correct. But if not you might have just found a diamond in the rough that other companies are skipping over.<p>I hope this very incomplete list is enough to get folks interested in following up on point 2.