34 ms·

Young whippersnappers are going to downvote me for sharing, but I'm on the other side of the divide and have had to interview and be interviewed a lot over the

Young whippersnappers are going to downvote me for sharing, but I'm on the other side of the divide and have had to interview and be interviewed a lot over the years. The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program. The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz. My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing! The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists. The good news is there are interviewers like me who have been lucky enough to be in the position to hire people on the strength of them being able to work through things in pseudo code even though they are not familiar with any programming languages. I keep interviewing and hiring physics grads on the strength of their excellent problem solving skills, and they all learn to express that in programming languages in short order once they are hired and they have found employment as a programmer...

jahller 5y ago
on top of that you will also filter out applicants who show some red flags when they not immediately know the answer to a problem. it's absolutely okay to not know everything. but there is a huge difference in how people communicate their lack of knowledge.
raverbashing 5y ago
If you're incapable of finding out who "gets it" without asking about fizzbuzz (which I'll point blank refuse to answer) or recursion/sorting, you're failing at interviewing. By the way feel free to try to write a sorting algo (preferably not bubblesort) by memory in your favourite language. It will be a good reality check. > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team Yes, you don't. But you don't need to ask them that directly, or have them code live.
- attil-io 5y ago
  So what do you suggest instead?
- anonymoushn 5y ago
  I got a working merge sort. I think this question is harder than the "can you code" type questions that I'm used to asking when interviewing at companies, but easier than the questions I get at companies (e.g. write me a thread-safe hash map)
- wirrbel 5y ago
  >> My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team > Yes, you don't. But you don't need to ask them that directly, or have them code live. How will you know if you don't ask them a question that asks them to solve a small-scale problem that can be solved via a for loop? In our process it takes like 10 minutes. Granted we don't ask fizz buzz, but also we don't ask for implementations of textbook algorithm. Just a simple programming problem or two. The way I see it is, the most condescending interview for a programmer is the one that contains no coding at all. And if you refuse to implement FizzBuzz, well, that is okay, but I will not recommend you for being hired.
  - raverbashing 5y ago
    > to solve a small-scale problem that can be solved via a for loop? Why do you need to ask them specifically to code fizzbuzz? There's nothing magical about it and it's a condescending coding exercise. Ask stuff about their everyday coding and their favourite language. What's the difference between an Array and a Set (in your language of choice). How do you add an element to those? (if it's your day to day language you should remember, right?) Tell me about an issue you had to debug. Tell me how (something) works in general. Something basic, no need to go into much detail, but just to see if they get the basic idea and have used it. Again, who cares about fizzbuzz when you can ask them about http headers, network delays, etc (it will be more job relevant as well). People who can't code fizzbuzz will usually fall flat on those questions as well.
a_c 5y ago
I am on the other side of the table too. I also design the interview process. The things I look in an interview - the ability to code with quality - the ability to learn and grow - track record to deliver business value In my experience, people are wasting too much resources on interviewing. And the process is never meant for more senior positions. Engineers don't like it, and the outcome cannot be falsified (what if we hire someone with a light weight process, would it turn out worse?) I am saying specifically about interviewing, as opposed to hiring in broader sense. What you want is a process that evolve with your demand/available resource, not hardcoding of 2 sessions of coding (oh and with shadowing, so to grow interview skills of the team, of course!), 1 session of architectural design, 1 experience deep dive, whatever. Is this topic something people are interested in though? I might try to write up the thinking behind our process
- CraigJPerry 5y ago
  These are just 3 arbitrary points. E.g. I’m pretty certain you’re not advocating for hiring developers who can’t have a civilised disagreement, yet you don’t list anything about collaboration or communication or ability to put team before self in pursuit of a common goal. Hiring well is hard to do fairly and accurately. There’s no pithy shortcut that can be wrapped up in a blog post. About the best I’ve managed to go in 15 years of hiring is recognise that i have biases and recognise that I’m not always that good at seeing my biases.
  - a_c 5y ago
    Agreed those are arbitrary point. And so is every hiring process. Pick some attributes that helps you define good people, good business, good tech and that's it. At the end of the day, it is a subjective process. I bet whatever "objective metrics" we come up at the end has some "rating" element in it which is subjective. Acknowledge the arbitrariness within the team and to the candidate in my opinion helps bring more fairness to the table. And also why I think it is worth less to overly religious over the hiring process
- loup-vaillant 5y ago
  > track record to deliver business value A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line. That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.
lexapro 5y ago
>The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program. It's perfectly possible to be a 10x engineer but not being able to solve some obscure recursion problem on a whiteboard. All it does is forcing candidates to study obscure problems before the interview and hope they get lucky and receive a problem that they have memorized so they can pretend to have never seen it.
- estomagordo 5y ago
  Or, you know, they're smart problem solvers and don't need to rely on memorizing.
  - michaelscott 5y ago
    Is that what you really end up testing though? As parent mentioned this can be broken by simply memorising, so are you sure the candidate is a good problem solver or are they just good parrots?
    - thinkharderdev 5y ago
      So I think it's actually evolved into a weird sort of test of conscientiousness. Originally the idea was probably that we will test people's abstract problem solving skills. Can they come up with a solution on the fly? Ok, now can they figure out any clever optimizations? But at this point it is sort of expected that if you are interviewing with a FAANG you will be getting these sorts of questions (and they tell you that up front), so it becomes a sort of test of "is this person willing to spend 10 hours preparing for an interview"?
      - michaelscott 5y ago
        Yeah I suspect this is the case, the original intention and structure was solid but it's been progressively shifted into that FAANG space. I think the only solution is probably a question tailor made to the company interviewing, that doesn't rely on leetcode-style approaches to solve.
dgb23 5y ago
I agree with your general sentiment and I think algorithmic questions are fine. But it seems to me that the common type of questions are very non-typical for every day problem solving and programming. For example I as a full stack web dev, never write sorting, very rarely search / string or scheduling and so on. However I happen to like puzzles and coding challenges, so I do them fairly regularly on a Sunday. Do people want to select based on hobbies? Actually tricky stuff (tricky as in I have to think more deeply and do actual design) I have to do includes for example: - caching and synchronization - concurrency/asynchronicity issues - deep SQL queries - schema (DB/API/UI) design - tree/graph traversal - refactoring and code design - breaking down (deeply coupled or complex) features into sensible tasks - (declarative) state machines - asking the right questions about an unfamiliar domain and deriving the right abstractions and data structures - error handling, invariants, correctness... Those apparently rarely come up in the types of questions that for example leetcode et al suggest. It's typically "A&D with a twist".
- marcus_holmes 5y ago
  I've been working through HackerRank, LeetCode, etc - they have nothing to do with actual software development. And most of them rely on knowing some obscure algorithm or "trick" to solve, which you wouldn't do in real life - you'd Google the problem, possibly add a dependency, and be about your business. But I've also been in technical interviews where the problem was used as a discussion point, rather than a challenge, and I get that use case - though "let's build a web server" might be a better problem to solve collaboratively.
  - VirusNewbie 5y ago
    Interesting, I'd say 80% of the 'easy' level questions are very relevant to understanding data structures one encounters on a day to day basis (maps, trees, lists, arrays) and basic ability to manipulate those with loops or recursion. I think those are very good interview questions. I'd also say 90% of medium and hard questions are exactly what you said, relying on a relatively obscure algorithm.
indigochill 5y ago
> they are to filter out people who simply can't program. The problem is they also filter out people who get nervous during tests. I'm someone who marginally failed a programming test and am now one of the most in-demand developers at my company (where I failed the test). The tech director who rejected my failed test has since told me not hiring me to his team at that time was one of the biggest mistakes of his career and I've also heard he's stopped being a believer in programming tests because of my application. I've also been involved in hiring decisions and I've hired people who have bombed programming tests (and in ways where it was clear they just didn't grok the logic they should have). They've also been perfectly fine contributors, because our test questions required knowledge that wasn't going to be relevant (a CRUD-gluer doesn't really need to be proficient with geometry). I still believe programming tests are useful, though. In the hiring I've done, it has been one factor to discuss during the interview. We always give developers a take-home test and then discuss the results in the interview. If they messed up, we illustrate where their solution is wrong and see if they're able to reason through the problem. If they didn't mess up, hey, that's a great sign. If we can see them really start re-reasoning through the problem, that's a good sign that they (a) don't take programming failure personally and (b) are the sort of person who will re-evaluate what they think they know. On the other hand, if they just throw up their hands and give up without really giving the problem any extra effort, that's a bad sign. Our reasoning for this approach is that everyone writes bugs, but nobody gets to give up when fixing bugs. As an aside, we've never tested someone who just couldn't write a for loop at all, so it's possible our hiring pool is different and so our needs/solutions are different. And for context, the take-home test questions we use (they're always the same and they're not a secret) are: 1. Given a rectangle and a point, write a function to determine if the point is within a certain distance of the rectangle. 2. Given a string, write a function that determines if any permutation is a palindrome (this one's for the over-engineers who don't first think through the problem) 3. Write a CLI dice game where the computer cheats to maintain around a 70% win rate (there are some basic rules for scoring I'm leaving out for space - this one people rarely get totally wrong, but talking about why they picked a particular cheating mechanism can be enlightening).
- estomagordo 5y ago
  Sounds like fun!
ChrisMarshallNY 5y ago
Fizzbuzz is one thing. Balancing binary trees, is another. I've learned that if I see a binary tree question, I might as well stop the process, as they have no intentions of hiring me. They want someone fresh out of college, and I'm really just an EEOC checkmark. I've said it many, many times, here. If a candidate has a portfolio, you'd be absolute idiots to ignore that portfolio. Or deliberately ignorant, as the decision has already been made, not to hire the candidate (for reasons that have nothing at all to do with their tech abilities), and no one wants to waste time, reviewing a portfolio. I'm biased, here, of course, as that's my strength. I have a fairly substantial portfolio. A portfolio makes it much easier to evaluate real world skills and capabilities. If a candidate sends a link to a sample project or OSS product they've worked on/developed, it's not particularly difficult to review the example, and then ask the candidate a bunch of questions about it. I've found that the conversations that arise from this kind of thing can be amazing. But this won't work for managers that have a hundred résumés on their desk, and have maybe five minutes per candidate. As that was never my own experience, as a hiring manager, I can't speak to it. I rarely had candidates that had significant portfolios, and treasured the ones that did. In my experience, it usually took about two minutes of casual conversation, to figure out if the candidate had potential, or was simply a jargonaut.
- ravenstine 5y ago
  I find it astonishing how I often I've been asked about binary trees and binary search trees in web developer interviews. In all my time, I've come across some circumstances where some concepts like state machines were helpful, but have yet to run into a time where I needed to understand or write a binary tree. At first I felt ashamed, but over time the feeling flipped and I felt bad for the interviewer asking such a non-applicable question as for them to look rather foolish. It's like asking a biologist to describe the Dirac equation. Fortunately I've yet to run into this once I spent enough time as a mid-level developer and became senior. If it's any ray of hope for younger developers out there, you will get to a point where you basically bypass all that crap and interviews can be more like a friendly chat between peers.
  - ChrisMarshallNY 5y ago
mettamage 5y ago
> The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz. > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing! Your comment shows that this topic has a false assumption. There is not one type of hiring process. Not even when we talk about algorithm/data structure style coding interviews. How do I know? Because if you don't know how to do a topological sort and similar algorithms on that level, you stand no chance at FAANG interviews. I remember the time where I found fizzbuzz doable but difficult. I could do it, I was simply slow at it. When I prepped myself for a FAANG interview, I did fizzbuzz at the end of it for fun since I hadn't done it in years. The result: fizzbuzz was done very very quickly and I'd classify it as a Leetcode easy. The thing is, Leetcode hard is a different beast [1]. Therefore, I'd argue it's also a different hiring process. [1] Here is how I look at the Leetcode difficulty levels (the TL;DR version). Leetcode easy: can you write a for loop? Do you know what a function is? What about if-statements and variables? Leetcode medium: can you reasonably think about data structures and write it out in code? Leetcode hard: do you see the ingenious trick (or tricks) being employed? Do you have advanced knowledge of data structures? If so, congratulations! The hard part is over. You just need to code it out. Example: you need to know this type of stuff: https://www.youtube.com/watch?v=cIBFEhD77b4 https://www.youtube.com/watch?v=cIBFEhD77b4 <-- It's a good YT channel by the way. After his video series/lectures on graphs, I was able to solve 50% Leetcode hard on graph problems :)
game_the0ry 5y ago
> The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists. No downvotes from me, friend. I get what you are saying, but I wish my tech interviews ludicrously simple. They tend to be the opposite, and it seems to be worse when you are a front end UI engineer. Not only do I need to be up to date on the new new javascript hotness, I need to be able design twitter's back end architecture and implement min / max heaps on the spot on a white board (now in coder pad, hacker rank or, even worse, google doc) in about 20 mins or less. That's asking a lot.
- _jesseb 5y ago
  Been interviewing lately for front end positions, it's rough. It's leetcode questions that touch on things I don't do that much when building UIs (or ever do, like why would I implement a sort ever? I don't even use the built in sort array method that often) and very specific questions about whatever front end framework they're using, so if it's not your daily driver at the moment then good luck.
cryptica 5y ago
Most of these live programing exercises are far too demanding when you consider the stressful environment and the time pressure that candidates are under. It selects for a certain kind of fresh-out-of-uni candidate who has been solving puzzles every week as part of their assessments. Once you've been out of university for almost a decade, some things fade from memory and you need more time to solve those puzzles because you can't rely on your 'muscle memory' like a recent graduate can. These puzzles say nothing about a candidate's problem solving ability, they're just monkey tricks that can be rehearsed. Who is smarter; a candidate who can solve a Rubik's Cube after seeing it for the first time or someone who has rehearsed it hundreds of time and knows the algorithms? It's not even fair to compare these two people, the former is unequivocally a very intelligent person and the latter could potentially still be an idiot... This is true even if the second person could solve it in one tenth of the time in front of an audience while blindfolded and riding a unicycle across a plank suspended in mid-air above crocodile-infested waters. And this barely scratches the surface of what's wrong with tech companies' hiring processes. This puzzle-solving ability is overvalued and the ability to design/architect good systems (I.e. seeing the big picture and using common sense) is extremely undervalued.
pc86 5y ago
My comments here are relevant only to my hiring experience, which is decidedly un-FAANG: small companies you've never heard of, teams of 3-5 on average but always less than a dozen or so, for the entire company. But I have a lot of problems with using any programming tasks in an interview. My biggest problem is that it doesn't have any correlation to the actual job. Coding on a white board, under stress, with multiple tech and non-tech people watching you, with a sub-30 minute time cap, with no access to the internet or debugging tools other than an interviewer who may or may not just be trying to look smart to the other people in the room, is almost entirely the opposite of what an SDE does day-to-day. I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it. Solving programming "puzzles" is completely different than day-to-day work, especially at small non-startup shops, where you're doing line-of-business stuff and maybe a new project every 5 years. It's maintenance 99% of the time. You don't need to know how to reverse strings to implement a recursive sliding window function. This is how we've done hiring at my current company so far and it's worked out better than any of the places I've been that used puzzles or language trivia. 1. As always, lean on your network. 1st- and 2nd-level connections will already have a lot of previous vetting completed. 2. Interview primarily for team fit. You can teach people technical details easily if they're otherwise qualified. You can't teach someone not to be an asshole, and having an asshole on the team will drive away good people who don't want to deal with it. 3. Have a very clearly communicated probationary period. We use 30 days but honestly 2-3 weeks is plenty. If things aren't working out, cut them in this period. 4. As part of #3, check in a lot more than you otherwise would during this time. We do a management one-on-one every two weeks, so we'll do daily technical one-on-ones during the first week or two of onboarding. We've let one person go during the probationary period because of performance and without these meetings it would've taken weeks longer than it did. 5. Have onboarding. Docs, calls with a defined itinerary, whatever. But don't just drop people into the thick of it if you're doing this type of interviewing. 6. Actually request references and talk to them. You'd be surprised how candid former managers will be about someone's previous performance, even when they're not supposed to be.
- Aeolun 5y ago
  > You don't need to know how to reverse strings to implement a recursive sliding window function. I guess I generally agree with the sentiment of your post, but if you have issues reversing a string (brute force) I’m not sure how you’d ever get to sliding window functions.
pklausler 5y ago
I find that the best way to expose candidates who can’t actually program is with coding questions that don’t have data structures or even loops in them. Can they write a simple Boolean expression to correctly implement a simple predicate? Too often, no, they can’t. (Example: given two intervals [a,b] and [x,y], are they disjoint or do they overlap?)
- dharmab 5y ago
  On a team I worked on, our technical screening question was, essentially, to implement Python's `dict.get()` function. A surprising number of applicants who passed HR's screen failed at this stage.
  - andrew_ 5y ago
    asking candidates to reimplement stdlib methods is asinine. (unless of course your company is working on python core)
    - dharmab 5y ago
      The exercise wasn't a literal reimplementation, there were some additional constraints rather than a generalized problem, but it was literally 3 or 4 lines of simple if-then statements. And not that it mattered to the purpose of this question, but this team did frequently work with kernel, language runtime and container runtime source code.
    - pklausler 5y ago
      > A surprising number of applicants who passed HR's screen failed at this stage. Perhaps you didn't notice this part of the parent comment.
      - andrew_ 5y ago
        "surprising" indicates that the expectation was the candidates were supposed to be able to perform the task. Perhaps you read some sarcasm into the comment that wasn't explicit?
andrew_ 5y ago
42 years old. I've been in the industry 20 years now. Does that make me a young whippersnapper? I don't know. I can say that I refuse interviews that don't include job-relevant questions. If I'm asked to do work as proof of experience, I refuse any requests that aren't job-relevant. After this many years in the industry, if someone can't take the time to look at my publicly available body of work, call some references (which I always provide access to), then I want nothing to do with them. If your measure of someone's ability equates to fizzbuzz YOU'RE PART OF THE PROBLEM WITH TECH HIRING. The grads probably aren't aware enough to know the difference, being new grads. And I'd wager that's why you're targeting them.
- Bedon292 5y ago
  I don't see fizzbuzz here as the full measure of someone's ability. Its a filter. I have had many candidates make it through phones screens who seem quite capable only to start working through a series of problem solving questions and they cannot do it. People with job history that suggests they should easily be able to. With no specific language requirements (pseudo code is totally fine) and they can't even write a for loop. We ask to see how they approach the problem, not to get a perfect answer. Ask questions about it, talk through your reasoning, work with us on it. Not worried about off by 1 or specific syntax, just getting to know them and how they work through a problem. We tried hiring a few people who didn't perform as well on this, and it was a mistake every time. And anyone who had no problems with it was always a good hire. Now, obviously there is a problem with the screening process when people who can't actually write a for loop get through it, but until that is fixed, you have to filter them out somehow. How have you approached that in the past? I would honestly like to know how to fix it.
devwastaken 5y ago
Knowing the same interview questions doesn't make you competent. That's the problem. By asking questions not related to the work you filter out people who do the work you need, and only accept those who spend time passing interviews. Same as how ACT's filter for test takers, not ability to learn nor domain knowledge. The core problem is these interview questions are asked without knowledge as to why they're doing it. "It's industry standard" isn't a reason, but it's why binary search tree questions still exist. Some people understand that they're filter questions, but overwhelmingly interviewers think they're real problems related to the job.
bgro 5y ago
I'm absolutely terrible at tech interviews, despite being a software engineer and actual architect for around 5-10 years. I constantly fix major security issues in legacy code, optimize it, and work with the senior devs in multiple languages to create new solutions. I've filled the gap as a tech lead, and frequently have to just figure out a new language in days. I naturally learn language nuances, best practices, I'm easy to work with, I know how to implement things and work across teams, technologies and departments. Learning is what I'm great at, not necessarily coding. I have extensive experience leaning towards hacker-like work in addition to software engineering. I'm legitimately, at worst, decent, with the capability to be exceptional in multiple areas. I'm generally a jack of all trades. I go to a tech interrogation and when I ask for clarification on the question, I get an under the breath "jesus christ, I need to explain this to you?" If I don't ask to clarify, I get "Oh, well he didn't ask for more details. I guess he's rushing without thinking! He's bad at communication. Gottem! Next." I can't take a minute to read the question because the interrogator is screaming that I'm not constantly talking. If there's a literal 10 second gap in talking, I get a "Hello? Are you still there? Hello? What are you doing?" You have to memorize the leetcode questions that are always asked so you're able to talk over them. That doesn't demonstrate any skills. When I get to actual coding, I've automatically failed an otherwise perfect whiteboarding session because I had a lowercase letter instead of an uppercase one. "Ha, gottem! He doesn't know the difference between an object and a variable!" I'm not the best at writing code from scratch but I'm decent in a business practice. I'm exceptional at improving code from any skill level, and adopt that quality in my own code naturally. This has 0 value during an interview though. The only thing that matters during interviews is how many of the classic pattern questions you've memorized. All the amazing work I've done is invalidated because I can't instantly write a perfect meme code question. I come on the internet to articles like this for help or to see anyone else who got stuck in my position, and there's always someone like you here. "Wrong. You're not a real engineer because you can't even answer an easy level leetcode question without stumbling on something. I guess you're not a real engineer. You're just a worthless fake person." I've worked with people like you before. I know because I heard this at my last job from dismissive coworkers either bashing interviewees or other people's code they didn't understand (or understand context around, such as a critical hotfix) in PRs. You people submit untested code on Friday at 5 before going camping for the week and I have to come in and hotfix your sloppy work. I can pick up what you wrote, see how awful your coding practice is, but understand what you were thinking and fix it. However, just because you memorized the leetcode questions or can think of simple solutions to puzzle questions naturally, I guess you're automatically better than me and I'm basically a skilless idiot. I try to have a conversation about fixing this or how I might be an unusual edge case and the interviewers are all on my side. I get to the interview and everything I said is dropped. I get a puzzle question in a google docs sheet that tests none of my skills. I understand you need to test if people can code, but all these dismissive gatekeeping methods are slamming me and letting people who just happen to either memorize the questions or they live and breath programming and can weasel through it. Those people, I've noticed, are frequently poorly trained in coding and refuse to change their ways.
glitchc 5y ago
The disconnect is that the questions are not simple. FizzBuzz is great, always worth asking. It’s when people are asked to answer ridiculous questions that gets my goat. One interviewer asked me to develop a lexical parser in a one hour timeframe. This is stupid in the extreme.
- andrew_ 5y ago
  > FizzBuzz is great, always worth asking. Up to what point? Are you going to ask a 20 year veteran of the industry to be performative in order satisfy an entry level screening?
  - glitchc 5y ago
    It depends. If the veteran is responsible for architecture, process, framework, then no. But, if the position requires that veteran to touch code (or read and review it), then a simple question like a "find the largest number" or FizzBuzz completely appropriate. The question basically acts as a safety value at this point. It is especially important to do this if they have not touched code in previous positions over the last 5-7 years. Otherwise, the business runs the risk of this veteran throwing their weight around on the engineering team and mucking up a production codebase two days before the release date, which could cost the company serious time and money depending on contractual obligations.
muh_gradle 5y ago
Everyone's already saying it, but let's be honest. In 2021, fizzbuzz is not what is being tested. We are 15 years past that now.
tsavo 5y ago
Absolutely this. HR groups now use automated tools to search resumes and filter candidates, which has led to a lot of keyword optimization of resumes. Mediocre talents with optimized resumes in up in interviews where I then screen using the most basic questions. And the questions aren't an attempt to be brutal, the questions will be around platforms and coding that they've directly mentioned in their resume. If they can't answer basic questions around things they've listed in their resume, then you know it is puffery.
geebee 5y ago
I'm glad to see I'm not the first or only one to make this point, but I'll reiterate... it isn't fizz buzz. Trust me, I can write fizzbuzz. I can write loops. I can do basic tree traversal. If I study (yet again), I can also whip out DFS, BFS, MergeSort, inorder, postorder, find all permutations of a set or string, blah blah blah. Without study, I could code up DFS and BFS with a bit of time to think. But probably not in 45 min at the whiteboard. If I study a lot (yet again), I might be ready for the kind of questions that have been actually used to screen me out, such was "find all matching subtrees in a binary tree", in 45 minutes, at the whiteboard. The only way I can reconcile my experience with what you claim to be screening for is that I haven't interviewed with you, and you haven't been at my interviews, and we just disagree about what is typical. But I've been on a lot of interviews, and I do firmly believe that "fizz buzz" doesn't come within 50 miles of the difficulty level of a typical technical exam style interview. I refuse to put this kind of time into study anymore, since there is no lasting benefit to reloading 2nd year data structures and algorithms into short term "45 minute whiteboard memory", and it so rarely works out anyway. I won't do a 5 hour, room to room series of technical exams. This may cost me opportunities, but eh, my guess is that I wouldn't have gotten these jobs anyway, so I'm really just saving time. (on a separate note, I recommend you don't start your comment with a pre-emptive dismissal of why people may downvote you. just make your point, reasonable people here will discuss it with you, don't worry about the others).

jahller 5y ago

on top of that you will also filter out applicants who show some red flags when they not immediately know the answer to a problem. it's absolutely okay to not know everything. but there is a huge difference in how people communicate their lack of knowledge.

raverbashing 5y ago

If you're incapable of finding out who "gets it" without asking about fizzbuzz (which I'll point blank refuse to answer) or recursion/sorting, you're failing at interviewing. By the way feel free to try to write a sorting algo (preferably not bubblesort) by memory in your favourite language. It will be a good reality check. > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team Yes, you don't. But you don't need to ask them that directly, or have them code live.

attil-io 5y ago
So what do you suggest instead?
anonymoushn 5y ago
I got a working merge sort. I think this question is harder than the "can you code" type questions that I'm used to asking when interviewing at companies, but easier than the questions I get at companies (e.g. write me a thread-safe hash map)
wirrbel 5y ago
>> My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team > Yes, you don't. But you don't need to ask them that directly, or have them code live. How will you know if you don't ask them a question that asks them to solve a small-scale problem that can be solved via a for loop? In our process it takes like 10 minutes. Granted we don't ask fizz buzz, but also we don't ask for implementations of textbook algorithm. Just a simple programming problem or two. The way I see it is, the most condescending interview for a programmer is the one that contains no coding at all. And if you refuse to implement FizzBuzz, well, that is okay, but I will not recommend you for being hired.
- raverbashing 5y ago
  > to solve a small-scale problem that can be solved via a for loop? Why do you need to ask them specifically to code fizzbuzz? There's nothing magical about it and it's a condescending coding exercise. Ask stuff about their everyday coding and their favourite language. What's the difference between an Array and a Set (in your language of choice). How do you add an element to those? (if it's your day to day language you should remember, right?) Tell me about an issue you had to debug. Tell me how (something) works in general. Something basic, no need to go into much detail, but just to see if they get the basic idea and have used it. Again, who cares about fizzbuzz when you can ask them about http headers, network delays, etc (it will be more job relevant as well). People who can't code fizzbuzz will usually fall flat on those questions as well.

a_c 5y ago

I am on the other side of the table too. I also design the interview process. The things I look in an interview - the ability to code with quality - the ability to learn and grow - track record to deliver business value In my experience, people are wasting too much resources on interviewing. And the process is never meant for more senior positions. Engineers don't like it, and the outcome cannot be falsified (what if we hire someone with a light weight process, would it turn out worse?) I am saying specifically about interviewing, as opposed to hiring in broader sense. What you want is a process that evolve with your demand/available resource, not hardcoding of 2 sessions of coding (oh and with shadowing, so to grow interview skills of the team, of course!), 1 session of architectural design, 1 experience deep dive, whatever. Is this topic something people are interested in though? I might try to write up the thinking behind our process

CraigJPerry 5y ago
These are just 3 arbitrary points. E.g. I’m pretty certain you’re not advocating for hiring developers who can’t have a civilised disagreement, yet you don’t list anything about collaboration or communication or ability to put team before self in pursuit of a common goal. Hiring well is hard to do fairly and accurately. There’s no pithy shortcut that can be wrapped up in a blog post. About the best I’ve managed to go in 15 years of hiring is recognise that i have biases and recognise that I’m not always that good at seeing my biases.
- a_c 5y ago
  Agreed those are arbitrary point. And so is every hiring process. Pick some attributes that helps you define good people, good business, good tech and that's it. At the end of the day, it is a subjective process. I bet whatever "objective metrics" we come up at the end has some "rating" element in it which is subjective. Acknowledge the arbitrariness within the team and to the candidate in my opinion helps bring more fairness to the table. And also why I think it is worth less to overly religious over the hiring process
loup-vaillant 5y ago
> track record to deliver business value A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line. That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.

lexapro 5y ago

>The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program. It's perfectly possible to be a 10x engineer but not being able to solve some obscure recursion problem on a whiteboard. All it does is forcing candidates to study obscure problems before the interview and hope they get lucky and receive a problem that they have memorized so they can pretend to have never seen it.

estomagordo 5y ago
Or, you know, they're smart problem solvers and don't need to rely on memorizing.
- michaelscott 5y ago
  Is that what you really end up testing though? As parent mentioned this can be broken by simply memorising, so are you sure the candidate is a good problem solver or are they just good parrots?
  - thinkharderdev 5y ago
    So I think it's actually evolved into a weird sort of test of conscientiousness. Originally the idea was probably that we will test people's abstract problem solving skills. Can they come up with a solution on the fly? Ok, now can they figure out any clever optimizations? But at this point it is sort of expected that if you are interviewing with a FAANG you will be getting these sorts of questions (and they tell you that up front), so it becomes a sort of test of "is this person willing to spend 10 hours preparing for an interview"?
    - michaelscott 5y ago
      Yeah I suspect this is the case, the original intention and structure was solid but it's been progressively shifted into that FAANG space. I think the only solution is probably a question tailor made to the company interviewing, that doesn't rely on leetcode-style approaches to solve.

dgb23 5y ago

I agree with your general sentiment and I think algorithmic questions are fine. But it seems to me that the common type of questions are very non-typical for every day problem solving and programming. For example I as a full stack web dev, never write sorting, very rarely search / string or scheduling and so on. However I happen to like puzzles and coding challenges, so I do them fairly regularly on a Sunday. Do people want to select based on hobbies? Actually tricky stuff (tricky as in I have to think more deeply and do actual design) I have to do includes for example: - caching and synchronization - concurrency/asynchronicity issues - deep SQL queries - schema (DB/API/UI) design - tree/graph traversal - refactoring and code design - breaking down (deeply coupled or complex) features into sensible tasks - (declarative) state machines - asking the right questions about an unfamiliar domain and deriving the right abstractions and data structures - error handling, invariants, correctness... Those apparently rarely come up in the types of questions that for example leetcode et al suggest. It's typically "A&D with a twist".

marcus_holmes 5y ago
I've been working through HackerRank, LeetCode, etc - they have nothing to do with actual software development. And most of them rely on knowing some obscure algorithm or "trick" to solve, which you wouldn't do in real life - you'd Google the problem, possibly add a dependency, and be about your business. But I've also been in technical interviews where the problem was used as a discussion point, rather than a challenge, and I get that use case - though "let's build a web server" might be a better problem to solve collaboratively.
- VirusNewbie 5y ago
  Interesting, I'd say 80% of the 'easy' level questions are very relevant to understanding data structures one encounters on a day to day basis (maps, trees, lists, arrays) and basic ability to manipulate those with loops or recursion. I think those are very good interview questions. I'd also say 90% of medium and hard questions are exactly what you said, relying on a relatively obscure algorithm.

indigochill 5y ago

> they are to filter out people who simply can't program. The problem is they also filter out people who get nervous during tests. I'm someone who marginally failed a programming test and am now one of the most in-demand developers at my company (where I failed the test). The tech director who rejected my failed test has since told me not hiring me to his team at that time was one of the biggest mistakes of his career and I've also heard he's stopped being a believer in programming tests because of my application. I've also been involved in hiring decisions and I've hired people who have bombed programming tests (and in ways where it was clear they just didn't grok the logic they should have). They've also been perfectly fine contributors, because our test questions required knowledge that wasn't going to be relevant (a CRUD-gluer doesn't really need to be proficient with geometry). I still believe programming tests are useful, though. In the hiring I've done, it has been one factor to discuss during the interview. We always give developers a take-home test and then discuss the results in the interview. If they messed up, we illustrate where their solution is wrong and see if they're able to reason through the problem. If they didn't mess up, hey, that's a great sign. If we can see them really start re-reasoning through the problem, that's a good sign that they (a) don't take programming failure personally and (b) are the sort of person who will re-evaluate what they think they know. On the other hand, if they just throw up their hands and give up without really giving the problem any extra effort, that's a bad sign. Our reasoning for this approach is that everyone writes bugs, but nobody gets to give up when fixing bugs. As an aside, we've never tested someone who just couldn't write a for loop at all, so it's possible our hiring pool is different and so our needs/solutions are different. And for context, the take-home test questions we use (they're always the same and they're not a secret) are: 1. Given a rectangle and a point, write a function to determine if the point is within a certain distance of the rectangle. 2. Given a string, write a function that determines if any permutation is a palindrome (this one's for the over-engineers who don't first think through the problem) 3. Write a CLI dice game where the computer cheats to maintain around a 70% win rate (there are some basic rules for scoring I'm leaving out for space - this one people rarely get totally wrong, but talking about why they picked a particular cheating mechanism can be enlightening).

estomagordo 5y ago
Sounds like fun!

ChrisMarshallNY 5y ago

Fizzbuzz is one thing. Balancing binary trees, is another. I've learned that if I see a binary tree question, I might as well stop the process, as they have no intentions of hiring me. They want someone fresh out of college, and I'm really just an EEOC checkmark. I've said it many, many times, here. If a candidate has a portfolio, you'd be absolute idiots to ignore that portfolio. Or deliberately ignorant, as the decision has already been made, not to hire the candidate (for reasons that have nothing at all to do with their tech abilities), and no one wants to waste time, reviewing a portfolio. I'm biased, here, of course, as that's my strength. I have a fairly substantial portfolio. A portfolio makes it much easier to evaluate real world skills and capabilities. If a candidate sends a link to a sample project or OSS product they've worked on/developed, it's not particularly difficult to review the example, and then ask the candidate a bunch of questions about it. I've found that the conversations that arise from this kind of thing can be amazing. But this won't work for managers that have a hundred résumés on their desk, and have maybe five minutes per candidate. As that was never my own experience, as a hiring manager, I can't speak to it. I rarely had candidates that had significant portfolios, and treasured the ones that did. In my experience, it usually took about two minutes of casual conversation, to figure out if the candidate had potential, or was simply a jargonaut.

ravenstine 5y ago
I find it astonishing how I often I've been asked about binary trees and binary search trees in web developer interviews. In all my time, I've come across some circumstances where some concepts like state machines were helpful, but have yet to run into a time where I needed to understand or write a binary tree. At first I felt ashamed, but over time the feeling flipped and I felt bad for the interviewer asking such a non-applicable question as for them to look rather foolish. It's like asking a biologist to describe the Dirac equation. Fortunately I've yet to run into this once I spent enough time as a mid-level developer and became senior. If it's any ray of hope for younger developers out there, you will get to a point where you basically bypass all that crap and interviews can be more like a friendly chat between peers.
- ChrisMarshallNY 5y ago

mettamage 5y ago

> The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz. > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing! Your comment shows that this topic has a false assumption. There is not one type of hiring process. Not even when we talk about algorithm/data structure style coding interviews. How do I know? Because if you don't know how to do a topological sort and similar algorithms on that level, you stand no chance at FAANG interviews. I remember the time where I found fizzbuzz doable but difficult. I could do it, I was simply slow at it. When I prepped myself for a FAANG interview, I did fizzbuzz at the end of it for fun since I hadn't done it in years. The result: fizzbuzz was done very very quickly and I'd classify it as a Leetcode easy. The thing is, Leetcode hard is a different beast [1]. Therefore, I'd argue it's also a different hiring process. [1] Here is how I look at the Leetcode difficulty levels (the TL;DR version). Leetcode easy: can you write a for loop? Do you know what a function is? What about if-statements and variables? Leetcode medium: can you reasonably think about data structures and write it out in code? Leetcode hard: do you see the ingenious trick (or tricks) being employed? Do you have advanced knowledge of data structures? If so, congratulations! The hard part is over. You just need to code it out. Example: you need to know this type of stuff: https://www.youtube.com/watch?v=cIBFEhD77b4 https://www.youtube.com/watch?v=cIBFEhD77b4 <-- It's a good YT channel by the way. After his video series/lectures on graphs, I was able to solve 50% Leetcode hard on graph problems :)

game_the0ry 5y ago

> The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists. No downvotes from me, friend. I get what you are saying, but I wish my tech interviews ludicrously simple. They tend to be the opposite, and it seems to be worse when you are a front end UI engineer. Not only do I need to be up to date on the new new javascript hotness, I need to be able design twitter's back end architecture and implement min / max heaps on the spot on a white board (now in coder pad, hacker rank or, even worse, google doc) in about 20 mins or less. That's asking a lot.

_jesseb 5y ago
Been interviewing lately for front end positions, it's rough. It's leetcode questions that touch on things I don't do that much when building UIs (or ever do, like why would I implement a sort ever? I don't even use the built in sort array method that often) and very specific questions about whatever front end framework they're using, so if it's not your daily driver at the moment then good luck.

cryptica 5y ago

Most of these live programing exercises are far too demanding when you consider the stressful environment and the time pressure that candidates are under. It selects for a certain kind of fresh-out-of-uni candidate who has been solving puzzles every week as part of their assessments. Once you've been out of university for almost a decade, some things fade from memory and you need more time to solve those puzzles because you can't rely on your 'muscle memory' like a recent graduate can. These puzzles say nothing about a candidate's problem solving ability, they're just monkey tricks that can be rehearsed. Who is smarter; a candidate who can solve a Rubik's Cube after seeing it for the first time or someone who has rehearsed it hundreds of time and knows the algorithms? It's not even fair to compare these two people, the former is unequivocally a very intelligent person and the latter could potentially still be an idiot... This is true even if the second person could solve it in one tenth of the time in front of an audience while blindfolded and riding a unicycle across a plank suspended in mid-air above crocodile-infested waters. And this barely scratches the surface of what's wrong with tech companies' hiring processes. This puzzle-solving ability is overvalued and the ability to design/architect good systems (I.e. seeing the big picture and using common sense) is extremely undervalued.

pc86 5y ago

My comments here are relevant only to my hiring experience, which is decidedly un-FAANG: small companies you've never heard of, teams of 3-5 on average but always less than a dozen or so, for the entire company. But I have a lot of problems with using any programming tasks in an interview. My biggest problem is that it doesn't have any correlation to the actual job. Coding on a white board, under stress, with multiple tech and non-tech people watching you, with a sub-30 minute time cap, with no access to the internet or debugging tools other than an interviewer who may or may not just be trying to look smart to the other people in the room, is almost entirely the opposite of what an SDE does day-to-day. I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it. Solving programming "puzzles" is completely different than day-to-day work, especially at small non-startup shops, where you're doing line-of-business stuff and maybe a new project every 5 years. It's maintenance 99% of the time. You don't need to know how to reverse strings to implement a recursive sliding window function. This is how we've done hiring at my current company so far and it's worked out better than any of the places I've been that used puzzles or language trivia. 1. As always, lean on your network. 1st- and 2nd-level connections will already have a lot of previous vetting completed. 2. Interview primarily for team fit. You can teach people technical details easily if they're otherwise qualified. You can't teach someone not to be an asshole, and having an asshole on the team will drive away good people who don't want to deal with it. 3. Have a very clearly communicated probationary period. We use 30 days but honestly 2-3 weeks is plenty. If things aren't working out, cut them in this period. 4. As part of #3, check in a lot more than you otherwise would during this time. We do a management one-on-one every two weeks, so we'll do daily technical one-on-ones during the first week or two of onboarding. We've let one person go during the probationary period because of performance and without these meetings it would've taken weeks longer than it did. 5. Have onboarding. Docs, calls with a defined itinerary, whatever. But don't just drop people into the thick of it if you're doing this type of interviewing. 6. Actually request references and talk to them. You'd be surprised how candid former managers will be about someone's previous performance, even when they're not supposed to be.

Aeolun 5y ago
> You don't need to know how to reverse strings to implement a recursive sliding window function. I guess I generally agree with the sentiment of your post, but if you have issues reversing a string (brute force) I’m not sure how you’d ever get to sliding window functions.

pklausler 5y ago

I find that the best way to expose candidates who can’t actually program is with coding questions that don’t have data structures or even loops in them. Can they write a simple Boolean expression to correctly implement a simple predicate? Too often, no, they can’t. (Example: given two intervals [a,b] and [x,y], are they disjoint or do they overlap?)

dharmab 5y ago
On a team I worked on, our technical screening question was, essentially, to implement Python's `dict.get()` function. A surprising number of applicants who passed HR's screen failed at this stage.
- andrew_ 5y ago
  asking candidates to reimplement stdlib methods is asinine. (unless of course your company is working on python core)
  - dharmab 5y ago
    The exercise wasn't a literal reimplementation, there were some additional constraints rather than a generalized problem, but it was literally 3 or 4 lines of simple if-then statements. And not that it mattered to the purpose of this question, but this team did frequently work with kernel, language runtime and container runtime source code.
  - pklausler 5y ago
    > A surprising number of applicants who passed HR's screen failed at this stage. Perhaps you didn't notice this part of the parent comment.
    - andrew_ 5y ago
      "surprising" indicates that the expectation was the candidates were supposed to be able to perform the task. Perhaps you read some sarcasm into the comment that wasn't explicit?

andrew_ 5y ago

42 years old. I've been in the industry 20 years now. Does that make me a young whippersnapper? I don't know. I can say that I refuse interviews that don't include job-relevant questions. If I'm asked to do work as proof of experience, I refuse any requests that aren't job-relevant. After this many years in the industry, if someone can't take the time to look at my publicly available body of work, call some references (which I always provide access to), then I want nothing to do with them. If your measure of someone's ability equates to fizzbuzz YOU'RE PART OF THE PROBLEM WITH TECH HIRING. The grads probably aren't aware enough to know the difference, being new grads. And I'd wager that's why you're targeting them.

Bedon292 5y ago
I don't see fizzbuzz here as the full measure of someone's ability. Its a filter. I have had many candidates make it through phones screens who seem quite capable only to start working through a series of problem solving questions and they cannot do it. People with job history that suggests they should easily be able to. With no specific language requirements (pseudo code is totally fine) and they can't even write a for loop. We ask to see how they approach the problem, not to get a perfect answer. Ask questions about it, talk through your reasoning, work with us on it. Not worried about off by 1 or specific syntax, just getting to know them and how they work through a problem. We tried hiring a few people who didn't perform as well on this, and it was a mistake every time. And anyone who had no problems with it was always a good hire. Now, obviously there is a problem with the screening process when people who can't actually write a for loop get through it, but until that is fixed, you have to filter them out somehow. How have you approached that in the past? I would honestly like to know how to fix it.

devwastaken 5y ago

Knowing the same interview questions doesn't make you competent. That's the problem. By asking questions not related to the work you filter out people who do the work you need, and only accept those who spend time passing interviews. Same as how ACT's filter for test takers, not ability to learn nor domain knowledge. The core problem is these interview questions are asked without knowledge as to why they're doing it. "It's industry standard" isn't a reason, but it's why binary search tree questions still exist. Some people understand that they're filter questions, but overwhelmingly interviewers think they're real problems related to the job.

bgro 5y ago

I'm absolutely terrible at tech interviews, despite being a software engineer and actual architect for around 5-10 years. I constantly fix major security issues in legacy code, optimize it, and work with the senior devs in multiple languages to create new solutions. I've filled the gap as a tech lead, and frequently have to just figure out a new language in days. I naturally learn language nuances, best practices, I'm easy to work with, I know how to implement things and work across teams, technologies and departments. Learning is what I'm great at, not necessarily coding. I have extensive experience leaning towards hacker-like work in addition to software engineering. I'm legitimately, at worst, decent, with the capability to be exceptional in multiple areas. I'm generally a jack of all trades. I go to a tech interrogation and when I ask for clarification on the question, I get an under the breath "jesus christ, I need to explain this to you?" If I don't ask to clarify, I get "Oh, well he didn't ask for more details. I guess he's rushing without thinking! He's bad at communication. Gottem! Next." I can't take a minute to read the question because the interrogator is screaming that I'm not constantly talking. If there's a literal 10 second gap in talking, I get a "Hello? Are you still there? Hello? What are you doing?" You have to memorize the leetcode questions that are always asked so you're able to talk over them. That doesn't demonstrate any skills. When I get to actual coding, I've automatically failed an otherwise perfect whiteboarding session because I had a lowercase letter instead of an uppercase one. "Ha, gottem! He doesn't know the difference between an object and a variable!" I'm not the best at writing code from scratch but I'm decent in a business practice. I'm exceptional at improving code from any skill level, and adopt that quality in my own code naturally. This has 0 value during an interview though. The only thing that matters during interviews is how many of the classic pattern questions you've memorized. All the amazing work I've done is invalidated because I can't instantly write a perfect meme code question. I come on the internet to articles like this for help or to see anyone else who got stuck in my position, and there's always someone like you here. "Wrong. You're not a real engineer because you can't even answer an easy level leetcode question without stumbling on something. I guess you're not a real engineer. You're just a worthless fake person." I've worked with people like you before. I know because I heard this at my last job from dismissive coworkers either bashing interviewees or other people's code they didn't understand (or understand context around, such as a critical hotfix) in PRs. You people submit untested code on Friday at 5 before going camping for the week and I have to come in and hotfix your sloppy work. I can pick up what you wrote, see how awful your coding practice is, but understand what you were thinking and fix it. However, just because you memorized the leetcode questions or can think of simple solutions to puzzle questions naturally, I guess you're automatically better than me and I'm basically a skilless idiot. I try to have a conversation about fixing this or how I might be an unusual edge case and the interviewers are all on my side. I get to the interview and everything I said is dropped. I get a puzzle question in a google docs sheet that tests none of my skills. I understand you need to test if people can code, but all these dismissive gatekeeping methods are slamming me and letting people who just happen to either memorize the questions or they live and breath programming and can weasel through it. Those people, I've noticed, are frequently poorly trained in coding and refuse to change their ways.

glitchc 5y ago

The disconnect is that the questions are not simple. FizzBuzz is great, always worth asking. It’s when people are asked to answer ridiculous questions that gets my goat. One interviewer asked me to develop a lexical parser in a one hour timeframe. This is stupid in the extreme.

andrew_ 5y ago
> FizzBuzz is great, always worth asking. Up to what point? Are you going to ask a 20 year veteran of the industry to be performative in order satisfy an entry level screening?
- glitchc 5y ago
  It depends. If the veteran is responsible for architecture, process, framework, then no. But, if the position requires that veteran to touch code (or read and review it), then a simple question like a "find the largest number" or FizzBuzz completely appropriate. The question basically acts as a safety value at this point. It is especially important to do this if they have not touched code in previous positions over the last 5-7 years. Otherwise, the business runs the risk of this veteran throwing their weight around on the engineering team and mucking up a production codebase two days before the release date, which could cost the company serious time and money depending on contractual obligations.

muh_gradle 5y ago

Everyone's already saying it, but let's be honest. In 2021, fizzbuzz is not what is being tested. We are 15 years past that now.

tsavo 5y ago

Absolutely this. HR groups now use automated tools to search resumes and filter candidates, which has led to a lot of keyword optimization of resumes. Mediocre talents with optimized resumes in up in interviews where I then screen using the most basic questions. And the questions aren't an attempt to be brutal, the questions will be around platforms and coding that they've directly mentioned in their resume. If they can't answer basic questions around things they've listed in their resume, then you know it is puffery.

geebee 5y ago

I'm glad to see I'm not the first or only one to make this point, but I'll reiterate... it isn't fizz buzz. Trust me, I can write fizzbuzz. I can write loops. I can do basic tree traversal. If I study (yet again), I can also whip out DFS, BFS, MergeSort, inorder, postorder, find all permutations of a set or string, blah blah blah. Without study, I could code up DFS and BFS with a bit of time to think. But probably not in 45 min at the whiteboard. If I study a lot (yet again), I might be ready for the kind of questions that have been actually used to screen me out, such was "find all matching subtrees in a binary tree", in 45 minutes, at the whiteboard. The only way I can reconcile my experience with what you claim to be screening for is that I haven't interviewed with you, and you haven't been at my interviews, and we just disagree about what is typical. But I've been on a lot of interviews, and I do firmly believe that "fizz buzz" doesn't come within 50 miles of the difficulty level of a typical technical exam style interview. I refuse to put this kind of time into study anymore, since there is no lasting benefit to reloading 2nd year data structures and algorithms into short term "45 minute whiteboard memory", and it so rarely works out anyway. I won't do a 5 hour, room to room series of technical exams. This may cost me opportunities, but eh, my guess is that I wouldn't have gotten these jobs anyway, so I'm really just saving time. (on a separate note, I recommend you don't start your comment with a pre-emptive dismissal of why people may downvote you. just make your point, reasonable people here will discuss it with you, don't worry about the others).