I wonder if this works as a heuristic. It seems like companies working with mature software would have less pretense, and so feel less need to gatekeep. Working with stuff like PHP or classic libraries and frameworks might signal they recognize they're just tools to get a job done, and it doesn't matter how you go about it as long as it's on time, on budget, meets the spec, and won't get them sued.
That's the classic library I had in mind. I could have been clearer. It's not perfect, but it's as good as any library would be after 15 years of changes to meet new needs.
back then (~2004) for Google phone screen you had to "write", ie. to voice it, correct code over the phone - good luck if you didn't know that beforehand like me and was at the place without whiteboard nor pen&paper nor took laptop with you (i was just walking that Bay trail around Sun (nowdays FB) MPK campus), and i got the impression that they really expected you do to it from the mind ie. using say pen&paper would be cheating (i should have tried stick on the sand though :).
Even more stupid. "We'll 'let' you use a computer to do our totally contrived, useless code exercises, but you can't just share your screen and use an IDE so we can see how you actually. No, just use 2020's WordPad."
I don't love giving coding interviews, but we use CoderPad nowadays, which is pretty reasonable for this task, IMHO. Acceptable editor, you can run your code, etc. And as the interviewer, I can replay the session afterward if I want to retrace the path the candidate took.
I think a fun/useful question would be along the lines of tell me one of the biggest mistakes you’ve made in X language that shows up quite a bit on the resume.
I dislike these questions. Not everyone compartmentalizes their experiences using technology into "best," "worst," "biggest," etc. I have 26 years of software development experience. At this point, it's all feel, intuition, and instinct.
A big Fintech company asked me to go to wikipedia and look up k-means squared algorithm. Implement it with tests, from scratch. No sample data etc. In about 45 minutes. I was applying for an Android position. Still sticks with me to this day how cold the interviewer was. It's a great learning experience and has made me a better interviewer
I think this shows how difficult interpretations can be. The interviewer was probably just kidding around, but given the stakes and the unfamiliar environment, it was probaboy a rough comment.
It's a good lesson in behavior. Even professional adults screw up and have foot-in-mouth moments.
>I think this shows how difficult interpretations can be
It's not interpretation, really, I think. It speaks to the asymmetry of the situation and how, if you are the interviewer, you need to be thoughtful about what you say at all.
I learned this early on, much to my chagrin. An interviewee was obviously stuck and getting themselves in a muddle so I stopped them and redirected to a different question; I thought it was in a lighthearted manner and communicated that I wanted them to relax and regroup - found out later they felt I was making fun of them and had a terrible interview experience. Ever since then I've been much more careful and explicit.
What I thought was being considerate was read as being condescending, I suspect, even though my intent was pure the situation is fraught with potential for miscommunication.
It's difficult to know how best to react to interviewees being stuck. If you leave them stuck, they may take it badly; if you redirect them, they may take it as a sign that they "failed" this part of the interview.
I try to say something along the lines of "OK, I think it's time to move on to something else; in an interview situation, you sometimes go down a blind alley, but that does not really reflect on the real world, and I think I've seen enough to move on to the next subject."
The latter is similar to the approach I take also - but tellingly also what I thought I was saying in the situation related about. I'm more careful with language now.
I have to agree, I would guess that the interviewer could tell the OP was nervous and was trying to lighten the mood a bit. Though, asking someone to write a language they don't use everyday is a pretty horrific thing to do in an interview. I've always been able to interview in my preferred language, even if the company didn't have one line of it in production.
Somewhat tangential (for the possible future): out of blue my paypal account was suspended recently, permanently, and they refuse to give any reason. Now I'm thinking to apply for some positions there only to raise this topic with the hiring manager :)
Sure. I guess I won't name names, but it happened something like ten years ago. It was for a pretty large online stock trading platform. It was a previous era of my career when I was a full stack web dev. The interview question involved some kind of CSS gotcha. I couldn't figure it out and asked if I could Google it. The interviewers agreed. I pulled up some search results and started looking past the first few because they looked kinda click baity. One of the interviewers said something like, "Whoa, back up and look at the first link. That guy knows what he's talking about; he's the man." So I clicked on it and took a look. But by that time I was pretty nervous and my brain just wasn't working. I looked over the article and couldn't make sense of it quickly enough to figure out the answer. I think I told the interviewers something to that effect. That's when one of them laughed out loud and said, "Oh my god! It's right there in front of you!" I didn't get the job of course.
That situation has replayed a lot of times in my head since then. It was one of those things where I wish I could have done something glorious and snarky to put the guy in his place. Probably best that I didn't do that though. I think reacting defensively like that just incurs an emotional cost.
Mergesort and quicksort both work on the principle of sorting both halves of a list separately and then combining them. But mergesort is much simpler than quicksort.
Mergesort makes dividing the list in half easy: you just cleave the list at the halfway point. Then it's your job to assemble two small sorted lists into one big sorted list, which is also easy.
Quicksort makes assembling the large list easy: everything in the left list is smaller than everything in the right list, so all you need to do is concatenate the two sublists. But we've made something that was already easy even easier at the cost of making dividing the list much more difficult. Now instead of cutting the list in half, we have to rearrange it into a small part on the left and a large part on the right.
(Actually, you can just assemble new lists by filtering the input for small numbers (and passing them to the left) and then refiltering for large numbers (and passing them to the right). You're already doing O(n) work on the input, so doing O(n) work two more times won't change the asymptotic complexity. But anyone who's looking for an elegant solution will hate you.)
I ask tech questions in interviews as a litmus test (for any given concept) and it always relates directly to the work being done so they can get a feel of the kind of code they would be writing and maintaining.
As an example -- in my line of work, one task we perform is processing files, some small, some medium, some very large; and I wanted to make sure a candidate understood the concept of Maps in order to perform O(n) to create a map and O(1) to look up items (generally speaking, I'm sure it's not exactly that in practice), which aide in efficient processing (the age old processor vs memory tradeoff). This particular candidate got everything I asked immediately, and the interview was very short. The person was made an offer soon after and has gone on to learn what we've done, adapt, and also teach us some things that have made the software better.
And the moment candidates grok the concepts I'm after, I confirm that's what I was after, and move on, trying not to waste too much time on any given item. And if they don't get the concepts after a short while, I try to lead them there and see how they react (is it a lightbulb moment or a confusion moment, etc). These are all signs for me to determine if someone is right for the position.
Interviewing is a 2-way street of respect. The interviewer often has all the perceived power, but in my experience, a good interviewer eschews that perception right from the get-go and lets the interviewee know that this is more of a discussion than any kind of trickery or exam, even when it contains coding questions.
This is why I will never interview for Google or any other company that has multi-stage interviews and also employs time-wasteful, and sometimes esoteric, methods such as "How many jelly beans fit in a school bus?"
I wholeheartedly agree with your idea of having a 2-way street of respect, and treating interviews less like interrogations and more like discussions. It certainly feels more natural that way, and puts less pressure on the interviewee.
Regarding Google specifically, I just interviewed there about 2 weeks ago, and although I didn't get the job, I will say I felt very respected, and with the exception of maybe one interview, thought everything felt like a discussion. There were no trick questions, everything was fairly straightforward. Basically a leetcode medium/hard for the 4 technicals and just discussing my experiences in various situations for the "Googleyness" interview.
I have heard similar stories about Google using these trick questions, but from what I understand these were mistakes made in the earlier days of the company and have been effectively phased out, although that is purely speculative.
>This is why I will never interview for Google or any other company that has multi-stage interviews and also employs time-wasteful, and sometimes esoteric, methods such as "How many jelly beans fit in a school bus?"
I said this once upon a time. then I realized I like money and I'm willing to dance a jig if thats what will get me beaucoup RSUs to fund my personal startup venture
I get paid well where I'm at right now. I live a pretty good life. I don't begrudge anyone who works for Google or any other tech giant, I simply set my own standards and I live by them. I find it is a waste of time for me to interview at places that try those kinds of gimmickry. And from what others are saying, it looks like Google doesn't do that anymore nor does it sound like it was widespread, so it may have been simply anecdotal accounts I remember reading.
> I will never interview for Google or any other company that
> asks questions like "How many jelly beans fit in a school bus?"
I conducted more than 100 interviews at Google and saw the questions the other interviewers on each panel asked. Google does not ask questions like that.
Good to hear. They have done that in the past, though, I've read a few first-hand accounts of it (and sadly I cannot find them now so take it with a grain of salt, of course). Perhaps it was just early-days.
Yes, that's the circa 2005 version of what we have today.
If you at least tried you could still get an offer however, unlike today, where the answer must be approaching perfection and timely. Because they are a lot more interested in exposing impostors both real and imagined than hiring.
> This is why I will never interview for Google or any other company that has multi-stage interviews and also employs time-wasteful, and sometimes esoteric, methods such as "How many jelly beans fit in a school bus?"
Good news: they don't do that any more.
Bad news: you still need to practice the fermi estimation techniques that question employs, but also need to know like, the details of every paper they've published on distributed systems, and bring your own heuristics about computers and email in order to determine how big a GFS cluster you need to launch gmail.
I've had bad interview experiences. I think most of us who've been working for awhile have. I have advice for those who are newish: Walk away if you're uncomfortable. If you're not feeling right in the interview I bet you won't feel right on the job, either. If you're being mistreated just walk away.
Bonus points for getting up while the interviewer is in mid-sentence and telling them it's not a fit.
I was with you until the last sentence. The best way to respond to rudeness is clearly and politely, unless they're screaming, berating, or threatening you. If you make a habit of responding to rudeness by acting politely, you will impress everyone other than the perpetrator(s).
What's interesting to me is that CS adjacent fields are going through the same teething pains as CS for how to conduct interviews. My background is in engineering and I'm familiar with the terrible experiences the article's author has had. At least now there is some awareness and acceptance that there are bad ways to conduct interviews and that stopping that just might be a good idea. Since then I've moved into the data science/ML world and its like starting at square zero. The field is broader and deeper than CS. Interviews are like being a ping pong ball being smashed on one side by someone with a PhD in physics and aggressively returned in kind by an economist.
Hands down my worst interview experience was one where I was grilled on exact versions of operating systems, compilers, and software I used. Then over the phone I was asked to implement some simple functions in C++ but the interviewer kept getting annoyed I'd use shorthand like "array of doubles" and wanted me to say it like I was dictating into a compiler! The interview was cut short after I made a few off by one mixups in the code, probably for the best...
I'm really not sure what the purpose of the call was! It was my first scheduled contact with the company after sending in my resume, but it was directly with the hiring manager and he got right into writing code over the phone. I've checked their Glassdoor page again this year and my experience seems common.
I did a coding interview over the phone with Google. This was around 2006 maybe 2007. I did it in my car with a notebook in my lap. I don't remember the question but it was "leetcodish"
I actually did one of these as well. We couldn't get the video call to work, so the interviewer ended up having me write the code down, and then read it to him over the phone.
At the time if felt pretty dumb (and still kinda does), but he was fairly reasonable about it, and most of the back and forth was me describing the algorithm to him.
I generally don't mind whiteboard programming interviews but even so asking someone to implement merge sort is a bad question.
My sanity check for any question I ask is- Is the question I'm asking something that someone in the past published a paper about? If so then that's probably not a good fit for a 45 minute whiteboarding interview. This question falls in that category. Generally those algorithms are complex enough that it is unrealistic to expect someone to get them right from first principles so at that point you are just selecting for people who just happened to have dealt with them, memorized them or implemented them recently.
I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews (and there are companies that ask that question). Always stuck me as weird as multiple papers have been written about that problem, are you really expecting someone to implement a solution to a problem that people spend weeks (months?) thinking about before publishing? Could even Djikstra have come up with the Shunting Yard Algorithm in a 45 minute interview (with implementation on whiteboard) if that was his first exposure to the problem of expression parsing?
Yep. I think it goes further than whether there's a published paper about. It boils down to "does the question have exactly one correct answer?"
One important thing you learn in interviewer workshops is to avoid asking questions with "aha" components, i.e. things that can only be solved if a very specific insight is known. This type of question is problematic because it falls victim to the fallacious assumption that a candidate that excels in one specific problem must necessarily excel at others that are in actuality, at best, only marginally related.
Instead, it is better to ask questions for which the solution can be arrived at with small increments in effort (e.g. maybe there's an obvious brute force solution and you start from there to discuss more optimal solutions, or maybe the candidate got stuck on some specific peculiarity and you can give a hint to unblock them and move on to another part of the problem to get more signal)
The "aha moment" is also known as the eureka effect. Psychologists call this "insight problem solving", which is terrible for interviewing since like you said since it isn't a problem that you can build up towards solving. As a teacher, I try to make sure my assignments/quizzes don't fall victim of this.
For anyone interested, there are a lot of interesting studies on the topic if you search on Google Scholar. You've probably already seen matchstick arithmetic problems before (i.e., move a single matchstick to make the equation valid).
It never ceases to amaze me that a profession full of people that studied something called “computer science” is also filled with people that refuse to read the literature when it comes to hiring and instead lean on gut feelings, anecdotes, and cargo cult-ing.
I've researched a lot about this since I've had to do hiring, but I haven't been lucky enough to find anything collectively definitive or comprehensive enough to describe as "the literature." Most of it leans towards "what not to do," which is helpful but leaves some gaps. What do you recommend?
I was just watching a Jon Gjengset "Crust of Rust" stream on sorting, and when his quicksort implementation kept going sideways, I was like "haha how nostalgic".
> My sanity check for any question I ask is- Is the question I'm asking something that someone in the past published a paper about? If so then that's probably not a good fit for a 45 minute whiteboarding interview.
Also, is it a widely known algorithm? Because then I'm not measuring for programming ability; I'm measuring for rote memorization (there are people that will rote memorize all the sorting algos to be able to spit them out during interviews!).
Asking for a simply program like wc, in my opinion, gives a much better idea if someone can code (hint: there's not a single way of writing it and to define a word).
> I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews
That's a cool problem to use. I wouldn't expect a perfect parser or even a working one but I would be curious to see how they approach the problem and what they end up writing.
My impression of the facebook interview experience was that it is specifically selecting people that were calm under pressure and well rehearsed. They are testing for people that put in the effort to crank out a bunch of algorithms practice because they want to ace an interview. FB and Amazon were also explicit that they were looking for people with a particular "get things done and promote myself" attitude. Whether or not those people make good employees, I don't know.
When I interviewed at FB, every round was something that I had drilled on leetcode or similar sites. Yes, the wording was changed and the problems were altered a bit, but they were the same algorithms. And there were also two "lightning" rounds of 15 minutes each to solve two simpler algorithms problems (maybe easy/medium difficulty on leetcode). This experience gave me the impression that facebook's goals in hiring were to select people who really wanted the job and could pass quizzes well.
This all started back in the 90´s with companies like Microsoft, but at that time the questions were somewhat reasonable, and just reading something like Programming Pearls was most of what you needed to know.
But I suspect what has happened, is that as those hired by this method got promoted, they started asking harder questions... and that has over time escalated into the current situation which has become somewhat ridiculous in terms of pre-study, etc.
> My impression of the facebook interview experience was that it is specifically selecting people that were calm under pressure and well rehearsed.
Yes, the more stressed / slow thinker you are, and the more work you need to put to prepare these interviews. It's not uncommon for people to practice for years.
I don't think these companies exactly want this type of profile, but when you interview 10000s of people, you need some consistent criteria so that all candidates are treated equally. With that constraint, I don't think you can find a better interviewing system.
I got asked to parse infix notation and figured it out in the 45 minutes despite having no prior experience with parsing anything more complicated than CSV. I am not bragging or anything, I just know these discussions are biased towards kvetching so someone has to weigh in for it being possible to accomplish. My field is not computer science and if anything I'm the perfect example of who the infix notation question should be biased against.
To be fair the interviewer described my performance as "muscling through it" (exact phrasing changed to protect the innocent) so take it as you will. :)
I am aware that there is no way to write this comment without sounding like a boast, but that's just more reason to write it because there are probably a large number of people with the same story who can't balance out the discussion by telling it.
One bit of dirty laundry to keep in mind with FAANG and friends is that the interview process is somewhat self-selecting. Often times, the very people that crammed leetcode in the hopes of landing FAANG roles are the ones interviewing candidates three months later. So there this sort of twisted feedback cycle where the interviewers think that leetcode solving ability is a sort of badge of honor or whatever.
Obviously not all interviewers are like that, and at more senior levels, interviewers do place more emphasis on other criteria, but for entry/L4/L5-ish roles, it's a pretty rampant thing.
If you can crank out some moderately complicated algorithms, even having rehearsed them, and get all the little details right, like all the cases that occur, that does show you kind of know what you're doing.
Someone without the proper CS/programming background who is just trying to rote memorize will screw up the details, and not be able to explain anything if asked about it: like what is the purpose of that line of code?
Only problem is, even if this interview question is good at testing that which it is testing, it might not be selecting people along the right dimensions in terms of being suited for the job. It's not probing all the attributes of a software engineer.
Five candidates, A, B, C, D and E have done equally well on the exercise, excellent in fact, and are hired.
Yet, in actual work, things go funny.
A doesn't seem to believe in testing. Deliveries are sloppy and break things all the time. A is proud of her skills and treats criticism of their code as an insult.
B has never heard the words "version" and "control" in one sentence. B works on an out-of-date version of the code to make a change, and then follows the Wiki instructions for getting a fresh checkout (which pulls the latest baseline) and then just copies their previously changed files into the new checkout. Their code submission therefore reverts numerous changes from other people (incompletely: just in those files), while asserting their own changes. On top of that, B makes gratuitous whitespace changes, doesn't follow any consistent coding standard (never mind the prescribed one), and randomly fixes things he sees wrong that do not relate to the topic of the change.
C cannot handle changes in requirements. Even after code base has undergone many changes, C keeps thinking in the same concepts from when the code was two months old and C had been mostly working alone on that code, knowing everything about it. C's ideas about making changes no longer fit the new code. E.g. C cannot remember that some logic is now distributed, running in several places at once, because that's not how it once was, and consistently forgets that aspect.
D cannot say no to any new task. Whenever someone talks to D, D gets distracted and excited and starts looking into what that person was talking about, and doing work on it. Whenever D gets stuck on something, D easily finds something else, and forgets about being stuck, or to report having been stuck. D leaves numerous tickets in an in-progress state, and that list just grows over time.
E is simply lost in any large project. E has done nothing but programming challenges under 1000 lines of code. E has no skills with regard to navigating a large code tree and understanding the structure of something made of tends of thousands of lines (or orders of magnitudes more). E gets paralyzed when faced with making a change to a large system that will involve making some small changes to eight or nine files. But have you seen E's Tetris in five lines of code?
> B works on an out-of-date version of the code to make a change, and then follows the Wiki instructions for getting a fresh checkout (which pulls the latest baseline) and then just copies their previously changed files into the new checkout.
Do people like that ever make it into Google, Facebook etc. or is it purely a hypothetical?
> Always stuck me as weird as multiple papers have been written about that problem, are you really expecting someone to implement a solution to a problem that people spend weeks (months?) thinking about before publishing
except that these things aren't research material anymore and are now taught at undergraduate level.
That's the point. No one is solving the problem, they're regurgitating knowledge.
If you care is someone has completed a Computer Science degree, ask to see their resume. If you care if they actually learned the material, ask to see their GPA.
I don't think whiteboard programming is really a good metric for measuring someone's skills for a normal software engineering job.
However, assuming that extensive knowledge of certain algorithms (like merge sort), data structures, or computational methods are necessary for a particular job, I think a better question to ask isn't "how do you implement merge sort" but instead to present the merge sort algorithm and then ask the interviewee how it works based on the code given. Obviously still not the best way to assess someone's skills, but I think it's better than just memorizing a bunch of algorithms without being able to explain how they work.
Wirth's "Pascal User Manual and Report" has a listing of a program on pg 75 that does just that. Except it emits the expressions in postfix form rather than evaluating them. It's 31 lines of code, including declarations and `end` statements.
K+R "The C Programming Language" has a desk calculator that evaluates postfix form on pages 74-75 which is about 60 lines of code including lines with just a {, and handles +-*/= including user interface and error checking.
Say that it's a binary merge sort over a singly linked list.
A binary merge sort, if written recursively, is straightforward divide-and-conquer. The input list is divided into two halves, which are separately sorted via recursion, and then the sorted halves are merged to produce the sorted output.
The algorithm pops out of the definition. If you know the above definition (or the interviewer has provided it, which they should!) the rest is just an exercise which demonstrates that you can:
- completely analyze a problem's cases, including figuring out the existence of cases that are not spelled out in the description (like how to terminate the recursion)
- manipulate pointers
- decompose a problem into small, simple functions that you can separately reason about: (merging two lists, chopping a list in half, and such).
It's not such a bad interview question. I would actually tell all the candidates at least a day ahead of time that they will be implementing merge sort in C using a singly linked list during the interview, so they can study it all they want and rehearse coding it.
It's complicated enough that it can't just be regurgitated from memory by someone who doesn't know what the are doing. (Say, someone who had someone else write the code, and then tried to rote memorize it.) The memory has to be accompanied by understanding if the candidate is to reconstruct it with few or no flaws.
I thought about this a lot at my former job. When I first applied, we were 30 people strong, but 4 years later we were 150 people and had hired veterans from the NSA/FBI/NASA/FB/Google etc. I often thought, I definitely would not be hired if I re-applied right now.
I work in a Wall Street trading company. Up til about 6 years ago, I was actively involved in recruiting tech staff and defining our tech recruitment process.
I’ve since changed roles, but was recently asked to sit in on an interview.
Wow, how things have changed. I seriously doubt I would be successful going through the current recruitment process.
Any why? Focus on whiteboard programming with questions that far exceed the requirements for the day-to-day job.
Somewhere along the line, egos took over and we have a bunch of devs on an ego trip to prove how smart they are.
Amazon explicitly engineers this into the interview process via “bar raising”. You have to be better than the bottom half of people who hold the position to get hired. If Google is implicitly doing the same thing, I’d guess the same 40-60% that was mentioned in the thread.
I think most (entry to 5 years of experience at least) people who work at FAANG companies spend dedicated time studying for interviews. They also know exactly what their company is looking for - leadership principles for Amazon, for example. If you gave current FAANG engineers a month to prepare, I think 80% of them would reclaim their jobs. If you gave them no time to prepare, I think less 30% of them would reclaim their jobs.
The ability to solve contrived coding problems is a muscle that needs to be exercised, even when one does actual programming for their job every day. I'm guessing most people don't practice interviews when they aren't expecting to interview, so only a small percentage would retain enough to pass a loop.
At one of the FAANGs the number one thing they drummed in during training for the interviewer is that "interviews are not an opportunity to make you, the interviewer, appear smart!".
It's obvious but geek culture sometimes need things like this explicitly stated.
I don't see the problem. Writing code by hand has its roots in the early days of computing with punch cards and C is ubiquitous. I suppose the comment was somewhat snide but if your skin is that thin are you able to work on a team without becoming the problem?
I don't understand why "roots in the early days of computing" is inherently good. We've learned a lot since those days. As a fun example, imagine defending storing plaintext passwords "because it has it's roots in the early days of computing".
Other than "because we've always done it that way", what do you learn about a candidate in a 30-60 minute whiteboard interview where you ask them to implement something they'll never have to implement on the job, while restricting them from all of the resources they have been trained to rely on (internet access, man pages, etc.)?
Sorting algorithms are taught as part of every CS degree and C is still used today. The only real change is there are a lot more low-quality programmers than there used to be. If you have to cheat to pass a test I think that would tell the interviewers a lot. Any code monkey can search StackOverflow.
>Sorting algorithms are taught as part of every CS degree and C is still used today.
I still don't understand what you're learning from the 30-60 minute interview. If you want to know if someone has a CS degree, look at their resume.
>The only real change is there are a lot more low-quality programmers than there used to be.
You'll need some data to back that one up.
>If you have to cheat to pass a test I think that would tell the interviewers a lot.
I would consider someone smart if they use every resource available to them to solve the problem presented to them. You consider it cheating. What a weird way of thinking -- just rote memorization for everything in life? Everything must be from first principles? Sounds tedious and inefficient to me.
Smart people realize that other smart people exist, and might even have valuable ideas or solutions applicable to their own problems.
People lie on resumes. I don't need data to give my educated opinion. Rote memorization/learning is extremely valuable, disputing that fact is ridiculous. Stupid people also exist and unfortunately most companies need to weed them out, at least from certain positions.
While your brain is busy upkeeping your memorized minutia, I'll be on bigocheatsheet.com looking up big-O notation for every single algorithm in seconds, and keeping more of my brain on the actual problems at hand.
Degrees are really straightforward to verify (at least from any accredited domestic school), a standard new hire background check would catch this. Obviously tech companies just don't think the degree is a super valuable signal, which I get. But I think they've turned around and placed too much emphasis on these whiteboard interviews.
Memorization can certainly be important. Memorizing random algorithms that you will never actually use during the job is less so. Conversely, other skills are important too. Poorly executed whiteboard interviews will select crammers who lack many other skills.
I have a CS degree and I develop for the web. Want to know how often I write sorting algorithms for my job? Never, nada, none in 3 years out of school. Could I if asked? Absolutely. First I would question why we aren't using a pre-written and pre-tested library, but if convinced I would pull up google and take some time to write a performant sorting algorithm with the knowledge we all have free access to.
Meanwhile a dev can study leetcode for months and land a job where it turns out they have little to no experience in the actual work they will be doing day-to-day. Who would you rather hire?
Nowadays, with 20+ years of experience as a software developer behind me, having worked for Apple, First American, Bloomberg, AT&T, Booking, Amazon, many startups, etc. my job interviews have never been easier.
Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
When I applied for a job at Toptal this made the algorithm-test disappear like snow before an up-close nuclear blast.
I've interviewed hundreds of candidates over the years and I would never ask a question I can't also answer from the top of my head, in detail, and then some. Turns out, most technical interviewers who ask you "write a bubble sort" couldn't do it themselves.
And if they could, it'd be full of bugs. I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution. I don't need developers who can reinvent complicated wheels from scratch; I want developers who are efficient.
Likewise, I don't want to work for a company where developers pride themselves on over-engineering their things.
Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
> Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.
You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
Be kind to people. Show your maturity by understanding what is the other person's role in the process.
If you have so much knowledge and experience as you claim, you should have no problem going through the process -- your willingness to go out of your way to do this kind of shit does not show you are going to be nice person to work with.
> I would never ask a question I can't also answer from the top of my head
That is prerequisite, but not yet full solution.
You are asking candidates for things you know which means you are comparing their experience to yours. What if they have different experience and met different problems?
Ideally, you want to answer a question "Can they be productive at their new position?" which is a different question from "Do they know everything I do?"
I always remind myself that it is likely every single candidate I interviewed knows something I do not.
> Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
Speaking up is aimed at fixing the problem. People who "speak up" do it because they believe it is necessary to create publicity around the problem to get it fixed.
There is no way to “fix the problem” as the interviewee, unless you have invented a mind-control device. You can merely say no, and only if you are a desirable candidate can it have an effect other than “pushing on a string.”
I can’t think of a better approach than the golden rule here.
> And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.
I'm not being an asshole, the interview goes both ways. I want to know who I'm working with and whether they practice what they test for.
> You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
Oh come on, stop being so subservient. It's just a company.
The company is trying to convince me to work for them. If they want to know about what I can do for them, I have a lengthy resume and 5+ references they can call.
> He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
It's not a difficult job, though. Their recruiter can call my references, she can check if I worked at the companies I listed, their technical people can absolutely ask me relevant questions. But if they go into the realm of leetcode nonsense, then I am absolutely going to play that game with them.
And I don't really care if I get the job or not, I can afford to not work for about 20 months if I need to, and if I reach out to any of my on-call recruiters they'll have 5 job OFFERS for me in the next 14 days.
> Be kind to people. Show your maturity by understanding what is the other person's role in the process.
Well, I'm tactful in real life, trust me. My anonymous discourse on a forum like this isn't my conduct in real life, obviously.
> I always remind myself that it is likely every single candidate I interviewed knows something I do not.
That's a real good mindset, and I think it's guaranteed. Many junior developers still teach me a lot every day in my work.
---
> Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
I did.
When I got into Apple I was one of the first to introduce them to React Native for one of their in-store specialist apps that were also customer facing. High requirements for quality. I setup a small team (1 back-end dev, 1 front-end, 1 full-stack, 1 designer, 1 product manager) and we finished the software to the requirements in ~4 months where we were given 12 months.
And I think I'm extremely pragmatic, and that it's in my nature, historically speaking. I'm detail-oriented, fast, creative, and while I have my preferences, I easily change my mind when faced with new or better information.
And if I can't change or improve what I do a company (it didn't work at First American, for example), I'll just leave. I'll definitely try, but it's easy to see unbreakable walls of politics and invested third-parties who just want to write and invoice hours, not results.
A local bank I worked for, too. They promised me the world and gave me "unlimited power" to improve everything I wanted. Turns out, the unlimited power only went up to my own level, and I was still 5 levels below the hyper-social CTO who didn't know anything about the technology we were working with.
I don't like complaining, I like solutions. I bring solutions to the table. And it takes more than just me to get them implemented, especially in larger companies...
Woah, we got a badass over here. Seriously they have 1,000 other qualified candidates lined up right behind you. I'm sure they appreciate your time and then end the interview.
I also think this comes across as someone being pretentious and arrogant, and could be a no-hire, but there’s a nugget of truth in this: interviews are two-way streets, and getting a feel for your coworkers and your environment can be as important as landing the job.
Also
> Seriously they have 1,000 other qualified candidates lined up right behind you.
I’d kill to have ten qualified candidates to interview. It’s a seller’s market.
As an interviewer I've given you a heads up before the meeting what is being tested for. Some time to practice, do pre-work, research the company, etc.
Dumping at the start of that meeting out of the blue this criteria, is not a two-way street equal reciprocation of that respect. If you'd kill for ten candidates, you can have him. I've had ~230 for 2 position this week and I'm testing for EQ also. Maybe changing requirements on people at the last minute fits in your work culture.
~250 Candidates? Sure mate, I'd be surprised if at the end of your application process 5 of them remain and are still available.
Companies are having a very hard time finding software engineers. For the first time in the history of the market, employee retention budgets are skyrocketing because recruiting is so expensive and hard. It's not rare to hear software engineers getting a sudden 30% raise out of the blue.
Because they know we're in high demand, and they know that if we switch jobs we'll get a 30% raise, at a minimum.
If you truly have a position that is averaging 100 applicants, you are hiring on the margins.
You either have a position that is so elite and aspirational that it is paid accordingly and people are flocking to it - and good luck filtering out the majority of resumes that Dunning-Krugered their way into your inbox before the elite candidate moves on. Or, you have a position with requirements so low that you can easily get candidates by the bucketful and take your time to sift through to find a diamond.
Sounds like you should open a recruiting and placement agency if you have 1,000 of what everyone else is searching for high and low with limited success.
I'm not a badass, I am just laying out a baseline: I know what I'm talking about. That's all. And no, many companies don't have 1k applicants that are qualified. They have 5000 applicants in the SF area, 4900 of them are unqualified, 80 who are qualified can't write English, of the remaining 20 candidates only 8 are still on the market once you reach them, 4 pass your filters, 2 accept a job offer, and only 1 of them shows up.
That's far more realistic. In today's world, we're not looking for jobs, jobs are looking for us. Desperately so.
So you mentioned you worked at Apple... twice, plus a bunch of other high profile companies & with 20 years of experience your interviewee techniques aren't really that applicable to almost everyone here. If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole". You state a lot of desires for your employer and coworkers; I want to work with developers who are skilled, humble, joyful and nice.
And Booking, now also twice. What can I say, Apple was fun. Stayed for 12 months and then I left.
> If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole".
Well, I wouldn't act like I write on an anonymous online forum like this, obviously.
So far I would say that most of my ex-colleagues would describe me as someone who is quiet, listens well, makes lots of notes on a paper, has a fancy pen with ink, and is surprisingly non-hipster despite all that.
I'm very involved with helping other developers in my social network getting the most out of job interviews and salary negotiations. I know the right ways of getting the most out of performance reviews and how to nail an interview that would otherwise make one uncomfortable.
> Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
This is a great way to end the entire job interview process and make sure you're never called back again.
Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.
Exactly. I can answer every question on my list, and you'd think any interviewer could because we've all used our interview sheets again and again and seen every caliber of answer. If you waste my time by telling me up front you're going to ask your own questions back at me, I will end the interview and thank you for your time. Not because I can't answer your questions, but because that's not what I set aside this 90 minute block of time for and you know that.
I'm cringing just thinking what it would be like working with someone who had the gall to pull that kind of nonsense.
Right, it's not the cringe question, it's that you don't respect mah authority in asking me back a cringe question! I think the insane people are running the asylum now.
>If you waste my time by telling me up front you're going to ask your own questions back at me
I don't see why a 20 YOE candidate with predictable capability has no right to also likewise determine how experienced, qualified or intelligent team members on the interviewing side are...
> Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.
I once flat out refused to solve a question and still got an offer.. It really depends on a lot of variables to make a blanket statement either way. One of the variables is your level of experience. After a point, the fact that the interview goes both ways can skew heavily in favor of the candidate and if you're tactful and polite you can totally get away with driving the interview away from stupid problems. If you can't, then maybe you don't belong there and maybe that's ok. It's a win-win. A job is not a blessing, it's just a job. Unless you're starving, there's no point in pretending you're drone.
It goes even further than the "difficult to work with" vibes. If someone has 20+ years of experience and hundreds of interviews under their belts, they ought to know about candidate caliber variability and the meaning of standardization practices, aka why interview panels are setup the way they are.
As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade, if only to see how the candidate deals w/ hiring (since for the sort of roles I evaluate for, that does come up as a job task), but I suspect that I'd see a holier-than-thou attitude that I've seen from bad interviewers and that that would be a negative flag (and, no, the "I'm not fired, I quit" thing won't work with me, because - not to brag - I'm pretty confident in my interviewee skills even without cramming leetcode)
> It goes even further than the "difficult to work with" vibes. If someone has 20+ years of experience and hundreds of interviews under their belts, they ought to know about candidate caliber variability and the meaning of standardization practices, aka why interview panels are setup the way they are.
Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.
A company shouldn't have one interview process, they should have several. Some do well with live coding, some do well with take-home assignments, others do well with pair-programming. All are valid ways to show skill. And each can also be something that makes the candidate incredibly uncertain and stressed.
> As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade
It is always a two-way interview. It's not a charade. You sound extremely entitled and elitist just by saying that. The candidate has 5 other offers waiting for them that aren't being a pain in the rear like you.
Don't "entertain the idea", you are applying to the candidate as much as the candidate is applying to the company you work for. Get over yourself.
> Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.
I'm surprised you're saying this in such a one-sided way, since you claim to interview candidates. I interview as a candidate too just like anyone else, so itemizing interview process problems is preaching to the choir. But IMHO it's disingenuous to ignore that candidates cheat, that college kids putting 10 hours on a take home assignment are very different than mother-of-three w/ 10 years experience, that bad interviewing on the part of my peers leads to me picking up someone else's slack later, and that generally speaking interview sessions are uncomfortable scenarios for everyone, no matter the format, much like code formatting styles never fully pleases everyone.
If you've been involved in defining interviewing standards, surely you must be aware that having several interview processes is even harder than standardizing on a single process: there are issues of interviewer qualification, calibration, throughput, interest, attrition, and other fun logistics things to think about. Saying every company should bend over backwards and have master interviewers fully calibrated in six different interviewing methodologies, at scale, at all times, is really not any more reasonable than a company expecting every candidate to bang out bubble sort in 30 minutes or take 10 hour take home assignments or whatever. And letting people do whatever is how you get to the Apple horror stories you see elsewhere in this comment section.
The thing about people having other options lined up goes both ways, really. Just as candidates have other options lined up, companies also have candidates lined up. In mine, HR literally needs to be mindful to not flood people w/ too many interviews each week.
> It is always a two-way interview
Oh I fully agree with the spirit here, but there is also a thing called tact. I don't go on pissing contests w/ my candidates as an interviewer and I don't go disrespecting an interviewer's time by saying "you know what, you don't know how to interview me, let me show you how I do it to you" (and yes, I believe this is tactless behavior from the perspective of myself being a candidate). If my awareness of industry standards is me being a hard-ass in your mind, I don't know what to tell you. Industry standards are what they are, ad-hoc and imperfect as they may be, and at least I try to understand the problem space and make the process better rather than just being passive aggressive about it like so many interviewing-related threads are.
When I say "I might entertain the idea", unlike sibling comments here I do actually mean exactly that: if you think you can show your skills better that way than my planned interview structure, by all means, go ahead and show me, but when I say "charade", I also mean that: I'm still evaluating you just as you are evaluating me, and if you think I'm evaluating whether "you're as smart as me(tm)", you've got the wrong impression. If your strategy as a candidate is to talk my ears off, I'm certainly open to it as an interviewer. I have had sessions like this from both sides. I'm familiar enough with this interviewing trick and how "talkers-who-dont-walk" abuse it. To be clear, I'm not saying you're one of those, but that as an interviewer, one needs to be aware of bad faith actors, and it's one of the reasons many interviewers cringe at the thought of "curveballs" like the one you suggested.
Absolute nonsense. In a field where very experienced people are in high demand, they'll bend over backward to offer you the job. I have references and a long history of employment. I'm not "negging" them (also, grow up), and refusing part of an interview when THEY are the one in need of talent, well, that just means they change their recruitment workflow, or lose out on talent.
I am not difficult to work with and I have a real good track record at applying for jobs, and getting job offers. Anecdotal, sure, but when an applicant gives me a good reason why they feel a certain part of the interview isn't helpful to either one of us, then I adapt. Especially if that person already got through the recruiter and tech-review filters, that means they are good.
These people are offended that you would question the competency of the employer and the interviewers. They say that you need to adopt a more servile attitude.
Yeah, it's a filter we actually got from management at one company. They were looking for specifically agreeable type of developers. It was a consultancy and they needed to put 5 more developers on one of their big clients, and the client was getting sick of the previous people we had there; they were constantly fighting back against their idiots of managers.
Boss wants employees to write many hours, not have a weekly phone call from the client asking to replace another team member...
Agreeable people also stick around longer, because they think loyalty pays, and agreeable people rarely negotiate a good salary.
OMG the red tape at Apple is unbelievable, but this is the first time I've seen anyone mention it. On my first day at Microsoft, I checked in code. At Apple it took nearly two weeks to get granted separate access to the apps's sourcecode, secret OS version, secret Xcode version, secret new OS headers (for some reason this was a separate line item), upcoming hardware versions (which I never saw anyway).
Once up and running as a senior engineer with tons of experience, I had no autonomy and wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.
Nah. I've worked at other FAANG companies and I'm afraid that none had anything close to the Apple level of red tape. I have barely scratched the surface of describing it.
> wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.
I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.)
Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason.
You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it.
But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.
At the end of the day, you applied for the job at a company whose success is at-least partially based on the structure and rules that were instituted by those who came before you. It could be that they were put in for a very good reason. I'm all for re-evaluating rules and making modifications, but erring on the side of caution is probably a good idea as well. Just my 2c, not necessarily disagreeing with your opinion.
There are lots of un-googleable problems out there. These questions are meant to identify the people that will probably fail to solve any non-trivial programming challenge (and maybe even some of the trivial ones).
I'm not really opinionated about whether or not you should do algorithmic stuff in the interview, but I don't agree with your reasoning here.
I see chatter about how most problems can be solved with google and your CS teacher lied to you (usually on reddit, less so on HN). My experiences have not matched this. I'd estimate that a good 40-80% of my problems don't have a solution on google. It's pretty rarely an algorithmic problem though.
If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
My experience with problems that can't be solved with a Google search is limited. I tend to use existing technologies and I stick with an architecture that has been around for long enough to have proper support online.
Still, sometimes I run into limitations with regard to TypeScript, for example. If that happens I'll go over the problem with more experienced developers. It'll be a pair-programming thing for several reasons: two pairs of eyes and two brains see and think more than 1, and you both learn something new, and you both have a little more brainpower available because you want to look good. At least I do my best a little more ;)
> If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
It's a silly example, I don't care what algorithm we're talking about. And no, many languages lack any sort of built-in sorting solutions. JavaScript (front-end and Node.js), for example, requires external libraries for performant solutions.
It's interesting how many people replied to this rushing to defend algorithmic hazing. Sure this is sort of a "then the whole class started clapping" type post, but there is some merit buried in here.
Somebody with 20 years experience I would like to explore that they are not a bullshit artist and not subject them to worthless leetcode questions that some desperate 24 year old will cram, pretend they never saw the question before and spam out on a whiteboard.
one of the things interviewers look for is great questions from the candidate. servile drones make fine code-monkeys. but if you want to put it all together, you'll need to show some attitude. pretentious? maybe, but efficiency is key. have you ever seen the old Letterman gag "don't call me Chief"? Letterman interviews people on the street calling them Chief, and the person to win the game must day "stop calling me chief".
IMO there is a difference between production code and whiteboard code. Nobody expects candidates to come up with ready-to-ship production code in 10 minutes. I don't care much for arguments about which interviewing style is better. If you find success using your method, I'm happy for you, and I only care about results. Asking someone to write code has never let me down. It has exposed a lot of charlatans who puff up their resume taking credit for their teams work, but when you ask them detailed questions they can't back-up their claimed technical prowess.
Funny thing about apple last time I interviewed there, everyone is an independent interview team. If you want to work at apple, you can, you just have to keep on interviewing and interviewing and interviewing and eventually you'll get a bite.
Did not get rejected, and I loved working at Apple despite the red tape. The only reason I no longer work there is because I moved to a different continent :)
That's a great way to turn the process into a zero sum game. I don't understand why people do it.
I once had a phone interview at a startup. The interviewer showed up 20 minutes late. And the first thing he said was, "I was in a meeting and before you ask, I can't tell you anything about it because then I have to kill you".
> I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution.
I think it's pretty well known that the question, or the actual question for which this bubble sort question is just an example, is usually more about how good you are at solving a particular problem.
For example, I'd rather not have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution, because I want my developers to know that bubble sort is an O(n^2) toy algorithm mostly used as an example for an intentionally bad sorting algorithm.
My company does white board interviews and I always make a point of telling the interviewee that I'm not looking for syntax and just want to see the overall algorithm and program flow. If he wants to make a library call and can't remember the args, I tell him to make it up - I don't care if he can remember a trivial fact that his IDE will tell him or that he'll find in a quick manual page lookup.
(while I meant "he" as a gender-neutral pronoun, sadly, nearly all of our senior tech candidates are male, but one bright spot is that we've got near gender parity with college interns which I hope means the job market is becoming more balanced)
I mean I don't know. A joke which may have been intended to give a hint, while putting applicant at ease, has clearly backfired ; but if that's the worst interview they have had, they're pretty lucky.
I also notice the paragraph near the end with couple of general lines on good interview and the "that's how I hold interviews".
Here's the thing. Nobody sets off to intentionally be a bad interviewer or coder or manager or whatever. It helps to have humility and significant open introspection to be good at something (not the only path but for most of us it's the best path). We ascribe wilful incompetence to others while we have excuses and lessons learned for ourselves. Maybe - likely - the other interviewer too thought they were giving opportunities and signals and letting people at ease?
This is a great example of intent vs. impact. Regardless of the intent, the impact was negative. Recognizing how their actions impact the candidate is a huge part of interviewing, and the interviewer should have seen the candidate get nervous and adjusted.
That said, given that candidates are generally nervous to some extent anyway, and semi-colons shouldn't matter in a whiteboard interview, that joke seemed like in poor taste to me. That underscores why we need better training and mentorship for interviewers.
I interviewed with a company a couple of months ago and it was the first time in my career that I'd had one of those technical interviews that folks here on HN seem to run into a lot. Was shown a handful of problems in a Google doc and told the code doesn't need to compile, it just needs to be conceptually sound. Got asked how to check if a word's a palindrome, how to check if delimiters are balanced, some basic data shaping with JSON, and a pretty basic SQL question with a left join.
I left the interview feeling totally confident I'd rocked it, since there were no "inverse binary tree" curveballs or anything like that, and figured that the company just wanted to make sure I knew what a stack was and what some properties of arrays are. Got rejected, asked for feedback and was told none would be given, so I rinsed the bad taste out of my mouth and went with another company instead.
Never expect feedback for why you were rejected. It is in the company's best interest not to explain to you why; any feedback could potentially expose them to legal liability.
It may be in the company's best interest to leave you in the dark, though frankly I question that wisdom and have never had it effectively defended by a knowledgeable party. And even if it is in their best interest? That doesn't mean you shouldn't expect professional courtesy out of an organization that disrupted your day and decided not to hire you after it.
Being decent to people is important and you are important enough that you can expect to be treated with decency.
I think it isn't about legality, its mostly that most people take rejection badly and get angry, and it isn't worth a recruiters time to deal with that nonsense.
That's an occupational hazard, one they accepted willingly when they started working as a recruiter. It's not my fault that they have to deal with bad apples.
In the meantime, a lot of us want to improve and be told what we did wrong. It's the least you can do if you used several days of the candidate's life, don't you think?
So... how is that "worst" interview experience? You probably haven't seen really bad interviews.
My favourite was switching conference rooms until we ran out of time and the interviewer thanked me and invited for a next session. There was also one when the guy was late 30 minutes to a 30 minute interview. And the one when they spent 1h with me and at the end told me the position has already been taken. I had one where interviewer smelled really, really bad -- I left when I learned he would be my boss.
I also had one where the guy said he is "best programmer in the world". I thought he is joking. Unfortunately, he wasn't. He became my boss. I left a month later when his code failed in prod (he parsed XML by specifying a line and character number to extract piece of data) but he blamed it first on the vendor (they apparently changed the format when they turned off pretty printing) and then on me (I haven't even touched the code). Apparently he never makes mistakes -- he always blames somebody else.
To be fair, I have also a lot of "bad candidate" stories. Like a guy with a lot of knowledge who says at the end of interview he doesn't want to get hired, he just came to exercise before going to another company.
From my PoV as interviewer I think the only real egregious error here asking the candidate to write in unfamiliar language. It doesn't matter what the language the project uses, the whiteboard needs to use language that is comfortable for the candidate. We can discuss knowledge of the language as a separate issue.
Now, asking the candidate to write a particular algorithm on a whiteboard from memory is just a waste of time. The purpose of programming exercise is to see if the person knows how to program, not if they have memorised particular algorithm.
Writing an algorithm like merge sort could still be productive if the interviewer has first explained the algorithm and then asked to implement it.
But I still feel merge sort is a bad choice -- I prefer simple task but one that I created myself so no candidate is familiar with it. I am interested how the candidate works on the task and how he can communicate with me to solve it. You would be surprised how many candidates dismiss hints they are being offered.
Netflix should green light a series on bad tech interviews. With Zoom and screen recording there’s an easy way to gain raw materials. And then once we name, shame, and normalize that this is nuts, we can move on.
Author states that the following threw him off: Interviewer: "you must be writing a lot of Swift" after a few minor syntax errors.
Maybe being put off by an ambiguous comment was why you didn't get the job? Did you consider maybe in his notes he might've said: "Smart guy but was put off by a single comment (a failed attempt at humour on my part). Probably not someone who would thrive in a lively atmosphere".
I had an interviewer ask a question and, not satisfied with the answer, get up and walk out. The other guy apologized and we had a good discussion after the other guy left.
There is absolutely 0 signal there as to whether someone would "thrive in a lively atmosphere" when you're jumping through hoops for an interview that will determine your financial well being and a good portion of your live for the next n years, and its a fun example of how "engineer social hacks" continuously fail in the real world.
Ah, so you're saying you're financially and emotionally secure enough not to be completely discombobulated by this incredible display of disrespect?
Good for you I guess, but maybe don't apply your own mental blueprint to the rest of the world. Recommending candidates have thicker skin isn't really great a way to improve hiring in general.
An incredible display of disrespect? It might be rude, but that’s about it. Depending on the tone of voice, it could have been intended as a way to relieve the author’s tension.
It does sound a bit annoying, but if that is the author’s worst interviewing experience, it’s not that bad.
On reading it my thought was the interviewer was making a small joke to put the author at ease: "Ah, you've forgotten some semis, you're probably writing a lot of swift at the moment, it's okay". But he was in the room and I wasn't, so I can only trust his interpretation.
i'm not sure you can jump to that conclusion either. there takes a certain level of maturity both emotional and financial at certain skill levels. a psychologist once pointed out to me that actors are able to take their nervousness and translate it into energy to use in the moment.
at a point in my career i faced a similar dilemma but handled it completely differently than i had earlier. someone made a snide comment "but why would you use bash for this?" and i was able to take it in stride and the result of that comment got me the job. but at the start of my career i may have reacted negatively, i may have clammed up and stammered my way through the rest of the interview etc (i didn't get those jobs). could you imagine being in front of a C-level exec or a $300M customer and being discombobulated?
no one wants to hire an insecure pre-sales engineer etc
EDIT: i'm assuming engineering levels beyond senior. my past experiences have been around principal/architect roles which require a 'tough skin'. i would not expect rude remarks to a SE1 or SE2 and if that was the role, i would leave flustered with a bad taste in my mouth as well
Dial the rhetoric down, we can't really read the "context" in which this line was delivered by the interviewer. Glib? Sure. Incredible display of disrespect? Give me a break.
If you’re making jokes like this in an interview, you shouldn’t be an interviewer. There is a clear power imbalance between interviewer and interviewee that needs to be understood clearly.
A somewhat comparable analogy is your manager joking about firing you and then evaluating you negatively when you don’t like the joke.
Would you spell out for us what is unambiguously Wrong about "you must be writing a lot of Swift"? A charitable interpretation could be this is a shallow joke about semicolons, that could be safe for lightening things up in an interview, especially when the audience is known to be familiar with Swift.
My impression from the OP is that they were out of sync with their interviewer, they didn't "click". This is something that happens with humans. The interviewer may have detected this dynamic, and made the joke to break the ice. Obviously it backfired, but with another candidate perhaps it could have saved the interview?
Separately, what do folks thinks about the importance of humor on teams, and the degree to which it's acceptable to screen for sense of humor as part of interviews?
Can you explain how making this joke would have saved the interview?
Here is how I see it. At best, you interrupt a candidate in the middle of a technical interview to make a joke. At worst, you ruin the interview experience for the candidate. To me, the cost/benefit is clear cut.
During a technical interview, you are evaluating the candidate’s technical knowledge. You are not there to become friends. There will be time for that after the candidate goes through the interview process.
First, would you respond to my question? :) In the case of the other commenter's suggested joke, you said "That sounds completely fine to me", so I genuinely want to know why one joke is completely fine and the other falls into the bucket
"If you’re making jokes like this in an interview, you shouldn’t be an interviewer".
Anyhow, to answer you, on both sides of interviews, I've experienced bad chemistry early in the session. Could be any number of factors, even just one of the two of us getting out on the wrong side of bed that morning. I sometimes will make a joke to lighten things up and get things back on track. Sometimes it helps, sometimes not, but I like to feel over time I am learning better how to interact with humans, and improving my odds, leading to more positive interview experiences and less wasted time. Things are never "strictly technical" with humans.
(all that said, to be clear, I have never brought up the candidate's sense of humor in providing feedback, although I don't see a problem doing so if humor is in the team's values manifesto or the job description, and we've agreed on a legitimate way to screen for it (seems hard!). Curious to learn others' thoughts on this subject!)
Sure! We only have the candidate's perspective, but it appears that the candidate:
1) felt that the tone of the interviewer was negative
2) was in the middle of writing their solution
3) did not actively ask for feedback on syntax
Point #1 is subjective, but an interviewer should err on the side of caution when making curt remarks like this. Taken together, points #2 and #3 are important too: as an interviewer, you should know when (or even whether or not) to provide feedback.
As for why I believe the comment above phrased it better:
1) the interviewer is clearly acknowledging that it can be challenging to use a different language in an interview
2) the interviewer is clearly stating that the syntax mistakes being made are minor and nothing to worry about
Personally, I would still avoid making this kind of comment unless prompted by the candidate - e.g., in reply to "I think I might be making a few mistakes with syntax here". I would also avoid providing any feedback.
I also agree that an interview is not purely technical: there are other _passive_ signals you can use to build a better picture. I don't see how you would be able to judge sense of humor reliably in an interview setting, though.
Thank you! Not much to argue with, rather just nodding my head. I hope one of us interviews the other some day, and that we have a chance to debrief after.
A positive reading is “you must be coding Swift a lot lately, I acknowledge switching languages is hard and won’t fault you for it”.
A negative reading is “you are screwing this up enough for me to comment, you need to justify why”
If it’s intended to be reassuring then phrasing it so it’s clearly not a criticism is better. If it’s intended as a criticism then phrasing it clearly is also better.
The way I can see it being a joke, as claimed, is insultingly. Like a dentist watching a trainee dentist doing a filling and saying “you must have been doing masonry work lately”. Haha but the subtext is “you’re really doing a bad job of this”.
I'm pretty sure during an interview once someone made a very similar joke when I'd written using Rust syntax instead of Javascript. I thought it was funny and thanked them for tactfully pointing out my syntax errors and confirmed I had been writing Rust a lot recently.
The only other choices for the interviewer are to bluntly say "you missed using semicolons" or to not say anything and be left to wonder if the person knows how to really write in C. The author of this post seems to think even considering any other choice than the last is rude since "whiteboard code doesn't compile so semicolons are syntactic sugar".
But if it does matter, baking in some understanding of the charitable reasons why (that the interviewee is proficient at multiple languages, especially in the popular ones at Apple like Swift) is actually the nicest thing the interviewer could have done.
The post author seems to me hostile to being corrected. Given that every code review I've been in requires being corrected dozens of times about errors large and small, I wouldn't want to have to deal with their uncharitable attitude towards feedback from coworkers/collaborators.
Tone and timing matters. If the interviewer had interrupted the candidate's train of thought, or spoken it during a particularly tense moment, it can really throw off their game.
Code reviews after already being hired and accepted into a company are not comparable to interviews during the application process, when the specter of rejection still looms.
> "Smart guy but was put off by a single comment (a failed attempt at humour on my part). Probably not someone who would thrive in a lively atmosphere"
This sounds like a cartoonish training example of the kind of subjective, possibly biased feedback that you absolutely shouldn’t be writing down as an interviewer.
A recent interview experience that stuck with me was being told at the end of it that I obviously know my stuff but I just need more interview experience...
Wow.. imagine if jobs were interviews, everyone would know how to mergesort in 15 languages from memory but not a single person would know what a div was.
FWIW I don’t think Apple has a standardized interview process. Unlike companies like google or FB, each individual team decides its own interview questions.
That means it’s possible to have a horrible interview experience with one team, and a great experience with another team.
Not saying this system is good or bad, just trying to describe the system.
I’ve had so many poor interview experiences and all of them at the big tech companies. I once went to google and only 2/5 interviewers bothered to show up.
Hell, in an interview I had this week I was given multiple incorrect answers to my clarification questions. Even when I said “I believe I answered it” the interviewer said “I don’t think so” until he finally looked up and was like “oh you got it”
I’m on zoom watching the interviewer text / look at other screens as I ask clarifying questions and they give dismissive answers “yea yea that sounds right, do that” while never looking up from their phone. Was a pretty “wtf” moment. I completed the interview, but I got the feeling the review will be subpar.
272 comments
[ 3.1 ms ] story [ 252 ms ] thread> Also, writing code on a whiteboard is fucking stupid — so there’s that.
Many places have switched to google docs now. Still just as stupid though.
>My worst tech interview experience: all of them.
Agreed. I thought it gets better. It doesn't. It gets way worse. Best jobs I interviewed for were around 2010 for jQuery and wordpress jobs.
back then (~2004) for Google phone screen you had to "write", ie. to voice it, correct code over the phone - good luck if you didn't know that beforehand like me and was at the place without whiteboard nor pen&paper nor took laptop with you (i was just walking that Bay trail around Sun (nowdays FB) MPK campus), and i got the impression that they really expected you do to it from the mind ie. using say pen&paper would be cheating (i should have tried stick on the sand though :).
This should be an entertaining thread.
It's a good lesson in behavior. Even professional adults screw up and have foot-in-mouth moments.
Treat people with respect seems to be uncommon common sense.
It's not interpretation, really, I think. It speaks to the asymmetry of the situation and how, if you are the interviewer, you need to be thoughtful about what you say at all.
I learned this early on, much to my chagrin. An interviewee was obviously stuck and getting themselves in a muddle so I stopped them and redirected to a different question; I thought it was in a lighthearted manner and communicated that I wanted them to relax and regroup - found out later they felt I was making fun of them and had a terrible interview experience. Ever since then I've been much more careful and explicit.
What I thought was being considerate was read as being condescending, I suspect, even though my intent was pure the situation is fraught with potential for miscommunication.
I try to say something along the lines of "OK, I think it's time to move on to something else; in an interview situation, you sometimes go down a blind alley, but that does not really reflect on the real world, and I think I've seen enough to move on to the next subject."
That situation has replayed a lot of times in my head since then. It was one of those things where I wish I could have done something glorious and snarky to put the guy in his place. Probably best that I didn't do that though. I think reacting defensively like that just incurs an emotional cost.
Congratulations.
“Wow, that would be really toxic behavior if we were coworkers. I think we should end this interview here.”
What really would tick the box is Timsort: https://en.wikipedia.org/wiki/Timsort
Mergesort makes dividing the list in half easy: you just cleave the list at the halfway point. Then it's your job to assemble two small sorted lists into one big sorted list, which is also easy.
Quicksort makes assembling the large list easy: everything in the left list is smaller than everything in the right list, so all you need to do is concatenate the two sublists. But we've made something that was already easy even easier at the cost of making dividing the list much more difficult. Now instead of cutting the list in half, we have to rearrange it into a small part on the left and a large part on the right.
(Actually, you can just assemble new lists by filtering the input for small numbers (and passing them to the left) and then refiltering for large numbers (and passing them to the right). You're already doing O(n) work on the input, so doing O(n) work two more times won't change the asymptotic complexity. But anyone who's looking for an elegant solution will hate you.)
As an example -- in my line of work, one task we perform is processing files, some small, some medium, some very large; and I wanted to make sure a candidate understood the concept of Maps in order to perform O(n) to create a map and O(1) to look up items (generally speaking, I'm sure it's not exactly that in practice), which aide in efficient processing (the age old processor vs memory tradeoff). This particular candidate got everything I asked immediately, and the interview was very short. The person was made an offer soon after and has gone on to learn what we've done, adapt, and also teach us some things that have made the software better.
And the moment candidates grok the concepts I'm after, I confirm that's what I was after, and move on, trying not to waste too much time on any given item. And if they don't get the concepts after a short while, I try to lead them there and see how they react (is it a lightbulb moment or a confusion moment, etc). These are all signs for me to determine if someone is right for the position.
Interviewing is a 2-way street of respect. The interviewer often has all the perceived power, but in my experience, a good interviewer eschews that perception right from the get-go and lets the interviewee know that this is more of a discussion than any kind of trickery or exam, even when it contains coding questions.
This is why I will never interview for Google or any other company that has multi-stage interviews and also employs time-wasteful, and sometimes esoteric, methods such as "How many jelly beans fit in a school bus?"
Regarding Google specifically, I just interviewed there about 2 weeks ago, and although I didn't get the job, I will say I felt very respected, and with the exception of maybe one interview, thought everything felt like a discussion. There were no trick questions, everything was fairly straightforward. Basically a leetcode medium/hard for the 4 technicals and just discussing my experiences in various situations for the "Googleyness" interview.
I have heard similar stories about Google using these trick questions, but from what I understand these were mistakes made in the earlier days of the company and have been effectively phased out, although that is purely speculative.
I said this once upon a time. then I realized I like money and I'm willing to dance a jig if thats what will get me beaucoup RSUs to fund my personal startup venture
If you at least tried you could still get an offer however, unlike today, where the answer must be approaching perfection and timely. Because they are a lot more interested in exposing impostors both real and imagined than hiring.
Good news: they don't do that any more.
Bad news: you still need to practice the fermi estimation techniques that question employs, but also need to know like, the details of every paper they've published on distributed systems, and bring your own heuristics about computers and email in order to determine how big a GFS cluster you need to launch gmail.
Is that better? I'm not so sure.
Bonus points for getting up while the interviewer is in mid-sentence and telling them it's not a fit.
At the time if felt pretty dumb (and still kinda does), but he was fairly reasonable about it, and most of the back and forth was me describing the algorithm to him.
My sanity check for any question I ask is- Is the question I'm asking something that someone in the past published a paper about? If so then that's probably not a good fit for a 45 minute whiteboarding interview. This question falls in that category. Generally those algorithms are complex enough that it is unrealistic to expect someone to get them right from first principles so at that point you are just selecting for people who just happened to have dealt with them, memorized them or implemented them recently.
I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews (and there are companies that ask that question). Always stuck me as weird as multiple papers have been written about that problem, are you really expecting someone to implement a solution to a problem that people spend weeks (months?) thinking about before publishing? Could even Djikstra have come up with the Shunting Yard Algorithm in a 45 minute interview (with implementation on whiteboard) if that was his first exposure to the problem of expression parsing?
One important thing you learn in interviewer workshops is to avoid asking questions with "aha" components, i.e. things that can only be solved if a very specific insight is known. This type of question is problematic because it falls victim to the fallacious assumption that a candidate that excels in one specific problem must necessarily excel at others that are in actuality, at best, only marginally related.
Instead, it is better to ask questions for which the solution can be arrived at with small increments in effort (e.g. maybe there's an obvious brute force solution and you start from there to discuss more optimal solutions, or maybe the candidate got stuck on some specific peculiarity and you can give a hint to unblock them and move on to another part of the problem to get more signal)
For anyone interested, there are a lot of interesting studies on the topic if you search on Google Scholar. You've probably already seen matchstick arithmetic problems before (i.e., move a single matchstick to make the equation valid).
I mean, if it works for programming...
It's way too complicated to code on a whiteboard. I would never have asked somebody that question at Google.
Also, is it a widely known algorithm? Because then I'm not measuring for programming ability; I'm measuring for rote memorization (there are people that will rote memorize all the sorting algos to be able to spit them out during interviews!).
Asking for a simply program like wc, in my opinion, gives a much better idea if someone can code (hint: there's not a single way of writing it and to define a word).
> I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews
That's a cool problem to use. I wouldn't expect a perfect parser or even a working one but I would be curious to see how they approach the problem and what they end up writing.
When I interviewed at FB, every round was something that I had drilled on leetcode or similar sites. Yes, the wording was changed and the problems were altered a bit, but they were the same algorithms. And there were also two "lightning" rounds of 15 minutes each to solve two simpler algorithms problems (maybe easy/medium difficulty on leetcode). This experience gave me the impression that facebook's goals in hiring were to select people who really wanted the job and could pass quizzes well.
But I suspect what has happened, is that as those hired by this method got promoted, they started asking harder questions... and that has over time escalated into the current situation which has become somewhat ridiculous in terms of pre-study, etc.
I just remember too many dumb questions like that and am a bit salty.
Yes, the more stressed / slow thinker you are, and the more work you need to put to prepare these interviews. It's not uncommon for people to practice for years.
I don't think these companies exactly want this type of profile, but when you interview 10000s of people, you need some consistent criteria so that all candidates are treated equally. With that constraint, I don't think you can find a better interviewing system.
To be fair the interviewer described my performance as "muscling through it" (exact phrasing changed to protect the innocent) so take it as you will. :)
I am aware that there is no way to write this comment without sounding like a boast, but that's just more reason to write it because there are probably a large number of people with the same story who can't balance out the discussion by telling it.
And we're supposed to be desperately anxious to work for companies filled with people like that?
Obviously not all interviewers are like that, and at more senior levels, interviewers do place more emphasis on other criteria, but for entry/L4/L5-ish roles, it's a pretty rampant thing.
Someone without the proper CS/programming background who is just trying to rote memorize will screw up the details, and not be able to explain anything if asked about it: like what is the purpose of that line of code?
Only problem is, even if this interview question is good at testing that which it is testing, it might not be selecting people along the right dimensions in terms of being suited for the job. It's not probing all the attributes of a software engineer.
Five candidates, A, B, C, D and E have done equally well on the exercise, excellent in fact, and are hired.
Yet, in actual work, things go funny.
A doesn't seem to believe in testing. Deliveries are sloppy and break things all the time. A is proud of her skills and treats criticism of their code as an insult.
B has never heard the words "version" and "control" in one sentence. B works on an out-of-date version of the code to make a change, and then follows the Wiki instructions for getting a fresh checkout (which pulls the latest baseline) and then just copies their previously changed files into the new checkout. Their code submission therefore reverts numerous changes from other people (incompletely: just in those files), while asserting their own changes. On top of that, B makes gratuitous whitespace changes, doesn't follow any consistent coding standard (never mind the prescribed one), and randomly fixes things he sees wrong that do not relate to the topic of the change.
C cannot handle changes in requirements. Even after code base has undergone many changes, C keeps thinking in the same concepts from when the code was two months old and C had been mostly working alone on that code, knowing everything about it. C's ideas about making changes no longer fit the new code. E.g. C cannot remember that some logic is now distributed, running in several places at once, because that's not how it once was, and consistently forgets that aspect.
D cannot say no to any new task. Whenever someone talks to D, D gets distracted and excited and starts looking into what that person was talking about, and doing work on it. Whenever D gets stuck on something, D easily finds something else, and forgets about being stuck, or to report having been stuck. D leaves numerous tickets in an in-progress state, and that list just grows over time.
E is simply lost in any large project. E has done nothing but programming challenges under 1000 lines of code. E has no skills with regard to navigating a large code tree and understanding the structure of something made of tends of thousands of lines (or orders of magnitudes more). E gets paralyzed when faced with making a change to a large system that will involve making some small changes to eight or nine files. But have you seen E's Tetris in five lines of code?
Do people like that ever make it into Google, Facebook etc. or is it purely a hypothetical?
except that these things aren't research material anymore and are now taught at undergraduate level.
If you care is someone has completed a Computer Science degree, ask to see their resume. If you care if they actually learned the material, ask to see their GPA.
However, assuming that extensive knowledge of certain algorithms (like merge sort), data structures, or computational methods are necessary for a particular job, I think a better question to ask isn't "how do you implement merge sort" but instead to present the merge sort algorithm and then ask the interviewee how it works based on the code given. Obviously still not the best way to assess someone's skills, but I think it's better than just memorizing a bunch of algorithms without being able to explain how they work.
Wirth's "Pascal User Manual and Report" has a listing of a program on pg 75 that does just that. Except it emits the expressions in postfix form rather than evaluating them. It's 31 lines of code, including declarations and `end` statements.
K+R "The C Programming Language" has a desk calculator that evaluates postfix form on pages 74-75 which is about 60 lines of code including lines with just a {, and handles +-*/= including user interface and error checking.
A binary merge sort, if written recursively, is straightforward divide-and-conquer. The input list is divided into two halves, which are separately sorted via recursion, and then the sorted halves are merged to produce the sorted output.
The algorithm pops out of the definition. If you know the above definition (or the interviewer has provided it, which they should!) the rest is just an exercise which demonstrates that you can:
- completely analyze a problem's cases, including figuring out the existence of cases that are not spelled out in the description (like how to terminate the recursion)
- manipulate pointers
- decompose a problem into small, simple functions that you can separately reason about: (merging two lists, chopping a list in half, and such).
It's not such a bad interview question. I would actually tell all the candidates at least a day ahead of time that they will be implementing merge sort in C using a singly linked list during the interview, so they can study it all they want and rehearse coding it.
It's complicated enough that it can't just be regurgitated from memory by someone who doesn't know what the are doing. (Say, someone who had someone else write the code, and then tried to rote memorize it.) The memory has to be accompanied by understanding if the candidate is to reconstruct it with few or no flaws.
I work in a Wall Street trading company. Up til about 6 years ago, I was actively involved in recruiting tech staff and defining our tech recruitment process.
I’ve since changed roles, but was recently asked to sit in on an interview.
Wow, how things have changed. I seriously doubt I would be successful going through the current recruitment process.
Any why? Focus on whiteboard programming with questions that far exceed the requirements for the day-to-day job.
Somewhere along the line, egos took over and we have a bunch of devs on an ego trip to prove how smart they are.
The ability to solve contrived coding problems is a muscle that needs to be exercised, even when one does actual programming for their job every day. I'm guessing most people don't practice interviews when they aren't expecting to interview, so only a small percentage would retain enough to pass a loop.
It's obvious but geek culture sometimes need things like this explicitly stated.
Other than "because we've always done it that way", what do you learn about a candidate in a 30-60 minute whiteboard interview where you ask them to implement something they'll never have to implement on the job, while restricting them from all of the resources they have been trained to rely on (internet access, man pages, etc.)?
I still don't understand what you're learning from the 30-60 minute interview. If you want to know if someone has a CS degree, look at their resume.
>The only real change is there are a lot more low-quality programmers than there used to be.
You'll need some data to back that one up.
>If you have to cheat to pass a test I think that would tell the interviewers a lot.
I would consider someone smart if they use every resource available to them to solve the problem presented to them. You consider it cheating. What a weird way of thinking -- just rote memorization for everything in life? Everything must be from first principles? Sounds tedious and inefficient to me.
Smart people realize that other smart people exist, and might even have valuable ideas or solutions applicable to their own problems.
Memorization can certainly be important. Memorizing random algorithms that you will never actually use during the job is less so. Conversely, other skills are important too. Poorly executed whiteboard interviews will select crammers who lack many other skills.
Meanwhile a dev can study leetcode for months and land a job where it turns out they have little to no experience in the actual work they will be doing day-to-day. Who would you rather hire?
Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
When I applied for a job at Toptal this made the algorithm-test disappear like snow before an up-close nuclear blast.
I've interviewed hundreds of candidates over the years and I would never ask a question I can't also answer from the top of my head, in detail, and then some. Turns out, most technical interviewers who ask you "write a bubble sort" couldn't do it themselves.
And if they could, it'd be full of bugs. I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution. I don't need developers who can reinvent complicated wheels from scratch; I want developers who are efficient.
Likewise, I don't want to work for a company where developers pride themselves on over-engineering their things.
Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.
You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
Be kind to people. Show your maturity by understanding what is the other person's role in the process.
If you have so much knowledge and experience as you claim, you should have no problem going through the process -- your willingness to go out of your way to do this kind of shit does not show you are going to be nice person to work with.
> I would never ask a question I can't also answer from the top of my head
That is prerequisite, but not yet full solution.
You are asking candidates for things you know which means you are comparing their experience to yours. What if they have different experience and met different problems?
Ideally, you want to answer a question "Can they be productive at their new position?" which is a different question from "Do they know everything I do?"
I always remind myself that it is likely every single candidate I interviewed knows something I do not.
> Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
Speaking up is aimed at fixing the problem. People who "speak up" do it because they believe it is necessary to create publicity around the problem to get it fixed.
I can’t think of a better approach than the golden rule here.
I'm not being an asshole, the interview goes both ways. I want to know who I'm working with and whether they practice what they test for.
> You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
Oh come on, stop being so subservient. It's just a company.
The company is trying to convince me to work for them. If they want to know about what I can do for them, I have a lengthy resume and 5+ references they can call.
> He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
It's not a difficult job, though. Their recruiter can call my references, she can check if I worked at the companies I listed, their technical people can absolutely ask me relevant questions. But if they go into the realm of leetcode nonsense, then I am absolutely going to play that game with them.
And I don't really care if I get the job or not, I can afford to not work for about 20 months if I need to, and if I reach out to any of my on-call recruiters they'll have 5 job OFFERS for me in the next 14 days.
> Be kind to people. Show your maturity by understanding what is the other person's role in the process.
Well, I'm tactful in real life, trust me. My anonymous discourse on a forum like this isn't my conduct in real life, obviously.
> I always remind myself that it is likely every single candidate I interviewed knows something I do not.
That's a real good mindset, and I think it's guaranteed. Many junior developers still teach me a lot every day in my work.
---
> Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
I did.
When I got into Apple I was one of the first to introduce them to React Native for one of their in-store specialist apps that were also customer facing. High requirements for quality. I setup a small team (1 back-end dev, 1 front-end, 1 full-stack, 1 designer, 1 product manager) and we finished the software to the requirements in ~4 months where we were given 12 months.
And I think I'm extremely pragmatic, and that it's in my nature, historically speaking. I'm detail-oriented, fast, creative, and while I have my preferences, I easily change my mind when faced with new or better information.
And if I can't change or improve what I do a company (it didn't work at First American, for example), I'll just leave. I'll definitely try, but it's easy to see unbreakable walls of politics and invested third-parties who just want to write and invoice hours, not results.
A local bank I worked for, too. They promised me the world and gave me "unlimited power" to improve everything I wanted. Turns out, the unlimited power only went up to my own level, and I was still 5 levels below the hyper-social CTO who didn't know anything about the technology we were working with.
I don't like complaining, I like solutions. I bring solutions to the table. And it takes more than just me to get them implemented, especially in larger companies...
Also
> Seriously they have 1,000 other qualified candidates lined up right behind you.
I’d kill to have ten qualified candidates to interview. It’s a seller’s market.
Dumping at the start of that meeting out of the blue this criteria, is not a two-way street equal reciprocation of that respect. If you'd kill for ten candidates, you can have him. I've had ~230 for 2 position this week and I'm testing for EQ also. Maybe changing requirements on people at the last minute fits in your work culture.
Companies are having a very hard time finding software engineers. For the first time in the history of the market, employee retention budgets are skyrocketing because recruiting is so expensive and hard. It's not rare to hear software engineers getting a sudden 30% raise out of the blue.
Because they know we're in high demand, and they know that if we switch jobs we'll get a 30% raise, at a minimum.
You either have a position that is so elite and aspirational that it is paid accordingly and people are flocking to it - and good luck filtering out the majority of resumes that Dunning-Krugered their way into your inbox before the elite candidate moves on. Or, you have a position with requirements so low that you can easily get candidates by the bucketful and take your time to sift through to find a diamond.
Most of us aren’t hiring on the margins.
I really doubt it.
That is really not the case right now. It's REALLY hard to even find candidates in the first place. Especially people with OPs years of experience...
That's far more realistic. In today's world, we're not looking for jobs, jobs are looking for us. Desperately so.
They also mention bubble sort a lot. Bubble sort.
> If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole".
Well, I wouldn't act like I write on an anonymous online forum like this, obviously.
So far I would say that most of my ex-colleagues would describe me as someone who is quiet, listens well, makes lots of notes on a paper, has a fancy pen with ink, and is surprisingly non-hipster despite all that.
I'm very involved with helping other developers in my social network getting the most out of job interviews and salary negotiations. I know the right ways of getting the most out of performance reviews and how to nail an interview that would otherwise make one uncomfortable.
But, point taken.
This is a great way to end the entire job interview process and make sure you're never called back again.
Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.
I'm cringing just thinking what it would be like working with someone who had the gall to pull that kind of nonsense.
I don't see why a 20 YOE candidate with predictable capability has no right to also likewise determine how experienced, qualified or intelligent team members on the interviewing side are...
I once flat out refused to solve a question and still got an offer.. It really depends on a lot of variables to make a blanket statement either way. One of the variables is your level of experience. After a point, the fact that the interview goes both ways can skew heavily in favor of the candidate and if you're tactful and polite you can totally get away with driving the interview away from stupid problems. If you can't, then maybe you don't belong there and maybe that's ok. It's a win-win. A job is not a blessing, it's just a job. Unless you're starving, there's no point in pretending you're drone.
As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade, if only to see how the candidate deals w/ hiring (since for the sort of roles I evaluate for, that does come up as a job task), but I suspect that I'd see a holier-than-thou attitude that I've seen from bad interviewers and that that would be a negative flag (and, no, the "I'm not fired, I quit" thing won't work with me, because - not to brag - I'm pretty confident in my interviewee skills even without cramming leetcode)
Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.
A company shouldn't have one interview process, they should have several. Some do well with live coding, some do well with take-home assignments, others do well with pair-programming. All are valid ways to show skill. And each can also be something that makes the candidate incredibly uncertain and stressed.
> As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade
It is always a two-way interview. It's not a charade. You sound extremely entitled and elitist just by saying that. The candidate has 5 other offers waiting for them that aren't being a pain in the rear like you.
Don't "entertain the idea", you are applying to the candidate as much as the candidate is applying to the company you work for. Get over yourself.
I'm surprised you're saying this in such a one-sided way, since you claim to interview candidates. I interview as a candidate too just like anyone else, so itemizing interview process problems is preaching to the choir. But IMHO it's disingenuous to ignore that candidates cheat, that college kids putting 10 hours on a take home assignment are very different than mother-of-three w/ 10 years experience, that bad interviewing on the part of my peers leads to me picking up someone else's slack later, and that generally speaking interview sessions are uncomfortable scenarios for everyone, no matter the format, much like code formatting styles never fully pleases everyone.
If you've been involved in defining interviewing standards, surely you must be aware that having several interview processes is even harder than standardizing on a single process: there are issues of interviewer qualification, calibration, throughput, interest, attrition, and other fun logistics things to think about. Saying every company should bend over backwards and have master interviewers fully calibrated in six different interviewing methodologies, at scale, at all times, is really not any more reasonable than a company expecting every candidate to bang out bubble sort in 30 minutes or take 10 hour take home assignments or whatever. And letting people do whatever is how you get to the Apple horror stories you see elsewhere in this comment section.
The thing about people having other options lined up goes both ways, really. Just as candidates have other options lined up, companies also have candidates lined up. In mine, HR literally needs to be mindful to not flood people w/ too many interviews each week.
> It is always a two-way interview
Oh I fully agree with the spirit here, but there is also a thing called tact. I don't go on pissing contests w/ my candidates as an interviewer and I don't go disrespecting an interviewer's time by saying "you know what, you don't know how to interview me, let me show you how I do it to you" (and yes, I believe this is tactless behavior from the perspective of myself being a candidate). If my awareness of industry standards is me being a hard-ass in your mind, I don't know what to tell you. Industry standards are what they are, ad-hoc and imperfect as they may be, and at least I try to understand the problem space and make the process better rather than just being passive aggressive about it like so many interviewing-related threads are.
When I say "I might entertain the idea", unlike sibling comments here I do actually mean exactly that: if you think you can show your skills better that way than my planned interview structure, by all means, go ahead and show me, but when I say "charade", I also mean that: I'm still evaluating you just as you are evaluating me, and if you think I'm evaluating whether "you're as smart as me(tm)", you've got the wrong impression. If your strategy as a candidate is to talk my ears off, I'm certainly open to it as an interviewer. I have had sessions like this from both sides. I'm familiar enough with this interviewing trick and how "talkers-who-dont-walk" abuse it. To be clear, I'm not saying you're one of those, but that as an interviewer, one needs to be aware of bad faith actors, and it's one of the reasons many interviewers cringe at the thought of "curveballs" like the one you suggested.
I am not difficult to work with and I have a real good track record at applying for jobs, and getting job offers. Anecdotal, sure, but when an applicant gives me a good reason why they feel a certain part of the interview isn't helpful to either one of us, then I adapt. Especially if that person already got through the recruiter and tech-review filters, that means they are good.
Boss wants employees to write many hours, not have a weekly phone call from the client asking to replace another team member...
Agreeable people also stick around longer, because they think loyalty pays, and agreeable people rarely negotiate a good salary.
Once up and running as a senior engineer with tons of experience, I had no autonomy and wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.
I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.)
Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason.
You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it.
But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.
I'm not really opinionated about whether or not you should do algorithmic stuff in the interview, but I don't agree with your reasoning here.
I see chatter about how most problems can be solved with google and your CS teacher lied to you (usually on reddit, less so on HN). My experiences have not matched this. I'd estimate that a good 40-80% of my problems don't have a solution on google. It's pretty rarely an algorithmic problem though.
If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
Still, sometimes I run into limitations with regard to TypeScript, for example. If that happens I'll go over the problem with more experienced developers. It'll be a pair-programming thing for several reasons: two pairs of eyes and two brains see and think more than 1, and you both learn something new, and you both have a little more brainpower available because you want to look good. At least I do my best a little more ;)
> If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
It's a silly example, I don't care what algorithm we're talking about. And no, many languages lack any sort of built-in sorting solutions. JavaScript (front-end and Node.js), for example, requires external libraries for performant solutions.
Somebody with 20 years experience I would like to explore that they are not a bullshit artist and not subject them to worthless leetcode questions that some desperate 24 year old will cram, pretend they never saw the question before and spam out on a whiteboard.
and quite often the desire is to have servile drones.
I once had a phone interview at a startup. The interviewer showed up 20 minutes late. And the first thing he said was, "I was in a meeting and before you ask, I can't tell you anything about it because then I have to kill you".
??? I just hung up.
I think it's pretty well known that the question, or the actual question for which this bubble sort question is just an example, is usually more about how good you are at solving a particular problem.
For example, I'd rather not have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution, because I want my developers to know that bubble sort is an O(n^2) toy algorithm mostly used as an example for an intentionally bad sorting algorithm.
(while I meant "he" as a gender-neutral pronoun, sadly, nearly all of our senior tech candidates are male, but one bright spot is that we've got near gender parity with college interns which I hope means the job market is becoming more balanced)
I also notice the paragraph near the end with couple of general lines on good interview and the "that's how I hold interviews".
Here's the thing. Nobody sets off to intentionally be a bad interviewer or coder or manager or whatever. It helps to have humility and significant open introspection to be good at something (not the only path but for most of us it's the best path). We ascribe wilful incompetence to others while we have excuses and lessons learned for ourselves. Maybe - likely - the other interviewer too thought they were giving opportunities and signals and letting people at ease?
That said, given that candidates are generally nervous to some extent anyway, and semi-colons shouldn't matter in a whiteboard interview, that joke seemed like in poor taste to me. That underscores why we need better training and mentorship for interviewers.
I left the interview feeling totally confident I'd rocked it, since there were no "inverse binary tree" curveballs or anything like that, and figured that the company just wanted to make sure I knew what a stack was and what some properties of arrays are. Got rejected, asked for feedback and was told none would be given, so I rinsed the bad taste out of my mouth and went with another company instead.
Being decent to people is important and you are important enough that you can expect to be treated with decency.
https://blog.interviewing.io/no-engineer-has-ever-sued-a-com...
In the meantime, a lot of us want to improve and be told what we did wrong. It's the least you can do if you used several days of the candidate's life, don't you think?
My favourite was switching conference rooms until we ran out of time and the interviewer thanked me and invited for a next session. There was also one when the guy was late 30 minutes to a 30 minute interview. And the one when they spent 1h with me and at the end told me the position has already been taken. I had one where interviewer smelled really, really bad -- I left when I learned he would be my boss.
I also had one where the guy said he is "best programmer in the world". I thought he is joking. Unfortunately, he wasn't. He became my boss. I left a month later when his code failed in prod (he parsed XML by specifying a line and character number to extract piece of data) but he blamed it first on the vendor (they apparently changed the format when they turned off pretty printing) and then on me (I haven't even touched the code). Apparently he never makes mistakes -- he always blames somebody else.
To be fair, I have also a lot of "bad candidate" stories. Like a guy with a lot of knowledge who says at the end of interview he doesn't want to get hired, he just came to exercise before going to another company.
From my PoV as interviewer I think the only real egregious error here asking the candidate to write in unfamiliar language. It doesn't matter what the language the project uses, the whiteboard needs to use language that is comfortable for the candidate. We can discuss knowledge of the language as a separate issue.
Now, asking the candidate to write a particular algorithm on a whiteboard from memory is just a waste of time. The purpose of programming exercise is to see if the person knows how to program, not if they have memorised particular algorithm.
Writing an algorithm like merge sort could still be productive if the interviewer has first explained the algorithm and then asked to implement it.
But I still feel merge sort is a bad choice -- I prefer simple task but one that I created myself so no candidate is familiar with it. I am interested how the candidate works on the task and how he can communicate with me to solve it. You would be surprised how many candidates dismiss hints they are being offered.
Maybe being put off by an ambiguous comment was why you didn't get the job? Did you consider maybe in his notes he might've said: "Smart guy but was put off by a single comment (a failed attempt at humour on my part). Probably not someone who would thrive in a lively atmosphere".
I had an interviewer ask a question and, not satisfied with the answer, get up and walk out. The other guy apologized and we had a good discussion after the other guy left.
Good for you I guess, but maybe don't apply your own mental blueprint to the rest of the world. Recommending candidates have thicker skin isn't really great a way to improve hiring in general.
It does sound a bit annoying, but if that is the author’s worst interviewing experience, it’s not that bad.
at a point in my career i faced a similar dilemma but handled it completely differently than i had earlier. someone made a snide comment "but why would you use bash for this?" and i was able to take it in stride and the result of that comment got me the job. but at the start of my career i may have reacted negatively, i may have clammed up and stammered my way through the rest of the interview etc (i didn't get those jobs). could you imagine being in front of a C-level exec or a $300M customer and being discombobulated?
no one wants to hire an insecure pre-sales engineer etc
EDIT: i'm assuming engineering levels beyond senior. my past experiences have been around principal/architect roles which require a 'tough skin'. i would not expect rude remarks to a SE1 or SE2 and if that was the role, i would leave flustered with a bad taste in my mouth as well
A somewhat comparable analogy is your manager joking about firing you and then evaluating you negatively when you don’t like the joke.
“Oh hey jumping between languages is hard, looks like you’re thinking in Swift right now, no worries about fumbling on syntax happens all the time”
My impression from the OP is that they were out of sync with their interviewer, they didn't "click". This is something that happens with humans. The interviewer may have detected this dynamic, and made the joke to break the ice. Obviously it backfired, but with another candidate perhaps it could have saved the interview?
Separately, what do folks thinks about the importance of humor on teams, and the degree to which it's acceptable to screen for sense of humor as part of interviews?
Here is how I see it. At best, you interrupt a candidate in the middle of a technical interview to make a joke. At worst, you ruin the interview experience for the candidate. To me, the cost/benefit is clear cut.
During a technical interview, you are evaluating the candidate’s technical knowledge. You are not there to become friends. There will be time for that after the candidate goes through the interview process.
Anyhow, to answer you, on both sides of interviews, I've experienced bad chemistry early in the session. Could be any number of factors, even just one of the two of us getting out on the wrong side of bed that morning. I sometimes will make a joke to lighten things up and get things back on track. Sometimes it helps, sometimes not, but I like to feel over time I am learning better how to interact with humans, and improving my odds, leading to more positive interview experiences and less wasted time. Things are never "strictly technical" with humans.
(all that said, to be clear, I have never brought up the candidate's sense of humor in providing feedback, although I don't see a problem doing so if humor is in the team's values manifesto or the job description, and we've agreed on a legitimate way to screen for it (seems hard!). Curious to learn others' thoughts on this subject!)
1) felt that the tone of the interviewer was negative
2) was in the middle of writing their solution
3) did not actively ask for feedback on syntax
Point #1 is subjective, but an interviewer should err on the side of caution when making curt remarks like this. Taken together, points #2 and #3 are important too: as an interviewer, you should know when (or even whether or not) to provide feedback.
As for why I believe the comment above phrased it better:
1) the interviewer is clearly acknowledging that it can be challenging to use a different language in an interview
2) the interviewer is clearly stating that the syntax mistakes being made are minor and nothing to worry about
Personally, I would still avoid making this kind of comment unless prompted by the candidate - e.g., in reply to "I think I might be making a few mistakes with syntax here". I would also avoid providing any feedback.
I also agree that an interview is not purely technical: there are other _passive_ signals you can use to build a better picture. I don't see how you would be able to judge sense of humor reliably in an interview setting, though.
A negative reading is “you are screwing this up enough for me to comment, you need to justify why”
If it’s intended to be reassuring then phrasing it so it’s clearly not a criticism is better. If it’s intended as a criticism then phrasing it clearly is also better.
The way I can see it being a joke, as claimed, is insultingly. Like a dentist watching a trainee dentist doing a filling and saying “you must have been doing masonry work lately”. Haha but the subtext is “you’re really doing a bad job of this”.
The only other choices for the interviewer are to bluntly say "you missed using semicolons" or to not say anything and be left to wonder if the person knows how to really write in C. The author of this post seems to think even considering any other choice than the last is rude since "whiteboard code doesn't compile so semicolons are syntactic sugar".
But if it does matter, baking in some understanding of the charitable reasons why (that the interviewee is proficient at multiple languages, especially in the popular ones at Apple like Swift) is actually the nicest thing the interviewer could have done.
The post author seems to me hostile to being corrected. Given that every code review I've been in requires being corrected dozens of times about errors large and small, I wouldn't want to have to deal with their uncharitable attitude towards feedback from coworkers/collaborators.
Code reviews after already being hired and accepted into a company are not comparable to interviews during the application process, when the specter of rejection still looms.
This sounds like a cartoonish training example of the kind of subjective, possibly biased feedback that you absolutely shouldn’t be writing down as an interviewer.
That means it’s possible to have a horrible interview experience with one team, and a great experience with another team.
Not saying this system is good or bad, just trying to describe the system.
Hell, in an interview I had this week I was given multiple incorrect answers to my clarification questions. Even when I said “I believe I answered it” the interviewer said “I don’t think so” until he finally looked up and was like “oh you got it”
I’m on zoom watching the interviewer text / look at other screens as I ask clarifying questions and they give dismissive answers “yea yea that sounds right, do that” while never looking up from their phone. Was a pretty “wtf” moment. I completed the interview, but I got the feeling the review will be subpar.
"Sorry, it looks like I must have caught you at a bad time. If you have a fire to put out, I totally get it."