My worst tech interview experience
jessesquires.com
jessesquires.com
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.
Funnily enough, I also interviewed with the Apple Watch team around the same time and had a similar negative experience.
I was struggling with a problem on the whiteboard and paused to ask a question. Instead, one of the interviewers (it was a pair) turned to the other and said “I wish the Calendar complication on my watch would show when this meeting ends”
All the other interviewers that day were great, but it just takes a few bad apples… Even though it’s been years and I’ve had a nice tenure at FAANG, I’ll never consider joining Apple after that experience.
A candidate asking questions and trying to unblock himself is an extremely positive signal. It means they are capable of communicating and not start panicking when they hit a blocker.
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."
This article lays out the problem very well, but then again so to very many others which have appeared on HN over the years.
Why does this keep happening? I mean this at the most fundamental level.
Why waste time with programming puzzlers to begin with? Does the candidate's degree (assuming no job experience) not obviate the need for this kind of thing? Do past programming gigs not absolve them of the need to perform in a way they'll never be asked to perform on the job? Are CS departments so full of bullshitters that unless you sic your 10x devs on them to sniff out whether they can program their way out of a paper bag, your organization runs the risk of filling up with "C Players?"
I mean, what's really going on here?
Best way I've found is to talk to them about their experience, sort of post mortem style. Pretty much everyone can talk about their experience in some respects, even those working on classified projects; you just need to respect their boundaries.
I've done pretty well at interviews despite being terrible at white board exercises because my personality is such that I treat these interviews casually. It's not that important in the larger scheme of things that I get this particular job, I'm looking at the interviewers as much as they are looking at me to see if I could work with them and I'll often joke around and keep it light hearted, even when failing a white board exercise.
The interviewers know the work culture and are looking for someone that can fit. In the case presented in this blog post, the writer could not handle a small joke about the Swift language. The interviewer probably knew the team like to joke around and tease, so this person was not a good fit. I think it's really that simple. I really doubt the interviewer thought the person was not technically qualified.
In one case, I was in a particularly light hearted mood and I joked throughout the entire interview. I believe to this day I was hired to lighten up the mood of the team, which turned out to be a very serious and gloomy bunch.
I've met people with degrees who can't program out of a wet paper bag. And also people without a degree who can program circles around anyone. It only seems to be an indicator of your ability to finish a long term project, unless it's a top school. Then it's a slightly more positive indicator.
> Do past programming gigs not absolve them of the need to perform in a way they'll never be asked to perform on the job?
When I was doing interviews for Netflix for Senior Engineers, I always asked FizzBuzz on the phone screen. These were all people who had at least five years of programming experience on their resume with titles like "Senior Engineer".
50% of them were unable to do the assignment in any language with unlimited time.
So it appears that a resume is not sufficient either.
I hate puzzlers and quizzers and never use them (other than FizzBuzz, which frankly anyone who can code should be able to do). But I don't know what exactly we can replace them with.
I personally just ask the person more general questions to understand their depth of knowledge and then explain what the work will entail and ask them if they think they can handle that. Then I hire them and give them work and let them go (or let them quit on their own) if they can't handle the work.
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
> I will never interview for Google or any other company that
> asks questions like "How many jelly beans fit in a school bus?"
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.
He went through the five interviews. After, we met for 20 minutes to express our thoughts. Pretty uniformly we agreed: the candidate was middling and we'd be better off waiting for someone better. We rejected him.
A day later the rejected candidate called my phone (how did he get it?) and said something like: "Hey, this is <candidate>. Why the hell wasn't I given an offer? The recruiter said that you (that is me, personally) had rejected me. Explain why." He insisted he had done great and we should reconsider.
The candidate hadn't reacted well to the rejection, and rather than being the firewall that shields the interviewers, the HR guy passed the buck and blamed me. We didn't reconsider, and I gave the HR guy hell about it.
Surely someone at your org could have determined that it's better to stop wasting each other's time before going through 5 interviews?
Sounds like there's more to the story than you're having us believe and the candidate had very good reasons to be upset (the exact wording and tone he used was not appropriate). If he insisted he had done great, I venture to say that he was led on during interviews and not given honest feedback.
Why did he go through the full round of interviews? Because (1) he was referred by an existing employee so interviewer were inclined to give him the benefit of the doubt, and (2) he wasn't terrible, just nothing special; it sometimes happens that one person gets a low impression and the others think they are great and we hire them anyway.
You surmise I must be telling part of the story because his reaction doesn't fit my description of the process. Yes, that is exactly the point of telling the story -- his response wasn't appropriate. Had I felt he had a reason to react that way, I wouldn't be retelling the story.
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.
He slammed (SLAMMED) his fist onto the table and yelled, "NO CODE!"
-----
Other bad experiences included Palantir telling me my onsite went really well, and that they'd like me to come in again to meet the hiring manager. Expecting to talk business, I instead was presented with 2 more algorithm questions. Those apparently went OK, so the next discussion with the recruiter yielded another "informal" (his words) meeting with 2 engineers via VC. Both ended up being 2 more DS/Algo questions.
-----
Another bad one I remember is a request to do a take-home coding test from Docusign (also circa 2012). They wanted me to program a "fully tested" elevator simulation using Stylus, Coffeescript, and Jade. I had never used any of these technologies, so I asked if I could write it in what I was familiar with (jQuery, Backbone, SCSS, ES5), which was denied. It would have taken me a full week to get up to speed on all of those technologies enough to submit a solution worthy of review. Absolutely ridiculous to ask a candidate to learn new frameworks just to complete the interview.
This whole process is so broken. Great devs get passed up on for terrible devs who know how to grind Leetcode and the like. I hate having to grind leetcode for weeks just to end up getting asked obscure algorithm puzzle questions that I could never prepare for. And all for a 100% React job? Jesus.
It looks like these folks really bought into it.
It's obvious but geek culture sometimes need things like this explicitly stated.
- Giving trick questions that have an "insight" moment, instead of one that has multiple answers, even partial answers to build off of.
- Not letting the candidate pick the language they're comfortable with. The candidate may even know the language they're asked to code in, but if they haven't been working with it recently, an interview is not the right time to pick it up again.
- Making the candidate nervous, both by not being helpful and by watching over them with unnecessary scrutiny.
- Looking for flaws instead of strengths.
People, myself included, are always talking about these problems, but companies have so much inertia, they are not evolving fast enough to solve these problems. No wonder tech companies are filled with people who, while capable, often fit a particular mold, and why we end up in situations where products don't reflect the needs of the market (because the people working on those products aren't representative of the market).
1. Being steered away from my answer for an algorithm problem, towards the interviewers preferred answer. When I reflected back on it later, I realised that my answer would have been more efficient for the specific problem asked, whilst the interviewers solution was for a more general version of the problem (which wasn't ever asked).
2. Being given feedback that I was weak on data structures, when there hadn't been any questions about data structures. I am weak on data structures though, so perhaps they just peered into my brain somehow.
3. Being told I wasn't suitable for remote positions because I was too verbose answering questions which were essentially trivia -- when I was intentionally trying to capture nuance because I didn't want to fall prey to trick questions.
1 and 2 were for the same company, but different stages.
I recently applied and got an offer from a big N company. It took forever, easily three times the length of my other processes. I was not given any insight into my team beyond an overarching organization. The pay was not fantastic and they didn't honor my first location request. Why would I accept this? The pay I could have negotiated. But I'd still be put into a random, likely boring team in a city I didn't pick as my first choice. All to be able to work at a "Big N" company, when I've already had that experience. Maybe that works on some people but after the first Big N it's really not important.
Bonus points for getting up while the interviewer is in mid-sentence and telling them it's not a fit.
(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)
This should be an entertaining thread.
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.
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.
So I asked the recruiter to talk to the hiring manager to give me another shot with a different computer, and never got a response.
Mind you: they also had a horrible recruit process of filling out paperwork on their web site; including a form-entry version of your resume that you already uploaded. Plus various other forms to fill out and disclaimers to sign. Honestly, the worst I had ever encountered.
Since then, this company has had 3 different recruiters (one internal, two external) try to contact me for different positions, but the first one asked for the same process of going through their careers website and filling out all the forms again - even though my previous record was still there: because it was a different position, it had to be done again. That's when I bailed.
At times when I have been anxious to get hired, I have had no problem demonstrating that I can fill out a bunch of redundant forms when required.
Sometimes you need to be able to do that sort of thing, even in the best organizations.
On the other hand, I don't think I'd intentionally add that to my hiring process.
There are better ways to check for conscientiousness than saying, "please do this redundant activity perfectly."
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?
Can anyone share examples of the kinds of questions I should be asking? Are there any good articles about this?
The second half is the brownie points session: it's where the candidate gets a chance to demonstrate that they're better than average, be it by demonstrating strong algorithmic thinking, or good refactoring and/or testing practices or what have you. Good candidates ace questions on multiple dimensions and it's pretty easy to spot a gold nugget.
When the candidate doesn't meet the bar at this point, it becomes geared towards looking for growth potential (as far as me collecting signals go) and being an opportunity for learning for the candidate. It can be me giving feedback about types of things they could take into further consideration or, for less qualified candidates, a discussion of how to formulate an algorithmic idea, either in terms of thinking from first principles, or in terms of erasing dissonance between abstract ideas vs how to express them in code.
I try to always pace feedback in such a way that by the end of the hour, the candidate has completed the exercise. Sometimes, that does mean that I'm literally walking them through the process of coming up with the solution. Some think this is a waste of time, but IMHO, it's important for the candidate to leave with a good impression of the interview process. If a session is a complete bust and a waste of my time, then at the very least the candidate should be getting something out of it.
> 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.
Interviewer: You can ask clarifying questions if you need to
You: What theme do you want me to use when I format this code? Monokai? Atom?
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 :).
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.
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.
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 asked if i could at least do on my editor of choice while screensharing -- "nope, too complicated".
i asked if i could do in pseudocode, nope "it must at least run".
i tried for 10min, said "thank you, but i don't think this is working for us -- we can probably stop here. thank you for your time [yadda yadda]".
the good thing is that i interviewed and was hired about three weeks later -- and it was an even better position!
My read is that the primary cause of the bad experience is because of a perception that the interviewer made a joke about missing semicolon in the white board code.
The attribution of that being “asshole” seems typical for a young guy who was stressed in a technical interview. Especially there could be additional signaling in the interview process that is problematic to the interviewee.
But the whole post does not sound too bad to me.
My personal worst example is one guy who is asking what I did previously, and after each time I gave an overview of one project, that guy just said: that sounds very easy (that was in Chinese, we were doing the interview in Chinese over phone). And that guy is a msft researcher turned engineer. I was internally amused at his employer being clueless about the skill gaps between an engineer and a researcher.
To me the saddest part was that he basically is not able to present an interesting description of the prospect projects in his own team (apparently that's expected based on his reactions to my previous projects), nor appreciate my side of the story. That makes the time spent close to being meaningless for both of us.
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.
Sadly interviews like that became a regular fixture and some were even worse. In a few I even had take-home assignments where I was to implement a full-project from scratch then present it at the interview (as well as all that other crummy interview stuff). I even got heavily criticised/insulted in one for prioritising my current job over the assignment and was told if I really wanted the position I "should've moved heaven and earth" - pretty deranged to ask someone to risk their income for an unpaid assignment if you ask me but anyways.
With that being said, I do think interviews are becoming better. They're less about blowing smoke up the interviewers arse and more about judging how good a fit they are for the company. Interviews tend to feel more collaborative and white-boarding sessions aren't a test but a discussion, with the best language agnostic. Hopefully they keep going this way.
The recruiter also pushed me to interview with other teams, but I quickly said "no, thanks". I can't necessarily say I was frustrated though — this experience is more or less exactly what I expected from Apple or any FAANG.
If the role required some math along with software engineering, then it could have been a question that provided a good signal.
Now maybe this is the whole point, to filter out those who never went to university, but I'd say it's still pretty dumb to test people on things that most likely have nothing to do with the job or just aren't realistic.
"Oh, I know that one!" is not a solution for the rest of us. Including you at the next interview where the different question is to implement the Ceph distributed filesystem on a whiteboard, clock-ticking, and an asshole looking over your shoulder.
For me, it's all about mindset. Interviews are a two way street. Talk to the interviewer, they're people too. If there are assholes, then whatever, you've still learned more and gotten to an better outcome for you.
If you don't know the language you're asked to write something in, ask to change it to something you do know. If the interviewer says language X is required for the job just be upfront about it. Stop the interview right there and address that issue. 'Look, I don't know/haven't used x in a while. Can I use y with the understanding that I need to come up to speed quickly? Otherwise, we can get our days back.'
The shame here is that the author is still clearly bitter about something that happened 6 years ago and the interviewer probably chalked it up to another hack who can't even implement a merge sort.
typedef RWCString SBFString;
But I supposed another lesson for interviewers is to be aware of how stressful interviews are for the candidate, and to mind their language and jokes.
I was asked to write a parser which could transform a simple data format into another.
I asked whether they were looking for a fast solution, or a better one? I was told it had to be fast and better.
Thinking I hadn't explained myself very well, I asked again, are you measuring how fast I can give you a solution, or are you looking for quality. I could do either. Again, I was told it had to be high quality and fast to produce.
I took the middle ground, and wrote something in a couple of hours that did everything they wanted, and was extensible to new formats, using a variety of OO techniques.
I failed the test because I hadn't used a standard library component that could be coaxed into doing that they wanted. I clearly didn't grasp the awesome power and reusability of object orientation!
A LOT of the places I have worked there's no budget for sensible interview tools even for remote interviews (shared IDEs, etc), so you are stuck with what you can cobble together (an ad hoc shared REPL, a shared virtual whiteboard, etc). They suck a lot, and I try to keep that in account when working through problems.
The best experiences are always in an actual simple dev environment where you can collaborate on code, have a live preview of UI stuff, allow access to stack overflow and other references, etc. it allows you to present a problem very similar to day-to-day work but smaller scale.
And I gotta say, even that is just somewhat useful for gauging how working with that person for real would be. Interviews suck - nerves are frayed, it's not always representative of that persons skill, ability or non-assholishness, AND it doesn't allow for assessing general skill, ability to learn or ramp up, because everyone necessarily in the interview has to have some skill in the language and platform you are working in during the interview.
Funny times.
I don't think the idea is to have a merge sort committed to memory. More like one can go from specification to implementation in a reasonable amount of time. Me, I kinda like to write my own first, then compare it with others.
Getting flustered when on the stage is a real problem, but it fades away as one gets experienced at being on stage. Then you can respond to snarky comments with a bit of snark of your own.
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.)
Whiteboard interviews do suck, but they exist because nobody's figured out a better alternative that works at scale. If you're a small company, you can get away with a less sucky interviewing method. If you're a massively large company, a lot of those fall apart because of various reasons (you can't ask for take-home tests because a significant percentage of your applicant pool will refuse to do it because they already have a job and stuff to do at home, you can't ask to "talk about interesting code/projects you've worked on", because either (a) they already have a job but can't show you any code because it's owned by another company, or (b) they just outright lie about everything and you don't figure it out for 6 months, etc etc).
So whiteboard interviews suck, but we're stuck with them.
There's some really weird things about conducting a good whiteboard interview which are not obvious
1. The candidate should not know if they're failing. The candidate should basically always get the sense that they're doing okay enough, even if they aren't. If the candidate fails your interview, but aces all the others, that's fine. Probably they should still get hired. But if the candidate fails your interview and feels really badly about having bombed it, then they just go on tilt and fail the rest anyways. That's not good signal, it wastes the candidate's time, it wastes the rest of the interviewers' time, all because you the earlier interviewer couldn't figure out how to not tilt the candidate. This is less important if you're the last interviewer on a loop. - so generally you want to start out easy, be really encouraging, and ramp up difficulty as they go on.
Tilt is real, and it is not helpful in an interview situation.
(Caveat to #1 - this is assuming you're working at a big enough company where your policy is to give zero actionable feedback to the candidate due to lawsuits, which is probably any large company. If you're not at a large enough company where this is true, why are you even doing whiteboard interviewing? Stop lol, whiteboard interviewing sucks)
2. You can't ask anything crazy domain specific. Sure maybe the specific super detailed queuing problem you're working on right now is fun, but it probably doesn't scale well to arbitrary-engineer who hasn't thought about queuing for a decade. Unfortunately this means you have to spend a lot of time figuring out what to ask, because the things you're currently working on are almost certainly terrible interview questions.
Corollary to #2 - if you pick questions from online, or even from within your company, candidates will absolutely have seen them before, memorized them, and go from there. Your question needs to be able to be modified, expanded, and you need to know what it
3. Benefit of doubt should always go to the candidate. Forgot a library? You tell them the library, and don't count it against them. You are the candidate's StackOverflow for the interview, be reasonable.
#1 up there is the hardest. Even simple things become very difficult to broach. If the candidate is digging themselves in a hole and you are having a hard time figuring out how to hint them out without psyching them out, feign ignorance about your own interview question and try to "collaboratively" work your way out of it.
Sometimes it's impossible. Sometimes you'll get a candidate who literally does not know even the most basic of programming stuff for their own chosen programming language (obviously has not ever written code at all). I don't actually know how to handle that. Sometimes the recruiters will make mistakes and just send you candidates for the wrong job. So this isn't all-encompassing advice, because there's always edge cases.
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.
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?