The thing is, when you look for a job, you will often go for 5 to 10 interviews.
On the other end, when I'm looking for someone to fill a position in my team, I will interview at the very least 50 candidates.
That is to say, all things equal, the interviewer has most likely more incentive than the interviewee to go straight to the point, and thus perform a technical check early in the process.
Also, you have to realize than the vast majority of candidates applying for a position are highly unfit for it. Seriously, even for very senior positions, you would be amazed at the sheer amount of people applying with grossly pumped resumes, and overall low skill level once tested.
Even after careful picking of resumes, I would estimate that 80% of candidates end up being obviously unfit after the first 10 minutes of a technical interview. That's why, as an interviewer, I'm not very inclined to have a long open discussion about the job until I have at least some degree of confidence that the candidate is worth it.
Of course that process is unfair for the "good" candidates. Those who apply to positions fitting their skill set. But when you have more than 50 interviews ahead of you, and an actual job to do, you have to make compromises and tailor your process for efficiency.
The annoying ones are dudes who want you to somehow do a big O proof of some NP complete problem, with tests, proper code, and in front of 3 people in 45 mins (with 5 left for you to ask any questions). For something you may have not touched in 20+ years. I do not want a guy who can create the proof. I want a guy who can explain it in plain English to the 3 other guys in the group and maybe take a few days to get it right and make the code easy enough to understand so when we have to change it in 8 months they can pick it back up.
I have worked in the embedded industry for 6 years, and have worked on a wide variety of projects (from WiFi to drones/airplanes to medical devices), and have never needed to use this, yet the interviewer expected me to know this.
Anecdotally speaking, when recruiters throw this kind of curve balls, it's because they already have someone in mind for that position and are interviewing candidates just to fill paperwork.
Some people ask more clarifying questions than others, but in any case a few minutes gets spent on this, we have a laugh and move on with our lives.
Of the failing candidates, around one in three or so spend nearly the entire interview on this or fail to answer entirely because they can't get the maths right.
Is that a "math trick"? It doesn't feel too different to fizzbuzz. It's not complex. It relies on high school maths, and except for very junior positions, for a job where you are expected to solve much more complex problems every day without handholding, even if you can't remember how averages work so I have to hand you the math, not being able to reason through the problem from first principles seems like a pretty big red flag for your problem solving skills to me.
What do people think?
Once I show someone the 'mod' trick they instantly get it (if they have any sort of math background) but I want to avoid as much as possible anything tricky in a interview. I want them relaxed and not tense. As that is a different kind of test. Throwing in a trivia trick can hurt the interview. I have run across many programmers that are decent at it and have never used it.
Also for your problem it would depend on the level you are interviewing for and how much time you want to allocate for it. As it is also a balance of filter and getting to know them which is mostly time management on your part. Remember you probably are going to be working with them. So a bit of chit chat goes a long way too. You can also use 'fizzbuzz' as a question 'do you know the trick of fizzbuzz'. If I show them the mod trick and they get it right away they show aptitude to learn. If they already know it then see if they can explain it. etc etc... Get them to talk. Also talk back to them like a peer as they very well could be! They should be interviewing you too.
I just try to avoid tricky bits in interviews and expecting tricky results from them. It would be like asking the to write a swap two values function and expecting the triple xor solution. Tricky is for something you have been working on for 3 weeks and need a better solution, plus two spike stories. It is not for interviews. :) Just ask yourself would you be massively annoyed if someone asked you this in an interview with no context as to why and expected a particular answer. If the answer is you would be annoyed then do not do it. If you feel it is OK and you would expect it then go for it. Just remember your time management.
But if you are applying for a programming position and claim a decade of programming experience - and literally can't come up with any path towards a solution - I smell a rat.
Honestly, the latter guys are absolutely fire to work with. I think recruiting is like security engineering: 90% of the guys doing it are total rubbish so you just assume that's what it's like. But that last 10% are super good, and the top 1% are really freaking good.
I remember when I first encountered a recruiting pipeline put together by a guy who was good at it. Literally every person I spoke to was a good engineer. We did tech-screen them, but only after the initial call where we talked to them about their interests and our company objectives.
Literally every one of these engineers knew:
* What sorts of problems they wanted to work on
* What stage of company they wanted to work at (seed, series-A, ..., big established company)
* What risk they were willing to take
* What sort of team they wanted to work on
This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot.
Anyway, I was very impressed. Also, the fact that almost every one of them didn't bat an eye at the tech screen. You read some of the comments on HN/Reddit and you see that these guys are a cut above the standard dudes.
Like, just the social nous. Way off the charts. On HN, people talk about an interviewer mis-sizing the problem: "Haha, so I told him I'd do it on a single SGI UV 300 with 3 TB of RAM. The interviewer got stuck. I got him.". These guys are like way better. If you mis-size, they'll just be like "Ah, okay, so you can get this done on a single machine these days, they have a lot of RAM, but that's trivial. AWS has the u24s for 24 TB or something. So let's say the problem is even bigger or that we want the other advantages of clusters" and they'll take it away. No chip on the shoulder. No insecurity. If some constraint doesn't make sense, they'll say "Okay, if we were doing this in prod, I'd push back on that, but let's say it's the case" and just go on.
We didn't convert everyone - not everyone wants to work in our domain or wants to deal with the quirks of our team or whatever, but that's life. It was way more enjoyable as an interviewer.
I think that's probably more the rub than anything. I never had a happier time being an interviewer than my time at hypergrowth startups. The sheer caliber of both candidates AND resource allotment towards landing them was far higher than what I was able to see in the BigCo environment. It made things a lot more pleasant.
I'll give you a pro-tip: Candidate Interview Packs. Cook up some Google Slides with the main info about the position, the company, the team, what you expect from the person, what you are looking for, the interview process, etc; beyond the dry JD that HR shares. Give it the personality of your (Engineering) team and generate a PDF that you can share with the 50+ candidates.
It has worked for me in the past.
Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.
I've interviewed enough people who don't even know the syntax of a for loop for the language that they chose to use.
As a general matter for how the industry as a whole interviews, I agree though; I am no longer a fan of tricky algorithmic or esoteric data structure questions in whiteboard interviews. The problem I find with other people's interviewing questions is that most people are still asking things that are way too difficult, and they don't end up judging anything other than "Did this person just cram hundreds of hours of algorithms questions?" or "Did this person get lucky and happen to know this type of problem ahead of time?".
For better or for worse, my company schedules me for like >90% system design questions now, which I prefer anyways. Start with a very simple problem and system, and then just throw wrenches.
Most loops are covered by a foreach or by LINQ (think: map and reduce, buy nicer).
The few times I actually need a for loop I type: "for" <press enter> <type the limit for i> <press enter> and then I focus on the loop body. If my needs are more complicated, I _modify_ the for loop my IDE gives me.
However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code.
That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
I think the type of problem and structure we use for interviews is bad. Let the candidate code alone without you watching. Give them internet access. Come back in an hour or two, or let them do it remotely or as a take home. This is more like our real jobs; and gets rid of cutesy "do you know this algorithm?" questions, which many whiteboarding problems are. Instead of going for pure data structure / dp / search / sort algorithms, have them implement things like business rules.
The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me. The problem is specifically about doing a programming performance in front of an audience, in an interview rather than co-worker context. I'm god-awful at that unless I'm heavily prepped for exactly what's going on. No tools? I'll forget basic syntax, yes even in "a language I chose". Let me use tools? I'll forget how to use them, or get self-conscious and avoid things I'm not entirely sure will work, overriding my own muscle memory. It's a very specific problem but I doubt I'm the only one who absolutely can do the job just fine, but is also entirely capable of coming off like a complete "faker" in an interview.
[EDIT] to make matters worse I can talk about programming just fine in that setting, which probably adds to the "he's some kind of social engineering genius who learned to sound exactly like a competent programmer while somehow also not learning a single thing about programming" impression. It's not usually an issue, but I'm quite sure I've reinforced some interviewers' notion that it's a good thing they do whiteboard screening because they're overwhelmed with lying applicants, and that I was one of them.
I've met one developer who couldn't do their job, and he moved into a pre-sales role shortly thereafter.
Everyone else was fine and did a good job but send them unprepared to a random interview on any given day of the week and I'm sure it'd be another one of those "well we dodged a bullet there".
The signal to noise ratio is Garbage.
Sure a "whiteboard interview" basically optimizes for people who can actually pass whiteboard interviews rather than people who can do the job.
But to claim that there is a NON-NEGLIGIBLE number of people who basically become 100% ignorant when under the stress of a whiteboard interview BUT are excellent employees in any other stressful situation is, to say it in nice words, [requires citation].
And if one really has this apparent rather unique type of handicap, then better mention on CV to try to get some empathy from the hirer, or just _train_ to avoid it. Yes, most people do _train_ for the express purpose of passing interviews.
Tech interviews are remarkably scattershot in the form they take (outside well-known big companies), and are unusually anxiety-generating, even in the notoriously anxiety-filled field of interviews. Describe what one might (emphasis on might, part of the problem is that it's so often a surprise) expect in a tech interview process to some people outside the industry, and gauge their reactions. I definitely think it's likely they have even worse signal-to-noise ratio than is commonly thought.
[EDIT] Certainly I find it far less plausible that there's an absolute army of people out there, dwarfing the count of actually capable programmers, who are brilliant con-persons but too dumb to figure out that that skill itself is more valuable than programming, outside the top couple percent of programming jobs by comp, and apply it more directly to business roles that actively want it.
And I'm quite confident it's not the interviewer. Usually the panel is quite anonymous when it comes to calling a "bullshit" candidate. We ask panel persons individually to avoid the "no one wants to contradict someone calling X bullshit'" effect.
I don't think tech interviews are _any_ worse than the ones outside. If anything, we have less standardization than other industries. I work for a engineering company first (software second) and the engineer interviews are basically _manufactured by HR_ (not engineers).
In this scenario, having someone literally be unable, in 2 hours, to replicate the first example code of some library, when they have access to almost identical code in the docs, is a pretty good filter.
The problem is when you apparently _forget_ the syntax for a function declaration in a programming language you claim N years of experience in your CURRENT position. This is just absurd. Our you suddenly get completely stuck with counting odd numbers on a sequence or the like. And this happens surprisingly frequently. I just cannot believe you can have this type of anxiety (I am extremely shy myself) outside your first or maybe second interview.
Languages like C that have a single official for loop syntax are a bit easier to remember, in part because it's a syntax I have previously used on a whiteboard rather than exclusively in actual code.
So if a candidate can't write a loop on a whiteboard, maybe let them try in a non-IDE text editor, or have them glance at a formal grammar for the language as a refresher that won't give away the game to someone who can't actually code.
And if I start showing them an EBNF grammar for the language, now that's TWO languages that you will show you don't remember rather than one. I find this even more absurd; you don't remember anything of the syntax of the language you used at work for years, but you think you can rediscover it from the FORMAL language specification in a whiteboard?
This is it, in a nutshell.
In all my years of interviewing candidates, I've never run into the mythical experienced developer who doesn't know anything about programming. Yet according to HN lore, there are hordes of them out there.
My theory is that the only thing there are indeed hordes of, is experienced developers who can be made to look dumb by subjecting them to whiteboard puzzles, algorithm trivia and other such questions which are completely unrelated to the job performance.
It's too true. A quick search found the source article that I read years ago here[0]. :)
From that page:
> We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them).
But the article doesn't even talk about the environment, which is what it's all about.
It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think".
Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part.
Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions.
So the "them" is actually all of us.
To me that is the key takeaway of FizzBuzz.
Of course the tests are proxies and often aren't even scored objectively. And most tests aren't very good at proxying anything general (hence companies' tendencies to have several). There's a lot of problems that remain, our industry doesn't take hiring seriously. But testing and trying to test as early as possible have come to dominate for not totally unreasonable reasons, and persist at the large companies despite the well-known negative trade-offs. It's a startup's/small company's advantage to not copy bigco's interview processes.
Why? IMO this is about an order of magnitude too many. I typically interview about 3-4 people, on rare occasions a few more. I've been interviewing candidates for about 25 years now.
If your recruiter is sending you 50+ mismatched resumes for a role, get a better recruiter. But even in that case, you should notice and weed these out while reviewing the resumes yourself, before getting to the interview stage.
I literally cannot imagine any scenario where I'd interview over 50 people for a role. Or even ten people.
A few startups ago we had to grow the team from 20 people to ~120 in a year. Your approach would result in interviewing well over 5000 people in a year. That would be over 20 people a day, every single day, zero work getting done meanwhile! I suggest a re-think of your hiring strategy.
> being obviously unfit after the first 10 minutes of a technical interview
Which one is more likely:
1. Senior people who have built many successful products don't actually know how to do what they've done.
or
2. Interview techniques that focus on skills unrelated to the job (e.g. whiteboard puzzles, algorithm trivial pursuit) have an inordinately high false negative rate.
I ask because 50 is not completely unreasonable. I've had positions where we've had to interview dozens of candidates, in our small company. In larger companies, often someone else does some initial interviews though and that filters out candidates who e.g. can't code at all (sometimes - not always!).
Like I said, I think if you have to interview that many, your filtering process is really broken further up the pipeline. You don’t know what you want, what the job really is, the or application process isn’t properly structured.
Interviewing large numbers of people is also a huge liability unless you’re extremely consistent and well-documented in your hiring process (something which I’ve found to rarely be the case).
I interviewed at Google. The position description versus what I was interviewed on were two worlds apart. Like the position mentioned front end CSS and HTML. I was grilled on SQL in two of the 4 interviews. This wasn't a SWE position, it was more of a client support role, but I was given a coding test. I did poorly on the test, but I still consider it difficult for a role that was not a SWE.
It didn't even seem like Google knew what role they were hiring for they just wanted "someone technical" to do something. I left this process feeling pretty confused and turned-off at their hiring process and questioning if I really wanted to work at a place like that.
Let me clarify first that 50 interviews include phone screening, where we don't do specific technical questions but rather just poke around what the candidate is looking for and whether they seem able to explain what they have been doing without drowning.
As for the process we use, we are a hedge fund of 30 people, we have no HR, so I directly deal with head hunters. That means the numbers I gave are "raw".
I see a lot of comments arguing whether it's even possible to assess technical skills during an interview, and overall spitting on whiteboard brain teasers.
For the former, really, you need to be in the front row of hiring to understand it. I'm not talking about filtering candidates that can answer library specific trivia or solve red black tree removal on a white board here. I'm talking about senior Python developers that cannot remember the syntax of a for loop, data science specialists that cannot ELI5 the intuition of a linear regression. That's the degree of "low skill level" I'm talking about. I think a lot of people here are biased toward thinking the average programmer on the market should be the same skill level of their average colleague.
This is Wrong.
You are reading hacker news, you are very likely to be passioned and dedicated about what you are doing, you are most likely working in an above average company, surrounded with above average colleagues. Your perception of the average programmer is biased toward your own surroundings.
Now I see that the whiteboard interview seems to be really dreaded. And man, do I feel you. I also used to hate them as an interviewee. But that does not mean they are all the same.
When I do a whiteboard interview, I am perfectly aware that the candidate is obviously stressed, uncomfortable, and not at 100% of his potential. That's why the questions I ask are typically not too intellectually challenging. Some variations of the fizzbuzz mainly, along with a small exercice on recursivity in case the fizzbuzz is too easy.
"Whiteboard interview" should not become a strawman for "24yo fresh grad throws B-tree inversion at you to feel superior". Really, the only thing that should be tested in these interviews is your programmer muscle memory. And from my experience, it does work.
I would think that any "straight to the point" hiring process would be "straight to the point" because it avoided the technical interview process:
A) there's not much you can do to entirely avoid problems with work performance and B) technical knowledge can only be sussed out so far in an interview, period, before actual work performance in the context you're hiring the person for can be evaluated.
You can guess where that ended. In case you can't: "Who did I think I was to refuse their offer to come to America to partake in this great opportunity?".
Interesting attitude change, turning on a dime they went from all smooth and friendly to outright hostile, and that on a track that they initiated. Very weird.
The follow up is usually "Why do you want to leave your current company?" replying with "I'm not, your recruiter said this was a cool place".
"Why do you want to sell me this apple?"
"Be... cause... I grow apples? To sell? And you said you want one, and are holding money?"
This was at the end of the process, after I'd already interviewed with all the technical folks and all the managers and they all wanted to hire me.
Apparently the desired answer was "no." My actual answer was something like "WTF are you talking about," and I somehow managed to get hired anyway. I later heard that if I'd answered "yes" it would have been difficult to overrule HR and get me hired. LOL
(FWIW, I am also a senior engineer, and I have seen this play out from both sides of the table.)
Sometimes folks overestimate their value as senior engineer for certain types of companies, and under-appreciate the risk companies take in hiring an employee. Large companies, for example, generally do not need yet another L6+ that cannot get their hands dirty. They usually have plenty of folks that fit that role already. Additionally, senior engineers are expected to mentor junior engineers, and doing so often requires whiteboard technical skills.
I cannot tell you the number of L6/L7/L8 interviews I've done where it was clear the person had no idea how to write simple algorithms, or put together a basic design. They may be great (or not) at the job they have been doing for years, but that sort of information is not accessible to the interviewing company. If the skills existed, it is a red flag if the candidate let them languish. Or perhaps those skills never existed, and that's a very large risk the company ($100,000s/year) is taking, especially for companies (cough FANG cough) that have a "you must be smart if you made it here" attitude around letting people go.
If one agrees to interview somewhere, it should come with the understanding that it is a mutual exchange. The company is not doing the interviewee a favor, and the interviewee is are not doing the company a favor. Both sides are expending work, which involves some tradeoffs and annoyances. As an interviewer, throwing in a technical question early is an easy sorting check to make early in the interview process before it gets into the nuanced details around role fit.
Of course people in these positions don't code, they couldn't be further away from developers. It's fine that FAANG want heads who can code AND run a department but it shouldn't come as a surprise that candidates don't match that.
That's precisely the sort of things I hire for and I have mixed feeling about that :)
First, infrastructure has a bazillion technical things to deal with between OS, systems, architecture, networking, hardware. Most of these are not even expected from software engineers so it seems disingenuous to make them a hard requirement for a management/lead position.
Second, it's irrelevant to the job. Senior candidates will be mentoring younger developers, developing the team and the department, coordinating and working with other teams (potentially hostile), taking architecture decisions a thousand step above coding a loop, handling hiring and promotions, taking care of budgets and schedules, etc... they should be evaluated on that.
People can't be perfect on technical aspects and soft skills and management. That's an impossible high bar.
After seeing tens of candidates, some of whom would certainly have done the job just fine, yet all got rejected for one minor thing or another. I have mixed feelings about the interview process. Yes, being rusty on algorithms should not be a blocker for some roles.
And, to be honest, as a well paid senior engineer my time is pretty valuable. Doing a skills test and then finding that the job is not of interest to me is pretty frustrating.
I do technical interviews for other teams within my company. I may not know much detail about the role, beyond just generally knowing with the team in question is responsible for and the topics they asked me to cover during the interview. I wouldn't ever think to ask for more details about the role because I assume that's a question for the manager or internal recruiter.
I honestly see it as a way to streamline the interview process and make it more fair. My role in the process is to determine how well you understand the core concepts of a handful of technologies, not to necessarily to sell you on the position or evaluate "culture fit." Of course, I try to be pleasant and want you to come away with a good experience. But sticking to the script is largely me being mindful of everyone's time; interviews are time-consuming and you probably don't want to be answering / asking the same questions to four different people.
The process for new grads and interns should be different from senior talent.
I don't care about the division of labour. Want to hire people away from Google? Don't be a pain in the ass. People expect pain in the interview process, but not before they are sold on the company.
So like I said, what I get from this is on the whole there's an aggregate trend away from wanting experience.
I think it's a worrying sign that the market may be either saturated with talent, and/or that companies are totally fine hiring only junior/mid-level "framework" developers.
Why would you want to work for a company which has such a hard time recruiting and retaining senior talent that they need to pander to them?
For 99.9% of the companies this is not the case.
For example I like working at my current employer and enjoy the challenges compared to earlier employments. But looking at the job postings, I can't see that. It's generic crap about competitive compensation, challenging problems, modern technologies, a flat organization, etc.
If this job posting landed in my mailbox I would skip it. The only reason I applied for this job is because I was jobless and desperate at that time.
But I see recruiting as a team effort. The recruiter should sell you on the company, the manager should sell you on the job, and I should sell you on the quality of the team. If companies aren't meeting your expectations, you should let everyone in the process know.
I'm sure lots of technical employees have no idea what the recruitment process is like at a company, especially if they've been there for a long time.
I understand that you are highly compensated and may not want to spend time trying out for a new job when you already make so much money, but from my perspective: I have a team of highly compensated individuals who are evaluating a candidate for potential hire and I don't want to waste all of their time if the candidate can't even write a simple algorithm to rearrange the characters in a string.
Since it sounds like you're pretty happy where you're at you have the freedom to choose to participate or not. I am guessing that the only way to pull away a candidate like you is by referral anyway, so I am guessing there's not actually a problem here.
If I am getting someone via referral, then interviews can focus on what you find valuable - I can sell you on the role, I can ask you personality questions and make sure there is goal alignment. If I have someone to vouch for you. If you're a stranger? You better believe you gotta write some code.
I think that if you take a step back and ask yourself if you'd really like to work at a place where they hire people who they haven't seen code, you'd probably rather choose to just write some code for 30 minutes in an interview.
Further there's also a question of what kinds of questions, and how the question is asked, but that is a separate topic.
In any case, as a tangent: Most of the questions asked in these interviews have little to do with the day to day tasks of software engineers. So I'm not sure they give much insight into the performance of software engineers doing software engineering. But they do give preference to the skills obtained in CS algorithms courses, so there is an intrinsic bias towards hiring new grads.
There's lots of debate on what kind of coding questions to ask. My questions are more fizz-buzz and less CS textbook. You'd be amazed how many people apply for senior level software engineer roles who can't demonstrate basic programming skills.
I've also been turned down for telling someone XML wasn't something people needed to really "know" to work with. The stack bias and navel-gazing of recruiters in their vainglorious attempts to prove that what they're doing is useful has reached peak.
Given a 32-bit unsigned integer, return true if the binary representation has two consecutive ones in it.
And...that's it. And people that have passed the recruiter gates and made it through the phone screen just completely lose it here. Let's be clear - I really don't care how you do it. There are 3-4 ways right off the bat ranging from a state machine to a shifting mask all the way down to a single inline math statement.
If you're as comfortable as you say, it will be a no brainer. As a check I took an intern and told him to meet me in a conference room to get the same stress level out of him. I posed the problem and got an answer in five seconds.
Now let me tell you about the candidate that wanted to turn the integer into a character string and then search the string for “11”...
After years of asking the same questions to intern candidates and to senior+ candidates, interns did consistently better. There are a lot of "experienced" but not very skilled people out there. They exist already inside ompanies too (Principle level checking in hundreds of lines of code with many classes and tests, purportedly to add logging support to something, but the code was ultimately a NOP as it did nothing) but even if it's impossible to put out the tire fire it's best not to contribute to it.
However I understand that may be part of the discussion afterwards.
Fizzbuzz wasn't designed to test people's prowess in coding. It was designed as "This is one of the simplest possible programs one can write. Can this candidate do it?" While many people may go through their whole career not dealing with dynamic programming or most data structures, almost all programming is fairly similar to FizzBuzz.
As an analogy, it's like giving someone who claims to be a circuit designer a basic circuit where he's failing at Ohm's Laws or Kirchoff's Theorems. Or an electromagnetics person who cannot integrate a basic polynomial.
If you have test anxiety that's one thing, but if your reason is "I need time to think this through", it's a huge red flag. Kind of like the person saying he needs to consult a table of integrals to integrate x^2.
I'm against intense Facebook/Google style whiteboarding. Fizzbuzz is at the extreme other end of intensity.
Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates:
- candidates who are (currently) unfit for any programming job
- candidates who freeze up during the interview
- candidates who have never used the mod operator
A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator".
edit: Oooh! "How many ways can you implement multiplication" would be a much more interesting warm-up/weed-out question! Allows the quality candidates lots of room to shine.
> A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator".
While possibly a fair question, this is a whole order of magnitude more difficult than FizzBuzz. It requires more domain knowledge as well (lots of people have forgotten how to multiply).
> Allows the quality candidates lots of room to shine.
But this is precisely the opposite of FizzBuzz. The goal is to weed out horrible candidates, not identify great ones.
Sorry, in my mind the input was restricted to positive integers. My fault for not making that clear.
def mul(a, b):
accum = 0
while b > 0:
accum = accum + a
b -= 1
return accum
> But this is precisely the opposite of FizzBuzz. The goal is to weed out horrible candidates, not identify great ones.
This accomplishes both at once. That's a super set, not an opposite.
Granted, that may be counter to the spirit of the question, but it's a valid answer lol
I'll give an easy question, but I'll have them do it ssh'd on to a remote machine. I'm more interested if they know how the environment works and how much coaching they need to navigate around.
But I'd probably want to, just to piss off this person (the throwaway account who came on here to argue...)
I haven't been a professional developer for anywhere near 25 years, but I could write fizzbuzz while blindfolded, on a wet bar napkin after a couple of drinks, in any one of at least half a dozen languages.
If someone asked you to write down the answer to 3+5 would you struggle with that as well? To me, fizzbuzz is barely a set up in terms of complexity.
Every senior engineer I've worked with including myself is able to write a for loop with a few lines of code in the body, because doing basic coding like this is important when training new grads and doing code review (not to mention when writing your own code).
That's an extraordinarily simple coding problem, and the usual ones you have to pass to get into Google are much harder.
Getting the job @ Google was worth that stress. The original comment I made was to the effect of: before you dump a coding test on me, you better make sure it's worth the stress by convincing me why.
Programming is not sports. I'm not a coding athlete. Maybe it is for some people, but not for me. That's not what the job I've held for all this time has ever been about.
Plus you get to a certain age and experience and the thought of "proving myself" to some 25 year old is just... Really?
If you just don't like hand writing and prefer typing, then that's cool with me and you can just do that during the interview (the content of interview is important, not the medium you write with).
If you're mentoring a 25 year old you'll have to prove yourself to them every day.
No, you won't. If they don't want to listen to you, they don't have to. As a mentor it's my job to listen to them and guide them with experience as my context, not joust with them over irrelevant, stupid, gotcha contests. And I'm happy to help them realize that just by not engaging in it.
Not sure if you are trolling.
``` case $input when $input % 3 == 0: “Fizz” when $input % 5 == 0: “Buzz” when ($input % 3 == 0 && $input % 5 == 0): “Fizzbuzz” end ```
It's quite ironic that you had all the time in the world to check your code and the ability to silently walk away when the pressure would've been too high and yet you included 2 obvious bugs in your 'proof' of how easy this is.
Thank you for your time, but I'm afraid you would not be a good match for this position at this moment.
I agree though, if the company isn't willing to let you talk to them about the role and requirements upfront, then I don't think you're being actively recruited for your talent and background, and the recruiter is just looking to meet quotas.
After a while you can get a feel for whether you're going to get anything out of the interview process other than a black hole (and probably lowball) offer and just abort the whole process before it starts. There's no point jumping blind from a good position into the unknown, especially given all the ??? are a bad omen.
I recently broke my own code at an interview and was rewarded with complete nonsense. Never again.
The FAANGs practically (sometimes, actually) give you a study guide, at least. Lots of smaller places act like knowing anything more than the names and titles of the people you'll be talking to would be cheating or something. I'm not gonna burn half a day or more just to bomb a question about graph traversal I haven't brushed up on lately, and I'm not gonna study everything unless I'm shooting for FAANG. Tell me what to expect, a few days out, with decent detail, or I'm not interviewing. I don't need to know exact questions but "first thing in the morning we'll ask you to do something with very basic data structures, like one of [short list of possibilities], and it will be on a whiteboard".
Then if you tell me the day is packed with 6+ hours of whiteboard problems I know not to bother, because I'll definitely be tired AF and bombing them after hour 3 no matter how much I study, because I'm not built to literally perform in front of people for hours on end. It saves us both some time.
The study guide is hundreds (thousands?) of pages. How is that helpful?
But frankly most shops out there are not worth it, but if they are, let's talk about how. Many very smart people I know would willingly leave their high-salaried FAANG job for a more rewarding or interesting job even with a steep compensation cut -- and there are many places that would benefit from that talent -- they just need to learn how to recruit it.
I've been on the other side of this process where the "solution" to a technical case study is flat out wrong, but most of the people training to do the interview didn't realize this to the point where the most skilled candidates would likely (and luckily for them) fail the interview by giving the correct answer!
This means that for many interviews at these wannabe-FAANG companies, if you really know your shit, you often have to proactively guess what the interviewer thinks is the correct answer.
There's a huge surplus of people claiming skills they don't have. You'd be shocked at how many people who claim to be strong data scientists don't know SQL.
When I last hired for a technical position, I had half an hour for each candidate to decide whether to move forward with them. I wrote up seven questions that took fifteen minutes to answer. I also spent fifteen minutes talking about the job, the co-workers, and answering questions about the fit of the position.
There is no shortage of labor in the market, and I would say that has been the case for the past 10 years and it has been progressively accumulating a glut. I can ask a senior programmer to complete a multi hour at home task after a brief call, and they will expect nothing in return. When I DJed at strip clubs, I would be payed to try out. Both have similar situations of a position staying open for months on end, large pools of people applying, and the need for selecting a candidate based on skill. The difference is incentive from the other DJs to fill in a Tuesday shift is way higher than a team to sign off on a DevOps engineer. Other people just aren't directly impacted by your marginal value and the selection process is going be for other qualities that are. As for the company's perspective, these engineers still cumulatively provide tremendous value and everything is stilling humming along more or less fine.
Agreed, I'm totally confused and put off by this as well.
Those 24 year old interviewers are the ones you'll have to train, so you need to, at minimum, be able to do their jobs.
I've seen this many times and I find it baffling: I already have a very high paying high quality job, I want you to sell _me_ on the position before demanding I do stressful work to prove myself to you.
The vibe I get from that is: they're not interested in senior or experienced talent. What they want is new grads. So I just tell them I am not interested. Either that or the hiring market isn't nearly as tight as people claim. There must be a surplus of talent if companies can get away with this.
I don't like whiteboard coding exercises, but would be willing to do them for the right position. We need to see if this is the right position for me/them before we proceed to that phase. That means that that process comes as one of the last steps, before an offer. If they're not willing to do that, I just politely decline.