I learned how to balance a red-black tree in college, 20+ years ago, and that’s the last time I ever balanced a red-black tree. Unless the job is writing data structures libraries, why would you ask me that?
I’ve built large, production systems used in the most secure environments in the world. My code is secure, performant, accurate, and safe…but no, I don’t remember how to find all palindromes in a string off the top of my head.
I remember interviewing at one of the Big Companies. I said I knew C. They asked me which format specifier in printf would do some obscure thing. I didn’t remember. Guess what? I’ve been writing C for…26? years now and I still sometimes look at man pages. I’d be more worried about a developer who didn’t, honestly.
Unless the job is writing data structures libraries, why would you ask me that?
Additionally, if I asked an engineer to build a data structures library with red-black trees and they started coding without immediately reaching for a description of the operations, invariants to maintain, etc, for a proper red-black tree, I’d be really nervous. It’s like when a waiter doesn’t write down your order.
I know that in some places it’s considered a badge of honour to be able to take everyone’s order without writing it down, but for many customers it just makes the service worse. I literally do not care how my order gets to the chef. All I care about is that it is correct. Writing it down increases my confidence that it will be correct, meaning that in the wait between ordering and getting my food, I can relax, confident that in due time they will bring me the right things, instead of worrying that I’m going to have to spend my evening negotiating with the waiter and waiting for the chef to get my order right by trial and error.
In a similar fashion, remembering how to implement a selection of obscure algorithms is really low on the list of priorities for a software engineer. You could almost argue that for interview purposes, you want a problem the interviewee hasn’t met before, so you can actually observe how they go about solving it.
instead of worrying that I’m going to have to spend my evening negotiating with the waiter and waiting for the chef to get my order right by trial and error
Everybody’s got their own thing going on, but I can’t help thinking you might be optimizing for the wrong kind of restaurant experience.
At risk of breaking the metaphor, we should optimize for safety first: Don’t serve allergens to patrons who indicate food allergies. This suggests that orders should be written down or tabulated in point-of-sale systems, rather than memorized, and that orders should be systematically assembled rather than designated by petnames.
I think this might be a “restaurant as status experience” thing? The waiter shows off their memory, this demonstrates that they’re a good waiter, which makes this a good restaurant, which makes you a person who eats at a good restaurant.
I don’t know if it is an US thing but having been waiter/bartender/manager in multiple bars and restaurants in Europe, I think a lot of folks here seems to have had a bad experience with waiters or hold a grudge on how to optimize the certainty of having exactly what they said done. And for siblings comments comparing taking notes as a SE and waiters, I would love to see how SE making minimal wage and living on tips would learn to optimize their workflow.
I have been trained to not write down for any table under five people. I insist on trained, first we were allowed to take note for anything and after a few days/a week, you stop taking notes for any table under four etc. It began to be a challenge between colleagues. Bref, all in all you develop a kind of memory palace of your restaurant and their table and make weird association between guest and their commands, your optimize also your work and your are faster and more precise at the end of the day because you will remember longer. Heck, I still have in my memory the set up of tables of all the place I worked in and the orders of regulars and from random people that I happen to see in the city I was living burned in my head years later.
As a manager, my rule to train my team was to be able to take order for table of X where X was our average table. It was speeding up the process, making waiter more aware of the flow of his tables, better balance the workload to the bar and the kitchen by timing when to take some orders, reshuffle orders order to let a two people table bypass the ten people table before it reaches the kitchen or later with kitchen. And bartenders and cooks have to learn and do the same. A restaurant is never a FIFO sequential process, you have to manage a concurrent/parallel environment when everybody needs to be served at the right timing, within a known acceptable lag. Having waiters able to memorize your order but also remember it as long as you are in the restaurant, it is similar to the cookie session in your browser.
Zeigarnik effect. Waiters don’t have to analyze, break down, reshuffle and regroup their orders. Software developers do that all the time. I don’t trust those who don’t take notes.
All software developers take notes. Good and bad ones. Those who don’t - are not software developers, at best, they are code-monkeys.
Also, red-black trees suck. Keeping the colour in every tree node bloats the data – quite probably by 8 bytes for the struct size on a modern machine, and many malloc libraries round up to the next multiple or 16 or 32 bytes. And both red-black and AVL algorithms are complex.
Hash tables are generally more useful now, and b-tree like structures make more sense given cache line sizes (or VM pages), but if I do require a balanced binary tree then my go-to now is the scapegoat tree. The code is much simpler and smaller, there is nothing extra in each node, and it requires only a few bytes of extra global storage (for powers of your acceptable unbalance factor) for all trees, plus one integer per tree if you will be allowing nodes to be deleted. I can and have written complete bug-free code for scapegoat tree in 5 minutes in programming contests/exams where standard libraries were not allowed to be used.
But, yes, the main point here is that if I need to write code for a data structure or algorithm for my actual job then I research the literature, find the best thing, implement it very carefully (possibly with modifications), put it into production, AND THEN FORGET THE DETAILS to make room in my brain for the next task.
I call BS on the premise of this article. There are bad coding interviews and good coding interviews. Those that literally test the ability to code at all are necessary because most teams need senior engineers who can actually code. Fizzbuzz, word counting, and the like do actually test if someone can code at all. I’ve seen senior engineers who couldn’t do simple coding tasks requiring no specific knowledge.
Further I’d say that environments where senior engineers don’t code are miserable- decisions are made by people who don’t actually have to deal with the consequences on a daily basis, and junior engineers are usually left entirely figuring things out for themselves.
Asking a senior engineer to do FizzBuzz only demonstrates to the candidate that you don’t value their time, and your recruiters aren’t doing their job. If you’re worried that someone has flat-out lied on their resume, then do a background check and have interviewers skilled enough to spot bullshit. You’re supposed to be evaluating candidate’s expertise, and how their experience is relevant to your company, not checking whether they’re a junior who’s practiced interview quizzes.
It happens that people who can code well fail coding interviews spectacularly. Not everyone handles high-stress situations. Coding on a whiteboard or someone else’s unconfigured computer is uncomfortable and distracting. Candidate might misunderstand your question. They might stumble on something trivial, which they’d have googled in a real environment.
For us, we do 3 basic “Fizzbuzz” style questions as part of a pre-screening via coderpad. They’re permitted to use the language of their choosing, ask questions, google, etc. It takes less than 15 minutes and is more about basic “read requirements; implement basic solution” rather than leetcode or those silly gotcha style ones that have obscure, subtle solutions. I wish we could eliminate it entirely, but it still weeds out about 10% of applicants. It also means we don’t have to try and suss out whether someone can code at the next phase of the interview which is more open-ended and explores how they break down requirements, architect, etc.
For us, we do 3 basic “Fizzbuzz” style questions as part of a pre-screening via coderpad.
So that’s fine and even makes some sense for cold-drop applicants you don’t know from Adam or Eve (although I’ve soured on that approach and had more success with other mechanisms). Where it gets my back up is that as a Senior who currently does all of my work open source, I’m far more likely to enter your hiring pipeline via a recruiter attempting to poach me than as a random person in your resume inbox.
I’d say, maybe, 75% of the time that seems to involve the recruiter prequalifying me and then dropping me into a hiring pipeline that immediately asks me to write some fizzbuzz style test. That’s an immediate hard No from me.
You could learn far more, with far richer signal, about 1) whether or not I can code, 2) how I approach real-world problem solving, and 3) how I deal with collaborating with others simply by looking at my commits, PR reviews, and discussions in Issues in the wide-open GitHub repo that’s the entire reason you decide to approach me in the first place. All these standardized tests accomplish in these cases are to tell me that either your Org is so dysfunctional that your hiring pipleine has no clue who your recruitment people are handing to it (in which case, why am I wasting my time on you?), or you and your Org are so blinkered by Process Uber Alles thinking that you prefer to confine yourself to the standard and much lower value signal of fizzbuzz than taking advantage of the richer source of information you have access to (in which case, again, why am I wasting my time on you?).
The suspicious bastard in me also thinks these tests are largely intended to serve the purpose of trying to confuse the issue of who’s pursuing who, trying to make me sell myself to you when really it should be entirely the other way around. That’s a game I decline to play – I don’t know who you are and you’re the one who approached me, don’t expect me to have any reason to want to prove myself to you.
(Obviously the “you” here is less you specifically and more “the phenomenon of employers dogmatically administering these silly tests I have encountered repeatedly”).
I don’t want to be too dismissive, but we’ve interviewed for senior-ish positions, and hey, the “fizz buzz” filtered out people! Meanwhile the coding stuff is like… fine, and it gives people a chance to shine.
We extremely take into account the issues with coding interviews when applying them. We don’t ask arcane stuff. We set up an environment and a “full-ish” project. Our walkthrough is based on a thing we actually had to build (and various tiny bugs we kinda had). We make sure to say we’re not trying to judge them on arcane shit, and this is a point of conversation.
We have had two sorts of results from this:
candidates take a bit of time to click through stuff, and ask questions. We go through some high-level stuff while also fixing up some low-level bugs. We see some varied ways to go about problems, and soimetimes outright stop the “coding” part to just talk about more interesting details, cuz we got the proof we needed.
candidates are completely lost in the material. We try to deviate to really simple stuff , down to just like “hey, here’s this stacktrace that you’re seeing, where should we go now”. We try really hard to get any sort of positive thing from the candidate and don’t.
Now yeah, in a work environment you have less stress going on. But our thing is really easy, and to be honest a huge part of maintaining an existing app is handling a bunch of code you have never seen in a reasonable amount of time.
We think it’s representative of some of the work, answers loads of questions frequently, and we have never gotten stuff on the edge. The bimodal nature makes me even more confident this isn’t totally broken. And it’s done in less than 60 minutes. Which I think is way more respectful of people’s time than a take-home project.
I feel like people conflate “coding interview” with “fizz buzz”, but if you take one of your engineers to the side and ask them to spend a day or two building out a vertical slice of one part of your application, it could be a very good playground for something very effective.
Here’s an interview where the interviewer respects the interviewer’s time and expertise, it’s the mock interview that Casey Muratori (of HandMade Hero fame) gives to Shawn McGrath.
To sum it up. You ask about a topic that the interviewee finds interesting and then you do a deep dive into it. That allows for so much more information to be obtained than a dumb code challenge that can be memorized by desperate candidates.
For people that have public projects on github nothing can be easier. For people that don’t have public code, see the interview itself.
(Paraphrasing) “It’s not an answer, it’s knowing for sure that you’re able to reason from the problem to the answer in your head”
Thank you for mentioning this interview. I had seen the link a couple of times before. I bailed out on each viewing due to the length. This time, based on your recommendation, I skipped around sampling how the interview went.
In general, the comment thread here has been fascinating.
Does anyone actually enjoy coding interviews? I’ve only been on the
receiving end. Between anxiety and social phobia and feeling threatened
by strangers, I’m in fight-or-flight mode, with the rational part
of my brain shutting down.
What’s funny is that I can do public speaking quite effectively, because
I can prepare for it. In other words, switch on the autopilot
and let my programming take over (no pun intended).
Yes! But, I am a white male with a lot of experience, so I am not worried about a lack of opportunity if I screw up.
For me, the only prep I do for interviews is to read one or two good articles to get my mind in tech land, and go in cold, otherwise. I draw upon my experiences to recognize problems and have an honest conversation, share my thoughts, keep an open dialogue, ask questions, etc.
I enjoy the random set of challenges being thrown at me. I have been passed on at some FAANG companies, but I have had a very successful and fulfilling career working with amazing people, on impactful products, so… for me this strategy has worked out very well! And, I’ve never come out of an interview without learning something new.
I like to interview semi-regularly – at least once every 1.5 years. I enjoy doing this for several reasons:
It’s a low-risk way for me to see what companies in my area really want to hire for. Lots of places in my area want .NET experience, so when I wanted to play around with a ML-esque language I picked F# so I can kill two birds with one stone.
It’s a great way to build my network. I live in an area with perhaps a few dozen major tech companies, and by interviewing around I’ve met a lot of the hiring managers. I know who I’d like to work for and who to avoid. And I’ve received a few direct references this way as well.
I’ve made the mistake before of waiting too long at a job that is starting to go bad. Interviewing often is a good motivator for me to leave.
The fastest way to beat impostor syndrome and to worry about interviewing is to get a job offer ;)
But when I treat interviews like this, there’s zero stress for me: my interviews are just like yours, a nice conversation, open dialogue about problems I’ve solved and problems the business faces, and generally easy and comfortable.
E: Because apg pointed it out, and I think it matters: I definitely have the same privilege he does, which changes my perspective, and when I’m on the other side of the table and evaluating candidates I consistently try to make that count less. One tip I got: I often get to review resumes to decide who to ask for a phone screen, and I’ve asked the internal recruiters I work with to send me resumes with no identifying information. I don’t know how it changes my recommendations, but it’s one more avenue that keeps any implicit bias from slipping in, so I suspect it’s worthwhile.
I don’t do biographical interviews anymore, and so I don’t even look at the person’s resume at all, until after I’ve submitted my evaluation. The interview feedback my company uses is based on our principles and each interview attempts to evaluate the candidate against a set of them. I’ve not been here long enough to have strong opinions on it yet. So far, I’ve enjoyed the attempts the framework makes to be unbiased, and feel that decisions have been fairly obvious as a result.
The interview I’ve been doing is a systems design thing, so technical, but not coding.
I’ve been trying to steer the ship away from the “resume -> phone screen -> broader phone screen -> in person” pipeline for a while, but it is fairly ingrained.
The interview feedback my company uses is based on our principles and each interview attempts to evaluate the candidate against a set of them
Could you share some examples on this? I suspect I’m about to be on another round of interviews and am curious how this works.
Principles – each of the interviews has a set of these that can be evaluated. Sometimes the interviews overlap in these principles, which is fine. The interview feedback I fill out has specific questions related to the interview, with a big focus on the principles.
I’m not convinced that being a white male helps, though that may depend where you are. At my place of work they have quotas with the effect that women get places more easily.
I enjoy coding interviews to a large extent but it is always a major relief when they’re over. And I’m never fully relaxed in any kind of interview. I do very extensive preparation. My mind tends to go blank when asked for examples from my past experience. And, I’m probably not very good at interviews because in 25 years I’ve only ever landed one job offer after an interview. That’s included two rejections from FAANG companies. So by my example, being a white male with lots of experience is not enough on its own. Only time I’ve changed jobs it was to a competitor where they already new me well from working with me for the same client - and that didn’t last long because my original company bought them.
I’m not convinced that being a white male helps, though that may depend where you are. At my place of work they have quotas with the effect that women get places more easily.
Hmm. This reads to me as if you don’t believe that white male privilege exists, and instead of responding with ways in which I’ve benefited over the years, I’ll ask you to see if any of these 160 things happen to apply to your situation, especially the work place section? I get that the name of this website may sound pretty scary, but I hope you can look past any potential bias there and give it a fair read.
Fun story from my past: I once worked for a company that announced a new diversity and inclusion “council” which was literally comprised of 3-4 Director level folks, 2-3 senior managers, all of which were white and male. I wish I could say that I had trust in this initiative, but needles to say that it was adjusted after some of us raised very publicly that this seemed like a questionable choice.
Try not to worry about whether or not the deck is stacked against you (some folks will insist it is, many will insist it isn’t, some will try to gaslight you about your own experiences either way); there are probably easier wins (resume polishing, practice being interviewed and general social anxiety defusing tricks, better negotiation techniques, and so forth) than worrying about things you can’t control. Good luck to you!
It’s natural that loss of privilege can feel like oppression. I try to take comfort from knowing that many other peoples’ real oppression is really being diminished.
I really enjoy coding interviews. I like high pressure/challenging scenarios, it’s a situation where preparedness pays off and I am a very social person. It’s also a great opportunity to learn more about how other people do their business, and how they interview people. Getting interviewed makes me a better interviewer.
Yes. I love coding interviews. This is an employee market, if I fail, l’ll interview somewhere else. Companies should be more worried about their false negative rate and the time they waste interviewing people, but they don’t… Their loss. To make a moneyball analogy: there are a lot of undervalued players on the market.
I’ve been on both sides. And I considerably prefer the interviewee side, I rarely learned something or been challenged/amazed on the interviewer side.
Yes, I do. Rather, I like the effect they have on job hunting as a whole. I don’t think it’s ever been easier to increase your income than before since you can prove your skills in a few hours. Solve some problems, get a bump in comp or move over to another company with a different wlb. The true interview is the first 3 months working with people, not the first few hours spent locked in a single room with them.
There are people who enjoy, but this question may apply to any kind of interview. Most people don’t enjoy at all any type of interview. It does not matter if you are a software developer, a pilot or a teacher, it is not a situation we are used to be and when we are not able to show our best, we feel sad.
On the other hand, I see a lot of complaints on the coding interview with regards to white board interview and questions. What I see on those complaints is that people actually do not propose a real solution to it, just pure complaints.
I made more than 130+ interviews during the last 3 years as an interviewer. During my interviews I never focus on the code the person writes, but if I can work with the person. I look for values such as: the person makes questions, can we communicate properly, can we have work together on a programming challenge. What I find wrong is to ask something very specific like RBT and expect to implement and remember it: this is super specific and does not tell you if you will succeed in the position.
For me interviewing its more about does this person match the team and knows how to work in team/pair.
On the doing end, I basically have always said no to homework interviews (they’re usually open-ended but just really boring and seem time consuming). An exception has been one place that had interesting questions (sort of “Advent of Code”-style stuff, where it’s not algorithmic prowess, more just a bit of elbow grease and a fun result). For face-to-face stuff, it’s been usually pretty awful. The worst was doing a really simple algorithm problem on a board, and then having the interviewer try to press me on index math (my original solution involved some zipping and stuff and the guy was like “let’s stick to C-ish semantics”). Very frustrating stuff. I also messed up a “string reversal” exercise through my own fault (it was easy in theory!) I feel like it’s a good test of “can you solve advent of code stuff fast”.
On the giving end, we have a vertical slice of a django application that we use for “full-stack”/backend roles. I think it’s been very effective. People pass with flying colors or fail entirely (we really try to make people pass because of all the stress etc involved, and try to reassure people that we are really not trying to ding anyone). And we try to have a lot of varied angles, so people can show off what they know. Again, we are trying to make people pass. Seeing people succeed is extremely gratifying and I’ve learned some stuff from watching people do it.
We aren’t doing fancy algo stuff so we don’t talk about fancy algo stuff (unless candidate brings it up and it’s a fun conversation). We are a CRUD-y webapp with a bunch of legacy code, so we test CRUD-y webapp skills on an unknown codebase.
Coding during an interview is completely fine for a senior engineer. I want to be able to understand how a candidate is able to solve problems. I agree that throwing them into a viper pit when they show up isn’t ideal, and certainly what it can feel like. But coding interviews are great when it’s not about fussing over which libraries or random trivia they know. Interviewers have to create a good environment and strategy to test for the signals they’re looking for (without overfitting).
I’ve had plenty of interviews where they are just testing me on random framework trivia. And it’s just like…yeah, what happens when we stop using that framework? People don’t think beyond that at all. Funny enough, when I ended up taking those jobs, it turns out the culture is toxic and full of insecure people who are aggressive so they don’t get found out to have imperfect engineering knowledge.
And in startups it’s especially important to have a strategy because you’ll often see the interviewers (who would be the candidate’s peer) come up with insane problems that are simply a way to scare away competition and aren’t even trying to perceive if the person is reasoning well. I haven’t seen this lead to positive outcomes. – And of course suddenly all the companies are throwing their hands up wondering where the talent is…
I had a coding interview this year that did not go well and felt really misplaced. My entire 20 year career had no bearing on the interview (other than to get it in the first place). It was to code a representation and traversal function of a directional graph. Yes the topic is applicable but the conditions are very artificial. It felt like for example a famous geometric mathemetician with numerous published papers, and the interview is - here solve this rubix cube in the next 5 minutes. What?
What I’d like to see is an analysis of what I have done. Instead of hunting resumes, there should be an automated analysis of all my github repos, looking for certain patterns or structures applicable to the job being filled. Then the job is more or less offered up front - hey we see you’re already good at this. If you want the job, its yours.
I think there is a middle ground here, and it’s striking to me that it’s not evident in any of the stories below. There are other ways to do the coding interview besides coding a red-black tree in a coding pad, or fizzbuzz.
In fact there are myriad small programs and exercises that you could present someone besides the trivially easy and the CS-301. The world is full of examples of small, self contained systems: little automata, or tiny models of business logic systems involving prototypical situations like document management, blog posts, what have you. These sorts of exercises have lots of scope for testing things like input validation, choice of data structures (not coding one up from scratch!!), sort and filter, and so on.
Hand in hand with this is the fact that it is quite possible to provide a candidate with a much more structured starting point than a whiteboard or a blank scratchpad. The classic ‘make these tests pass’ example is a great way to orient a candidate. Similarly, you can do a tiny bit of scripting and a little github work to get them some files that they can work on in the comfort of their own dev environment.
The coding exercise CAN be both invaluable at seeing how a candidate makes programming decisions and communicates them, and also fairly painless for the candidate. I’m surprised at the number of interviewers out there who seem to have never taken the time to actually consider what they’re testing for, such that they still seem to assume that the point is to have studied the graph inversion algorithms that they once had to learn in school, by no evidence aside from it was what they had to do to get their job.
I’ve been dealing with a lot of this lately (yay job search), and it’s all so tiresome.
Setting aside the kvetching about tooling, or about “it’s been 20 years why do i have to remember data structures waaaaaah”, or “i don’t like performing under pressure whiteboards are scary” (all of which I have little sympathy for; we get paid six figures and get to have soft hands, learn how to keep your fucking cool)…
…it’s about respect.
I’m telling a potential employer, as a senior (staff, principal, fellow, etc.): “Hey, I know my shit, I know how to deliver value, I’ve been around, let’s move on”. And they either trust me, or they don’t trust me and make me jump through hoops. Fuck them if we’re gonna start out with mutual distrust and disrespect.
Successful companies that recognize this tend to either trust candidates (and fire them quickly if they’re incompetent), or they show the respect of saying “Look, we can’t just take your word for it–much as we may like to–but we also know your time is valuable so we’ll pay you to jump through these hoops. Worst case, you get compensated and we learn we shouldn’t have hired you. We’ll set you up in our codebase and do something together.”
See how respectful that is? The company doesn’t start off with their hands in my proverbial pocket, fucking me over by getting me to work uncompensated. I won’t work for such a company, and neither should any of you.
And for all of you people fretting over race and minority status out there…I’ll note that this approach does make it easier for folks without privilege to make it through the process (though if you’re interviewing for a senior role you should be economically secure enough in your career that that is more symbolic than practical).
though if you’re interviewing for a senior role you should be economically secure enough in your career that that is more symbolic than practical
This assumption is incredibly limiting. When I last interviewed for a senior role at a Silicon Valley tech company (~16 hour flight), they let me know they’d give a per diem for the three days I’d be there. That was helpful, but what ended up happening is they told me to keep receipts and they’d reimburse me after.
As a person with distinctly less privilege than some, I couldn’t actually afford to feed myself in SF on zero notice — my previous job was distinctly non-Silicon Valley, and the exchange rate and difference in cost of living enormous — and had to borrow money from my mother before I went to the airport. Awkward.
(I got the job, easily, and it was very financially rewarding while I was there. Now I am very privileged.)
Aren’t interviews fundamentally about putting a person on the spot? And by all means I agree that it’s not ideal, but joining a new work environment is precisely that. I don’t see why the discussion is centered on the “why would you ask me to reverse a binary tree” type problems.
Applicants that can do well under pressure and/or have time and energy to prepare well to answer questions about obscure algorithms will likely continue to do so. On a large enough scale, a firm can exploit this to drastically cut out false positives.
This is indeed inefficient, but more so in the economic sense. Applicants will spend hours of productive work preparing for their expectations of what will be asked. Secondly, it risks excluding individuals on the basis of their material conditions; who in our society does better under pressure (definitely not oppresed minorities), who can afford to “grind Leetcode” for months prior to the interview?
Aren’t interviews fundamentally about putting a person on the spot?
Interviews are fundamentally about learning more about the candidate (and giving the candidate an opportunity to learn more about the company and team).
Putting them on the spot is not the point, unless it’s a specific type of interview for a very high-stress, split-second industry like EMT or air traffic controller. Software developers don’t code “on the spot”, unless the company culture is pathological. Instead, they code in ways sustainable in the long term, or during a crunch. Even in the latter, they’re not expected to solve data structure puzzles within the hour or lose their employment.
The goal of an interview is to determine how well a candidate will do in a given role. The more we make interviews about “putting a person on the spot” instead, the more we make the company culture about firefighting and crunch.
If you are a company that has oncall and need engineers to be able to fix something in an emergency, then testing for ability under pressure is not a bad thing. In that case maybe the test should be for under pressure debugging instead of memorizing algos, though.
I don’t think you can set an artificial fire and put it out with any meaningful output - every company has unique practices, tooling, playbooks, etc.
When I’ve sat in on SRE/ops interviews I’ve seen good outcomes from describing a hypothetical environment - web server and DB, your web server is throwing a 503 error - and walking through the troubleshooting steps. It can be relatively low pressure, but I’ve seen good signals: experienced ops people talk about remaining calm, surveying the landscape with familiar tools (ping, dig, etc), and build up a very quick mental model of the problem.
I won’t join companies that think day to day programming work should be a high-stress environment. Especially not the ones that do it on purpose to maximize exploitation of their work force.
Technical interviews should be focused on relevant experience uncovered through open-ended questions. You can ask the candidate walk through a code sample they’re especially proud of. If they are unable to furnish any, provide a coding challenge that is representative of what they’d actually be doing (but not the actual work, which is an ethical red flag). They can do the challenge at home and bring their solution to the interview. When reviewing the candidate’s code, ask open-ended questions about what they learned when writing it, what alternative approaches they considered, or what they enjoyed most about it. If you’re paying attention to the human being on the other side of the table, their strengths and motivations relative to the job requirements will reveal themselves quickly.
The only value of on-the-spot challenges is to establish the dominance of the interviewer over the candidate. Pass or fail, the candidate is made to feel like a pet doing a trick for their prospective master. Neither party may be fully conscious of the adversarial nature of these interviews, but I do not interview people this way and tend to avoid employers that do.
I believe that “bullshitters”—people who intentionally misrepresent themselves to hustle their way into a job they know they are not qualified for and are used to justify on-the-spot challenges—are over-counted and over-anticipated. Most of the time, when someone is under-qualified, it is either because they didn’t read the job requirements thoroughly enough or because the requirements weren’t accurately described to them in the first place. Both are unfortunately frequent but honest misunderstandings. There are also other reasons why new hires don’t work out. When the manager and the new hire start their relationship on the wrong foot (e.g. by running them through a gauntlet in the interview process) it can have a demoralizing effect. I have only ever encountered one genuine bullshitter in 15 years of interviewing people. He had built his entire career out of elaborate reverse-engineering schemes, which he freely admitted to me after I asked him a series of open-ended questions about the code he showed me. (It was written in a language I didn’t even know very well, so my questions were fairly naïve and non-confrontational). A bullshitter runs out of runway very quickly when asked about code they did not actually write. A bullshitter is also the kind of person who would prep for an interview by memorizing a solution to fizzbuzz and a dozen other irrelevant but nevertheless popular whiteboard coding challenges.
All of the “I really enjoy coding interviews” replies have been surprising
and enlightening, though considering how variable human psychology is,
maybe I shouldn’t be surprised.
One of the places I worked ended up being a contract-to-hire kind of
thing. No real coding interview to speak of. I was given a task and
a deadline, and they onboarded me into their codebase. We were both taking
a risk. They were happy with the final product, so I was given something
more difficult. A round or two of that, and I went from contract to
full-time. That was a good hiring experience; either of us could have
noped out during the “getting to know you” period.
I hate algorithm quizzes. I don’t know how to invert a red-black tree on a whiteboard because I focus on situations that reality demands rather than theoretical ones. I flunked an interview once because I didn’t know how to invent a search engine on a whiteboard.
I am not offended by fizzbuzz. It gives me the opportunity to make the most over-engineered fizzbuzz ever and take the screener to alice in wonderland and back.
Yeah, I kind of like to do something like the following. I don’t know whether it’s actually good policy, but such questions annoy me. And the interviewer quite likely doesn’t know how some parts work.
#include <stdio.h>
#define F "fizz"
#define B "buzz"
char is[4], *s[] = {is, F, B, F B};
int main(){
for (int i=1; i<=100; ++i){
sprintf(is, "%d", i);
printf("%s\n", s[0x1241843>>2*(i%15)&3]);
}
}
We just interviewed a couple candidates for a senior role at my company. None of the interview team is pedantic about syntax, or asks about obscure data structures. In fact, we mostly have asked easy questions to focus more on requirements and discuss the solution in depth. Still, candidates with 20 years of experience have had trouble doing simple problems (think averaging some numbers in a list, etc). Design questions are asked too, it’s not all about coding, especially for senior positions.
I know everyone already tore this article up, but I had to add another data point now that I’m finally in an interviewing position. I think only some FANG interview in this leetcode-heavy way.
I thought the school analogy was particularly apt.
Unfortunately, it would seem there is little measure of a programmer’s competence or ability, other than through “grade 8” textbook problems or general IQ type tests. Perhaps we should stop the charade of calling ourselves “engineers”.
I learned how to balance a red-black tree in college, 20+ years ago, and that’s the last time I ever balanced a red-black tree. Unless the job is writing data structures libraries, why would you ask me that?
I’ve built large, production systems used in the most secure environments in the world. My code is secure, performant, accurate, and safe…but no, I don’t remember how to find all palindromes in a string off the top of my head.
I remember interviewing at one of the Big Companies. I said I knew C. They asked me which format specifier in printf would do some obscure thing. I didn’t remember. Guess what? I’ve been writing C for…26? years now and I still sometimes look at man pages. I’d be more worried about a developer who didn’t, honestly.
Unless the job is writing data structures libraries, why would you ask me that?
Additionally, if I asked an engineer to build a data structures library with red-black trees and they started coding without immediately reaching for a description of the operations, invariants to maintain, etc, for a proper red-black tree, I’d be really nervous. It’s like when a waiter doesn’t write down your order.
To be fair, an experienced waiter can probably keep your order in their head…
I know that in some places it’s considered a badge of honour to be able to take everyone’s order without writing it down, but for many customers it just makes the service worse. I literally do not care how my order gets to the chef. All I care about is that it is correct. Writing it down increases my confidence that it will be correct, meaning that in the wait between ordering and getting my food, I can relax, confident that in due time they will bring me the right things, instead of worrying that I’m going to have to spend my evening negotiating with the waiter and waiting for the chef to get my order right by trial and error.
In a similar fashion, remembering how to implement a selection of obscure algorithms is really low on the list of priorities for a software engineer. You could almost argue that for interview purposes, you want a problem the interviewee hasn’t met before, so you can actually observe how they go about solving it.
Everybody’s got their own thing going on, but I can’t help thinking you might be optimizing for the wrong kind of restaurant experience.
At risk of breaking the metaphor, we should optimize for safety first: Don’t serve allergens to patrons who indicate food allergies. This suggests that orders should be written down or tabulated in point-of-sale systems, rather than memorized, and that orders should be systematically assembled rather than designated by petnames.
Whether the waiter can or not, I trust the process less if they don’t write it down.
I think this might be a “restaurant as status experience” thing? The waiter shows off their memory, this demonstrates that they’re a good waiter, which makes this a good restaurant, which makes you a person who eats at a good restaurant.
I don’t know if it is an US thing but having been waiter/bartender/manager in multiple bars and restaurants in Europe, I think a lot of folks here seems to have had a bad experience with waiters or hold a grudge on how to optimize the certainty of having exactly what they said done. And for siblings comments comparing taking notes as a SE and waiters, I would love to see how SE making minimal wage and living on tips would learn to optimize their workflow.
I have been trained to not write down for any table under five people. I insist on trained, first we were allowed to take note for anything and after a few days/a week, you stop taking notes for any table under four etc. It began to be a challenge between colleagues. Bref, all in all you develop a kind of memory palace of your restaurant and their table and make weird association between guest and their commands, your optimize also your work and your are faster and more precise at the end of the day because you will remember longer. Heck, I still have in my memory the set up of tables of all the place I worked in and the orders of regulars and from random people that I happen to see in the city I was living burned in my head years later.
As a manager, my rule to train my team was to be able to take order for table of X where X was our average table. It was speeding up the process, making waiter more aware of the flow of his tables, better balance the workload to the bar and the kitchen by timing when to take some orders, reshuffle orders order to let a two people table bypass the ten people table before it reaches the kitchen or later with kitchen. And bartenders and cooks have to learn and do the same. A restaurant is never a FIFO sequential process, you have to manage a concurrent/parallel environment when everybody needs to be served at the right timing, within a known acceptable lag. Having waiters able to memorize your order but also remember it as long as you are in the restaurant, it is similar to the cookie session in your browser.
Zeigarnik effect. Waiters don’t have to analyze, break down, reshuffle and regroup their orders. Software developers do that all the time. I don’t trust those who don’t take notes. All software developers take notes. Good and bad ones. Those who don’t - are not software developers, at best, they are code-monkeys.
Also, red-black trees suck. Keeping the colour in every tree node bloats the data – quite probably by 8 bytes for the struct size on a modern machine, and many malloc libraries round up to the next multiple or 16 or 32 bytes. And both red-black and AVL algorithms are complex.
Hash tables are generally more useful now, and b-tree like structures make more sense given cache line sizes (or VM pages), but if I do require a balanced binary tree then my go-to now is the scapegoat tree. The code is much simpler and smaller, there is nothing extra in each node, and it requires only a few bytes of extra global storage (for powers of your acceptable unbalance factor) for all trees, plus one integer per tree if you will be allowing nodes to be deleted. I can and have written complete bug-free code for scapegoat tree in 5 minutes in programming contests/exams where standard libraries were not allowed to be used.
But, yes, the main point here is that if I need to write code for a data structure or algorithm for my actual job then I research the literature, find the best thing, implement it very carefully (possibly with modifications), put it into production, AND THEN FORGET THE DETAILS to make room in my brain for the next task.
I call BS on the premise of this article. There are bad coding interviews and good coding interviews. Those that literally test the ability to code at all are necessary because most teams need senior engineers who can actually code. Fizzbuzz, word counting, and the like do actually test if someone can code at all. I’ve seen senior engineers who couldn’t do simple coding tasks requiring no specific knowledge.
Further I’d say that environments where senior engineers don’t code are miserable- decisions are made by people who don’t actually have to deal with the consequences on a daily basis, and junior engineers are usually left entirely figuring things out for themselves.
Asking a senior engineer to do FizzBuzz only demonstrates to the candidate that you don’t value their time, and your recruiters aren’t doing their job. If you’re worried that someone has flat-out lied on their resume, then do a background check and have interviewers skilled enough to spot bullshit. You’re supposed to be evaluating candidate’s expertise, and how their experience is relevant to your company, not checking whether they’re a junior who’s practiced interview quizzes.
It happens that people who can code well fail coding interviews spectacularly. Not everyone handles high-stress situations. Coding on a whiteboard or someone else’s unconfigured computer is uncomfortable and distracting. Candidate might misunderstand your question. They might stumble on something trivial, which they’d have googled in a real environment.
For us, we do 3 basic “Fizzbuzz” style questions as part of a pre-screening via coderpad. They’re permitted to use the language of their choosing, ask questions, google, etc. It takes less than 15 minutes and is more about basic “read requirements; implement basic solution” rather than leetcode or those silly gotcha style ones that have obscure, subtle solutions. I wish we could eliminate it entirely, but it still weeds out about 10% of applicants. It also means we don’t have to try and suss out whether someone can code at the next phase of the interview which is more open-ended and explores how they break down requirements, architect, etc.
So that’s fine and even makes some sense for cold-drop applicants you don’t know from Adam or Eve (although I’ve soured on that approach and had more success with other mechanisms). Where it gets my back up is that as a Senior who currently does all of my work open source, I’m far more likely to enter your hiring pipeline via a recruiter attempting to poach me than as a random person in your resume inbox.
I’d say, maybe, 75% of the time that seems to involve the recruiter prequalifying me and then dropping me into a hiring pipeline that immediately asks me to write some fizzbuzz style test. That’s an immediate hard No from me.
You could learn far more, with far richer signal, about 1) whether or not I can code, 2) how I approach real-world problem solving, and 3) how I deal with collaborating with others simply by looking at my commits, PR reviews, and discussions in Issues in the wide-open GitHub repo that’s the entire reason you decide to approach me in the first place. All these standardized tests accomplish in these cases are to tell me that either your Org is so dysfunctional that your hiring pipleine has no clue who your recruitment people are handing to it (in which case, why am I wasting my time on you?), or you and your Org are so blinkered by Process Uber Alles thinking that you prefer to confine yourself to the standard and much lower value signal of fizzbuzz than taking advantage of the richer source of information you have access to (in which case, again, why am I wasting my time on you?).
The suspicious bastard in me also thinks these tests are largely intended to serve the purpose of trying to confuse the issue of who’s pursuing who, trying to make me sell myself to you when really it should be entirely the other way around. That’s a game I decline to play – I don’t know who you are and you’re the one who approached me, don’t expect me to have any reason to want to prove myself to you.
(Obviously the “you” here is less you specifically and more “the phenomenon of employers dogmatically administering these silly tests I have encountered repeatedly”).
I don’t want to be too dismissive, but we’ve interviewed for senior-ish positions, and hey, the “fizz buzz” filtered out people! Meanwhile the coding stuff is like… fine, and it gives people a chance to shine.
We extremely take into account the issues with coding interviews when applying them. We don’t ask arcane stuff. We set up an environment and a “full-ish” project. Our walkthrough is based on a thing we actually had to build (and various tiny bugs we kinda had). We make sure to say we’re not trying to judge them on arcane shit, and this is a point of conversation.
We have had two sorts of results from this:
candidates take a bit of time to click through stuff, and ask questions. We go through some high-level stuff while also fixing up some low-level bugs. We see some varied ways to go about problems, and soimetimes outright stop the “coding” part to just talk about more interesting details, cuz we got the proof we needed.
candidates are completely lost in the material. We try to deviate to really simple stuff , down to just like “hey, here’s this stacktrace that you’re seeing, where should we go now”. We try really hard to get any sort of positive thing from the candidate and don’t.
Now yeah, in a work environment you have less stress going on. But our thing is really easy, and to be honest a huge part of maintaining an existing app is handling a bunch of code you have never seen in a reasonable amount of time.
We think it’s representative of some of the work, answers loads of questions frequently, and we have never gotten stuff on the edge. The bimodal nature makes me even more confident this isn’t totally broken. And it’s done in less than 60 minutes. Which I think is way more respectful of people’s time than a take-home project.
I feel like people conflate “coding interview” with “fizz buzz”, but if you take one of your engineers to the side and ask them to spend a day or two building out a vertical slice of one part of your application, it could be a very good playground for something very effective.
Here’s an interview where the interviewer respects the interviewer’s time and expertise, it’s the mock interview that Casey Muratori (of HandMade Hero fame) gives to Shawn McGrath.
To sum it up. You ask about a topic that the interviewee finds interesting and then you do a deep dive into it. That allows for so much more information to be obtained than a dumb code challenge that can be memorized by desperate candidates.
For people that have public projects on github nothing can be easier. For people that don’t have public code, see the interview itself.
(Paraphrasing) “It’s not an answer, it’s knowing for sure that you’re able to reason from the problem to the answer in your head”
Thank you for mentioning this interview. I had seen the link a couple of times before. I bailed out on each viewing due to the length. This time, based on your recommendation, I skipped around sampling how the interview went.
In general, the comment thread here has been fascinating.
Does anyone actually enjoy coding interviews? I’ve only been on the receiving end. Between anxiety and social phobia and feeling threatened by strangers, I’m in fight-or-flight mode, with the rational part of my brain shutting down. What’s funny is that I can do public speaking quite effectively, because I can prepare for it. In other words, switch on the autopilot and let my programming take over (no pun intended).
Yes! But, I am a white male with a lot of experience, so I am not worried about a lack of opportunity if I screw up.
For me, the only prep I do for interviews is to read one or two good articles to get my mind in tech land, and go in cold, otherwise. I draw upon my experiences to recognize problems and have an honest conversation, share my thoughts, keep an open dialogue, ask questions, etc.
I enjoy the random set of challenges being thrown at me. I have been passed on at some FAANG companies, but I have had a very successful and fulfilling career working with amazing people, on impactful products, so… for me this strategy has worked out very well! And, I’ve never come out of an interview without learning something new.
I like to interview semi-regularly – at least once every 1.5 years. I enjoy doing this for several reasons:
But when I treat interviews like this, there’s zero stress for me: my interviews are just like yours, a nice conversation, open dialogue about problems I’ve solved and problems the business faces, and generally easy and comfortable.
E: Because apg pointed it out, and I think it matters: I definitely have the same privilege he does, which changes my perspective, and when I’m on the other side of the table and evaluating candidates I consistently try to make that count less. One tip I got: I often get to review resumes to decide who to ask for a phone screen, and I’ve asked the internal recruiters I work with to send me resumes with no identifying information. I don’t know how it changes my recommendations, but it’s one more avenue that keeps any implicit bias from slipping in, so I suspect it’s worthwhile.
I don’t do biographical interviews anymore, and so I don’t even look at the person’s resume at all, until after I’ve submitted my evaluation. The interview feedback my company uses is based on our principles and each interview attempts to evaluate the candidate against a set of them. I’ve not been here long enough to have strong opinions on it yet. So far, I’ve enjoyed the attempts the framework makes to be unbiased, and feel that decisions have been fairly obvious as a result.
The interview I’ve been doing is a systems design thing, so technical, but not coding.
I’ve been trying to steer the ship away from the “resume -> phone screen -> broader phone screen -> in person” pipeline for a while, but it is fairly ingrained.
Could you share some examples on this? I suspect I’m about to be on another round of interviews and am curious how this works.
Principles – each of the interviews has a set of these that can be evaluated. Sometimes the interviews overlap in these principles, which is fine. The interview feedback I fill out has specific questions related to the interview, with a big focus on the principles.
I appreciate your perspective and willingness to point out that it’s considerably easier as a white male.
I’m not convinced that being a white male helps, though that may depend where you are. At my place of work they have quotas with the effect that women get places more easily.
I enjoy coding interviews to a large extent but it is always a major relief when they’re over. And I’m never fully relaxed in any kind of interview. I do very extensive preparation. My mind tends to go blank when asked for examples from my past experience. And, I’m probably not very good at interviews because in 25 years I’ve only ever landed one job offer after an interview. That’s included two rejections from FAANG companies. So by my example, being a white male with lots of experience is not enough on its own. Only time I’ve changed jobs it was to a competitor where they already new me well from working with me for the same client - and that didn’t last long because my original company bought them.
Hmm. This reads to me as if you don’t believe that white male privilege exists, and instead of responding with ways in which I’ve benefited over the years, I’ll ask you to see if any of these 160 things happen to apply to your situation, especially the work place section? I get that the name of this website may sound pretty scary, but I hope you can look past any potential bias there and give it a fair read.
Fun story from my past: I once worked for a company that announced a new diversity and inclusion “council” which was literally comprised of 3-4 Director level folks, 2-3 senior managers, all of which were white and male. I wish I could say that I had trust in this initiative, but needles to say that it was adjusted after some of us raised very publicly that this seemed like a questionable choice.
Try not to worry about whether or not the deck is stacked against you (some folks will insist it is, many will insist it isn’t, some will try to gaslight you about your own experiences either way); there are probably easier wins (resume polishing, practice being interviewed and general social anxiety defusing tricks, better negotiation techniques, and so forth) than worrying about things you can’t control. Good luck to you!
It’s natural that loss of privilege can feel like oppression. I try to take comfort from knowing that many other peoples’ real oppression is really being diminished.
I really enjoy coding interviews. I like high pressure/challenging scenarios, it’s a situation where preparedness pays off and I am a very social person. It’s also a great opportunity to learn more about how other people do their business, and how they interview people. Getting interviewed makes me a better interviewer.
I don’t mind coding interviews as such, but I do mind the kind where you’re expected to spend a lot of time on them (especially the “homework” ones).
Yes. I love coding interviews. This is an employee market, if I fail, l’ll interview somewhere else. Companies should be more worried about their false negative rate and the time they waste interviewing people, but they don’t… Their loss. To make a moneyball analogy: there are a lot of undervalued players on the market.
I’ve been on both sides. And I considerably prefer the interviewee side, I rarely learned something or been challenged/amazed on the interviewer side.
For context, I am as privileged as /u/apg, YMMV.
Yes, I do. Rather, I like the effect they have on job hunting as a whole. I don’t think it’s ever been easier to increase your income than before since you can prove your skills in a few hours. Solve some problems, get a bump in comp or move over to another company with a different wlb. The true interview is the first 3 months working with people, not the first few hours spent locked in a single room with them.
There are people who enjoy, but this question may apply to any kind of interview. Most people don’t enjoy at all any type of interview. It does not matter if you are a software developer, a pilot or a teacher, it is not a situation we are used to be and when we are not able to show our best, we feel sad.
On the other hand, I see a lot of complaints on the coding interview with regards to white board interview and questions. What I see on those complaints is that people actually do not propose a real solution to it, just pure complaints.
I made more than 130+ interviews during the last 3 years as an interviewer. During my interviews I never focus on the code the person writes, but if I can work with the person. I look for values such as: the person makes questions, can we communicate properly, can we have work together on a programming challenge. What I find wrong is to ask something very specific like RBT and expect to implement and remember it: this is super specific and does not tell you if you will succeed in the position.
For me interviewing its more about does this person match the team and knows how to work in team/pair.
I don’t mind them as much now that I learned how to do them… its just a lot of effort. With that said… I’m also not that good at them. lol
On the doing end, I basically have always said no to homework interviews (they’re usually open-ended but just really boring and seem time consuming). An exception has been one place that had interesting questions (sort of “Advent of Code”-style stuff, where it’s not algorithmic prowess, more just a bit of elbow grease and a fun result). For face-to-face stuff, it’s been usually pretty awful. The worst was doing a really simple algorithm problem on a board, and then having the interviewer try to press me on index math (my original solution involved some zipping and stuff and the guy was like “let’s stick to C-ish semantics”). Very frustrating stuff. I also messed up a “string reversal” exercise through my own fault (it was easy in theory!) I feel like it’s a good test of “can you solve advent of code stuff fast”.
On the giving end, we have a vertical slice of a django application that we use for “full-stack”/backend roles. I think it’s been very effective. People pass with flying colors or fail entirely (we really try to make people pass because of all the stress etc involved, and try to reassure people that we are really not trying to ding anyone). And we try to have a lot of varied angles, so people can show off what they know. Again, we are trying to make people pass. Seeing people succeed is extremely gratifying and I’ve learned some stuff from watching people do it.
We aren’t doing fancy algo stuff so we don’t talk about fancy algo stuff (unless candidate brings it up and it’s a fun conversation). We are a CRUD-y webapp with a bunch of legacy code, so we test CRUD-y webapp skills on an unknown codebase.
[Comment removed by author]
I could code FizzBuzz on the fly and you should not hire me.
Coding during an interview is completely fine for a senior engineer. I want to be able to understand how a candidate is able to solve problems. I agree that throwing them into a viper pit when they show up isn’t ideal, and certainly what it can feel like. But coding interviews are great when it’s not about fussing over which libraries or random trivia they know. Interviewers have to create a good environment and strategy to test for the signals they’re looking for (without overfitting).
I’ve had plenty of interviews where they are just testing me on random framework trivia. And it’s just like…yeah, what happens when we stop using that framework? People don’t think beyond that at all. Funny enough, when I ended up taking those jobs, it turns out the culture is toxic and full of insecure people who are aggressive so they don’t get found out to have imperfect engineering knowledge.
And in startups it’s especially important to have a strategy because you’ll often see the interviewers (who would be the candidate’s peer) come up with insane problems that are simply a way to scare away competition and aren’t even trying to perceive if the person is reasoning well. I haven’t seen this lead to positive outcomes. – And of course suddenly all the companies are throwing their hands up wondering where the talent is…
I had a coding interview this year that did not go well and felt really misplaced. My entire 20 year career had no bearing on the interview (other than to get it in the first place). It was to code a representation and traversal function of a directional graph. Yes the topic is applicable but the conditions are very artificial. It felt like for example a famous geometric mathemetician with numerous published papers, and the interview is - here solve this rubix cube in the next 5 minutes. What?
What I’d like to see is an analysis of what I have done. Instead of hunting resumes, there should be an automated analysis of all my github repos, looking for certain patterns or structures applicable to the job being filled. Then the job is more or less offered up front - hey we see you’re already good at this. If you want the job, its yours.
I think there is a middle ground here, and it’s striking to me that it’s not evident in any of the stories below. There are other ways to do the coding interview besides coding a red-black tree in a coding pad, or fizzbuzz.
In fact there are myriad small programs and exercises that you could present someone besides the trivially easy and the CS-301. The world is full of examples of small, self contained systems: little automata, or tiny models of business logic systems involving prototypical situations like document management, blog posts, what have you. These sorts of exercises have lots of scope for testing things like input validation, choice of data structures (not coding one up from scratch!!), sort and filter, and so on.
Hand in hand with this is the fact that it is quite possible to provide a candidate with a much more structured starting point than a whiteboard or a blank scratchpad. The classic ‘make these tests pass’ example is a great way to orient a candidate. Similarly, you can do a tiny bit of scripting and a little github work to get them some files that they can work on in the comfort of their own dev environment.
The coding exercise CAN be both invaluable at seeing how a candidate makes programming decisions and communicates them, and also fairly painless for the candidate. I’m surprised at the number of interviewers out there who seem to have never taken the time to actually consider what they’re testing for, such that they still seem to assume that the point is to have studied the graph inversion algorithms that they once had to learn in school, by no evidence aside from it was what they had to do to get their job.
I’ve been dealing with a lot of this lately (yay job search), and it’s all so tiresome.
Setting aside the kvetching about tooling, or about “it’s been 20 years why do i have to remember data structures waaaaaah”, or “i don’t like performing under pressure whiteboards are scary” (all of which I have little sympathy for; we get paid six figures and get to have soft hands, learn how to keep your fucking cool)…
…it’s about respect.
I’m telling a potential employer, as a senior (staff, principal, fellow, etc.): “Hey, I know my shit, I know how to deliver value, I’ve been around, let’s move on”. And they either trust me, or they don’t trust me and make me jump through hoops. Fuck them if we’re gonna start out with mutual distrust and disrespect.
Successful companies that recognize this tend to either trust candidates (and fire them quickly if they’re incompetent), or they show the respect of saying “Look, we can’t just take your word for it–much as we may like to–but we also know your time is valuable so we’ll pay you to jump through these hoops. Worst case, you get compensated and we learn we shouldn’t have hired you. We’ll set you up in our codebase and do something together.”
See how respectful that is? The company doesn’t start off with their hands in my proverbial pocket, fucking me over by getting me to work uncompensated. I won’t work for such a company, and neither should any of you.
And for all of you people fretting over race and minority status out there…I’ll note that this approach does make it easier for folks without privilege to make it through the process (though if you’re interviewing for a senior role you should be economically secure enough in your career that that is more symbolic than practical).
This assumption is incredibly limiting. When I last interviewed for a senior role at a Silicon Valley tech company (~16 hour flight), they let me know they’d give a per diem for the three days I’d be there. That was helpful, but what ended up happening is they told me to keep receipts and they’d reimburse me after.
As a person with distinctly less privilege than some, I couldn’t actually afford to feed myself in SF on zero notice — my previous job was distinctly non-Silicon Valley, and the exchange rate and difference in cost of living enormous — and had to borrow money from my mother before I went to the airport. Awkward.
(I got the job, easily, and it was very financially rewarding while I was there. Now I am very privileged.)
Ah, I see the issue there.
Aren’t interviews fundamentally about putting a person on the spot? And by all means I agree that it’s not ideal, but joining a new work environment is precisely that. I don’t see why the discussion is centered on the “why would you ask me to reverse a binary tree” type problems.
Applicants that can do well under pressure and/or have time and energy to prepare well to answer questions about obscure algorithms will likely continue to do so. On a large enough scale, a firm can exploit this to drastically cut out false positives.
This is indeed inefficient, but more so in the economic sense. Applicants will spend hours of productive work preparing for their expectations of what will be asked. Secondly, it risks excluding individuals on the basis of their material conditions; who in our society does better under pressure (definitely not oppresed minorities), who can afford to “grind Leetcode” for months prior to the interview?
Interviews are fundamentally about learning more about the candidate (and giving the candidate an opportunity to learn more about the company and team).
Putting them on the spot is not the point, unless it’s a specific type of interview for a very high-stress, split-second industry like EMT or air traffic controller. Software developers don’t code “on the spot”, unless the company culture is pathological. Instead, they code in ways sustainable in the long term, or during a crunch. Even in the latter, they’re not expected to solve data structure puzzles within the hour or lose their employment.
The goal of an interview is to determine how well a candidate will do in a given role. The more we make interviews about “putting a person on the spot” instead, the more we make the company culture about firefighting and crunch.
If you are a company that has oncall and need engineers to be able to fix something in an emergency, then testing for ability under pressure is not a bad thing. In that case maybe the test should be for under pressure debugging instead of memorizing algos, though.
I don’t think you can set an artificial fire and put it out with any meaningful output - every company has unique practices, tooling, playbooks, etc.
When I’ve sat in on SRE/ops interviews I’ve seen good outcomes from describing a hypothetical environment - web server and DB, your web server is throwing a 503 error - and walking through the troubleshooting steps. It can be relatively low pressure, but I’ve seen good signals: experienced ops people talk about remaining calm, surveying the landscape with familiar tools (ping, dig, etc), and build up a very quick mental model of the problem.
I won’t join companies that think day to day programming work should be a high-stress environment. Especially not the ones that do it on purpose to maximize exploitation of their work force.
Technical interviews should be focused on relevant experience uncovered through open-ended questions. You can ask the candidate walk through a code sample they’re especially proud of. If they are unable to furnish any, provide a coding challenge that is representative of what they’d actually be doing (but not the actual work, which is an ethical red flag). They can do the challenge at home and bring their solution to the interview. When reviewing the candidate’s code, ask open-ended questions about what they learned when writing it, what alternative approaches they considered, or what they enjoyed most about it. If you’re paying attention to the human being on the other side of the table, their strengths and motivations relative to the job requirements will reveal themselves quickly.
The only value of on-the-spot challenges is to establish the dominance of the interviewer over the candidate. Pass or fail, the candidate is made to feel like a pet doing a trick for their prospective master. Neither party may be fully conscious of the adversarial nature of these interviews, but I do not interview people this way and tend to avoid employers that do.
I believe that “bullshitters”—people who intentionally misrepresent themselves to hustle their way into a job they know they are not qualified for and are used to justify on-the-spot challenges—are over-counted and over-anticipated. Most of the time, when someone is under-qualified, it is either because they didn’t read the job requirements thoroughly enough or because the requirements weren’t accurately described to them in the first place. Both are unfortunately frequent but honest misunderstandings. There are also other reasons why new hires don’t work out. When the manager and the new hire start their relationship on the wrong foot (e.g. by running them through a gauntlet in the interview process) it can have a demoralizing effect. I have only ever encountered one genuine bullshitter in 15 years of interviewing people. He had built his entire career out of elaborate reverse-engineering schemes, which he freely admitted to me after I asked him a series of open-ended questions about the code he showed me. (It was written in a language I didn’t even know very well, so my questions were fairly naïve and non-confrontational). A bullshitter runs out of runway very quickly when asked about code they did not actually write. A bullshitter is also the kind of person who would prep for an interview by memorizing a solution to fizzbuzz and a dozen other irrelevant but nevertheless popular whiteboard coding challenges.
All of the “I really enjoy coding interviews” replies have been surprising and enlightening, though considering how variable human psychology is, maybe I shouldn’t be surprised.
One of the places I worked ended up being a contract-to-hire kind of thing. No real coding interview to speak of. I was given a task and a deadline, and they onboarded me into their codebase. We were both taking a risk. They were happy with the final product, so I was given something more difficult. A round or two of that, and I went from contract to full-time. That was a good hiring experience; either of us could have noped out during the “getting to know you” period.
I hate algorithm quizzes. I don’t know how to invert a red-black tree on a whiteboard because I focus on situations that reality demands rather than theoretical ones. I flunked an interview once because I didn’t know how to invent a search engine on a whiteboard.
I am not offended by fizzbuzz. It gives me the opportunity to make the most over-engineered fizzbuzz ever and take the screener to alice in wonderland and back.
Yeah, I kind of like to do something like the following. I don’t know whether it’s actually good policy, but such questions annoy me. And the interviewer quite likely doesn’t know how some parts work.
We just interviewed a couple candidates for a senior role at my company. None of the interview team is pedantic about syntax, or asks about obscure data structures. In fact, we mostly have asked easy questions to focus more on requirements and discuss the solution in depth. Still, candidates with 20 years of experience have had trouble doing simple problems (think averaging some numbers in a list, etc). Design questions are asked too, it’s not all about coding, especially for senior positions.
I know everyone already tore this article up, but I had to add another data point now that I’m finally in an interviewing position. I think only some FANG interview in this leetcode-heavy way.
I thought the school analogy was particularly apt.
Unfortunately, it would seem there is little measure of a programmer’s competence or ability, other than through “grade 8” textbook problems or general IQ type tests. Perhaps we should stop the charade of calling ourselves “engineers”.
[Comment removed by author]