Is it my idea or are interviews more harder nowadays? If you had to take a technical interview for your current position would you be able to pass it and get the job?
If you were the one doing the interview, would you be strict and request more things so as to filter out candidates? It’s understandable because somehow you need to find the best ones for a given position, but there are some soft skills that C/Java/Python interview problems can’t identify.
I’m asking because I’ve seen many interesting positions in which I could imagine myself into (having ~20 years experience in telecoms/soft engineering), but the entry requirements with regards to programming languages are set too high.
What are your experiences?
An implication of this is that the optimial interview process -- from the employer perspective -- will have a lot more false negatives (good candidates rejected) than false positives (bad candidates accepted).
So it could correctly be optimal for the interview process to be so onerous that most job-holders would fail their own interview!
My advice for these sorts of tests is to make it as short as possible, and use the test to give you something to talk about in the follow up in person interview. Replace "Invert a binary tree/solve this riddle" with "Why did you do this in the take home? What would you do differently if $FOO was now a requirement".
I find it effective.
To answer the OG question, I'm sure I would do well. Depends on the other candidates on whether I would get the job though.
If you want to talk privately you can reach me via twitter DM at https://twitter.com/@jitl or jake@makenotion.com
Thus, if you interview those promoted employees, they are not going to match external candidates unless they have been in the role for a while and are now excelling.
Additionally, you evaluate external candidates much more heavily on raw skills b/c they have no internal knowledge/experience, but you include that internal knowledge/experience when evaluating employees.
Finally, interviewing skills != working skills. I've been writing software for 20yrs, and interviewing SDEs for almost as long, and I'd still do interview practice to prepare. In a normal job I can go search the details of what a red-black tree is, and find a library to use it (or spend a few days implementing it). In an interview I need to already know it and be able to implement it myself in less than an hour. (yes, that sucks, but it's the reality of interviewing today)
Other close people I've asked before:
A, at Google, got in 10+ years ago. Told me she would not pass the current interviews.
B, at Google, an aquihire, 5+ years ago. Told me he would never have gotten in the front door (leetcode) way.
C, at Netflix, got in 5+ years ago. Told me odds are he would not pass if he were interviewing today. He says he is in a very interview un-ready state, and none of his realworld experience working at Netflix would help him pass his team's interviews.
The technical interview is broken and has been for a long time. I'm sad that as a society we accept leetcode or unrelated system design questions as a means to measure proficiency.
The standard continues to rise in certain companies and lowers in others.
I'm sure if I was in "interview mode", I could pass, but my position is not about knowing how to invert binary trees.
The Big Tech companies have standardized their interview process around hiring new grads. They fight with each other to hire them. These noobs get hired en masse and perpetuate the process, ultimately creating a monoculture of noobs hiring and mentoring noobs. It is the blind leading the blind.
So Big Tech companies end up consisting of armies of highly uniform noobs that throw massive amounts of code/money/people/time at every problem. And not because they're stupid, but just because they never had the benefit of real mentorship and training from a diverse pool of experienced experts. And because they've never learned to build without the resources of a Big Tech company.
On the other hand, good startups seek out experienced experts with diverse technical skills because they really need the most effective people possible. They're not just trying to meet recruiting quotas. They have to do great work and have to do it efficiently or they fail. This is why good startups can very often do much better work than even much larger Big Tech teams.
If you're an experienced expert, and actually enjoy your work, you probably want to work for company with less than ~300 people. And you probably want to quit when it gets to ~1000 people.
Yup. I didn't get blasted by algorithms problems and data-structure trivia for my current job. The interview I got was to answer a handful of questions by querying some data from a CSV file. I was supposed to use the programming language of choice by the company but I just loaded the data into a SQL table and did the queries in SQL... which was fine because the application I'd be working on is a web application and the majority if our work is querying databases.
Could I get through the usual interview process at other companies? Sure. I'm used to it by now and came up with a training regimen to keep my skills sharp. It really comes down to being able to categorize word problems into a handful of common data structures and algorithms: breadth-first search, depth-first search, two-pointer, binary search, dynamic programming... linked list, vector, hash map, or tree. Once you can match the description to the data structure and algorithm the solution is usually within reach with practice.
It's not my favourite skill and I don't find competitive programming entertaining. But that's the way the world works right now.
My company recently switched from a code submission to a hackerrank type thing. As part of that switch, several engineers of different ranks (junior, contributor, senior, staff, etc.) took the quiz to benchmark the platform. My score was second-to-last, despite being the highest ranking engineer.
Otherwise, it basically lined up, so we made the switch. It’s certainly possible that I’m under qualified for my position, but I also suspect that these assessments have significant false-positives and false-negatives, the consequences of which will be hard to measure, and therefore ignored or mis-diagnosed.
For myself I can say a definitive yes for 2 reasons - the first is at my current job all the interviewers test run new interview questions as a filter. If a preponderance of don't pass the question we don't use it. the other way I know for sure is that I have been actively interviewing for new roles in a lateral+ capacity. With an n<10 I have 100% pass rate into the interview process and a 75% rate of offer. My prep for interviews is Linkedin sleuthing of the companies and interviewers. If I ended up in an interview process that was asking for me to balance a tree I would likely fail, but I would also not want a job at a company that uses that question. For reference I am a top end IC (principal/architect/lead/etc.) with 20 years in complex web app dev.
I only got in because I happened to do the exact LeetCode questions asked the night before, and the questions relied on knowing special tricks
I really doubt when people say they got in to LC heavy companies without studying much, its more likely they just lucked out and got a question they happened to be able to solve
For any candidate you can create an arbitrarily hard/tricky LC question they won't get
I suspect the new grad FAANG recruits are at an advantage here (dubious though it may be), in that they are ready to grind from the get go. Those of us that started out in a different place are running into the hazing later in our careers and there's this existential crisis of "this isn't fair" and "am I a terrible engineer" and "screw them". It took me a number of years to move from denial to acceptance. I still posit that being able to pass these interviews have not made me a better employee, just a better interviewee.
I have been working in the same job for 10+ years. I was hired as a somewhat lower position than my current one and promoted over time. I am not sure my organization likes to hire "senior" developers - so I don't think "my" position would be available. They would probably split the work I do now into two junior positions.
This hiring pattern doesn't seem uncommon in my area. You see lots of junior-level positions kind of rolling around the typical job listing sites with very few senior roles.
Over those 10+ years I have done two or three more serious job searches. I tend to get offers but they are usually lateral moves. Meaning, roughly the same salary and work. I have some uncommon benefits at my current role so when I go on the job hunt I am typically looking for either a significant bump in pay or in work specifics (inspiring peers, programming languages, etc) or it isn't worth changing positions.
I would say that if you see interesting positions, have a go at it! Don't wait. And this is especially true if your vision for your career isn't on track to being fulfilled at your current job.
P.S. I'm not defending the current situation, I am merely trying to summarize it from the a practical point of view (i.e. action X increases the chance of outcome Y).
But yes, I've definitely encountered interview questions posed by a company I worked for that I probably would have flunked. And I've tried my best to push back on those, when it was clear that they were designed more as an ego booster for the person who designed it than as a tool for accurately assessing skills necessary to perform well in the open role.
One thing I would recommend, for companies that have similar issues, is to lean more on your most junior and most senior engineers, rather than mid-level and early senior engineers, when crafting things like coding challenges and architecture/design sessions. They're often the ones who will approach the task with the most humility.
UK based, financial sector, FWIW.
That said if I was looking to move, my confidence about other places being so sane would be low to medium, there seems to remain a lot of deterring approaches out there still.
Would i pass my own interview though? Not sure. The depth of knowledge is reasonable, since i craft my own questions i know the answers, but they are not standardized. They are tailored per resume. So depending on how i read my own resume, i might come up with questions that i don't answer adequately.
Many years ago however, I got into a FAANG via a "side channel", working as a a support engineer for ~1 year before I managed to impress a manager in the proper product engineer org (whom I and my team worked with closely), and didn't have to suffer through a traditional FAANG style interview as a result. Best opportunity of my life on accident, turns out. Pretty sure that on my resume opened more doors for me than anything else.
I'd never pass that interview process, yet proof is in the pudding that I did well, I rose the ranks over 5 years before leaving due to not wanting to relocate for a bigger promotion.
And we are hiring: https://www.mcg.com/about/careers/search-jobs/?gh_src=266419... (Feel free to email me at the address in my HN profile to ask about the company)
It isn't that people are more pragmatic when hiring a contractor. But in fact contractors are hired to do specific tasks. These days, your traditional software engineers are asked to all sorts of things and asked to learn all sort of things as the company grow. I think that there was a probably a time where the scope was limited and recruiter knew what are the problems a candidate might need to fix. Tech stack wise I would guess we are in an era of ambiguity.
Disclaimer: Haven't worked a day as an employee anywhere.
But only because the vast majority of our focus is on the person - their character, attitude, what drives them, what motivates them, how do they treat others, what are their communication skills, etc. Very little is spent on technical capabilities.
This has served us well, but hiring takes longer and is more involved. A lot of people fall out of the process early on, but it is totally worth it.
I understand the need to narrow down candidates but this kind of screening is about as useful as throwing darts at a dartboard.
There’s a risk that leetcode heros might turn out to be the type that throws up their hands at the sign if smallest of team friction points. As a Pm these devs are the most annoying. “That other team didn’t respond so I’m blocked”
Leetcode questions don’t help with this important criteria.
I would. I wouldn't ask hackerrank, leetcode or google-interview-type questions though, requiring knowledge of specific algorithms. I would ask questions about the programming knowledge that is relevant for my role. Since I'm in frontend, I would focus on finding out how well the candidate understands javascript (and these days, probably typescript as well), css, and browser apis. This and talking through the problems, I believe, will give me a pretty good signal about where the candidate is at.
However, I would not get the job because I wouldn't pass our in-house recruiter's phone screen. We recently did interview training, and got an explanation of what kinds of questions HR uses to filter out candidates, and when I pointed out that I would be thrown out after the first two questions, despite widely being considered a great culture fit, all I got was a shrug. :(
My question scales. It has 5 parts, such that a bootcamper can solve 1 and 2, and completing part 5 would require a whiz to spend several hours. That is, however good you are, I'll be able go get a good signal, see your thought process and you'll come away feeling mostly good.
You don't need to find the best people for a position, you need to find the ones that meet the requirements that you should have already set. If you're changing those requirements during the interview then you're doing it very, very wrong. It's fine to ask additional questions to get a better understanding of how well someone will fit, but that's completely different than moving the goalposts as the interview progresses.
Wait for "the best people" and you could be interviewing for years.
New interviewers are required to calibrate their expectations for the question by practicing conducting the interview on 3-4 existing employees.
By evaluating on dimensions you don't have to study for & calibrating based on active employees I like to think this does a better job of making sure we don't miss out on hiring good engineers who haven't spent hours doing LeetCode.
I don't believe they're any harder than the interviews I had to perform 12-13 years ago. If anything I think they're easier, because I remember a lot of weird trick-logic "Google" questions during the late 2000s that didn't even touch programming or software.
Algorithimic/coding? _maybe_, not confident in the least and would lean towards "no", simply in that my preparation was significant. I also push back in current company (FAANG) against the strong algorithimic/coding pushes as I don't think they are a good signal for skill/employees.
That being sad, where I am (Netherlands), interviews haven't gotten noticeably harder. 20 years ago I had an interview where I was asked to implement polymorphism in C on a whiteboard. The other year I had an interview where I had to implement some kind of graph sorting system related to blockchains. I failed them both, and went on to find a load of other companies that were a bit less silly.
My overall impression is that it's big tech companies in the US that have become obsessed with coding tests, hankerrank and leetcode and the like. I don't know why, when half of them are complaining about acute talent shortages... (Facebook?)
I've long come to terms with how much randomness plays in the interview game.
Interviewing is a numbers game, so play the game and fail/succeed quickly! I usually put out 25-30 applications a week, accept maybe 10-15 initial calls, and get an offer or so every other week.
It's a candidates market and companies know it. If I receive a request in an interview that I don't agree with I just say so. Leetcode for a Senior role? No, get rid of it or I walk and take another offer I can pick up in a few days. Just refuse to do anything you consider below your pay grade.
They leetcoded and had interns do system design diagrams. Intermediate and higher had paired code writing and a design discussion.
Joking aside, I would definitely pass the interviews for my previous job (I left 4 weeks ago). They were very JS and React focused, and they were pretty easy. I know that domain well, so I tend to interview well in it.
Where does it end?
Most "system design" interview material online seems to focus on web stuff where you setup multiple servers but my experience and my interviews usually involve designing an app or some other mostly offline system that would be implemented in C++.
The average software we build is more complex than before too. I guess that's why interviews have become harder.
I think I have done around 100 interviews as interviewer too and the biggest problem I see is that many of people that advocate different training programs for passing interviews have wrong idea about the interview process.
You shouldn't practice for puzzles. The whole purpose of live coding interview is to see how you communicate and how you approach to solve a new problem. Nobody expects you to implement algorithm in less than an hour and without studying it first. Nobody actually expects you to complete the assignment, even though it's definitely a plus point if you do it. That's the only part of the interview process that doesn't require practice in my opinion (if you know how to code). Instead you should practice your communication skills, debugging skills, best practices, and focus the actual requirements for the job. If they are building distributed systems, they are obviously looking for talents that at least understand distributed systems.
That's how it was done at my previous employer, too.
2. Wouldn't copying FAANG hiring practices (if you are not FAANG) ensure that you will always get their "rejects"? Where you will always have an inferior talent?
I've always found such questions lame, because (1) you rarely need this kind of thing, (2) when you actually do, you can find the information within 5 minutes, and (3) if you don't know it, well... you're not gonna suddenly come up with somebody's PhD thesis during a stressful job interview.
And you may say "yeah, they don't expect you to, they just want to see how you think". That's bullshit, because people know this questions come up often and will sit down and study them in order to game the interview process.
I'd still prefer the whiteboard interviews, over what are sometimes knowledge-based questions that are a search away. Not the common stuff that you should anyways, but something obscure that if you spent 5-10 mins on its man page, you will get it.
In my current position I constantly improve my skills to fit a variety of projects and facets of a single project.
Unused skills atrophy all the time.
My skill set is dynamic, adjusting to a variety of conditions and needs.
My core skills are qualities - curiosity, enthusiasm, quick adaptation, quick learning, communication, understanding logic, attention to detail, ability to visualize software as factorio-like machinery, skepticism and paranoia/trusting that people will try to do things wrong.
If I am asked to write a sorting algorithm I shall not pass. Therefore, I will never ask anyone to do so in an interview.
I prepped on that and some other material recommended by the guy that referred me.
That’s all been changed now so I’d be going in blind.
I bet the same is true of lots of engineers, too (that’s not my field, either.)
Just for point of reference.
I’ve never seen anyone hate their product and love their process quite like that, before or since. It was breathtaking.
No, absolutely not. I am a senior front-end engineer with 24 total years experience and about 15 years of full time employment in the corporate space.
I have enough experience that I can build most any kind of application that will execute in the browser. Given my level of experience I can execute pretty quickly. For my current side project I wrote a complete OS-like GUI in the browser, including file system display, in about 15 days. Its mostly WGAC 2.0 AA compliant and performs awesome even when scaling to an absurd number of GUI windows in the display.
Of course, if I approach any problem space that I have no experience with there will be some required learning time. For example I have no experience with graphics processing, so if I were tasked with rewriting Photoshop for the browser I would slow down figuring out how to write the tools specific to that class of application. If I were tasked with writing an accounting application I would have to learn how some basic accounting things work, and so forth.
Experience and competence will not get you hired writing JavaScript. In fact I will argue, as I have observed from interviewing this year, that you can be neither competent or experienced in this language/platform and be hired for an incredibly high salary, even at stable established big companies, if the other conditions are correct. I was having no trouble pitching $170k in a low cost of living area and requesting full time remote.
Hands down the most important consideration for employment writing JavaScript is appreciating the most popular tools. The most popular of them all at this time is React. To prove this visit this month's Who is hiring thread and do a CTRL+F for TypeScript. Around 90-95% of those positions require ReactJS.
https://news.ycombinator.com/item?id=29782099
Hiring aside, why would somebody with my level of experience spend any time with a large framework like that? It will dramatically slow down the performance of my applications, thanks VDOM, and inflate the size of my code by several times. It will also slow down my speed of delivery by an order of magnitude because there are addition technical concerns and more to test for. Then there are all the dependencies and additional build steps and plugins and all the other luggage that I don't want or need and that I certainly don't want to force onto my users. Worse, is that without all the nonsense the front-end is only a tiny part of any major application. Like insignificant trivially tiny compared to the rest of the application code even after accounting for accessibility, security, and cross-browser concerns. All the code swell is tech debt that increases maintenance concerns by orders of magnitude.
At this point I am already immediately disqualified from continuing employment in this field, but there are other more subtle secondary concerns resulting from tooling that add up to widen that gap.
Its interesting, because I went on a bunch of interviews, this past summer/fall. Never, in those discussions, almost never did anything knowledge related about the technologies/platforms come up in discussion, which I found very strange. There would be some knowledge questions about how the language works from a very broad level and how to asynchronously transmit data, but that's it. You would think if you were hiring a Node.js engineer there might be some Node related questions or if you were hiring for a browser related engineer there might be some browser related questions. Weird.
> If you were the one doing the interview, would you be strict and request more things so as to filter out candidates? It’s understandable because somehow you need to find the best ones for a given position, but there are some soft skills that C/Java/Python interview problems can’t identify.
I have interviewed many candidates. I generally gave three rankings to the hiring manager - pass, minimally acceptable and very good should follow up. Candidates tend to be a Gaussian curve with a normal distribution - if their resume looks good and they have been doing the job for at least two years and they pass a simple phone screen, the bulk (two thirds) follow into the minimally acceptable category. They know the basics and obviously have been doing it, but their knowledge can be spotty, and probing in depth almost never has results. Maybe one in six slip through the initial filters of resume and phone screen and show up at an interview knowing next to nothing. On the other end is the other side of the standard deviation - someone whose knowledge has few if any blank spots, and who can answer questions in depth.
I've found I can usually tell if they don't fit into the successful group in the first three questions. I have never had someone who flubbed the first three questions come back and answer subsequent questions correctly and in depth.
Of course having a recommendation internally helps. People I have deemed minimally acceptable who have been vouched for by a teammate have been hired. If they're coming in cold, they have to be in that one in six, one standard deviation above group who have some grasp of almost every subject you should know, and can go into depth on a lot of things.
So from your view being interviewed, it is pass/fail. From my view, I am looking at six people, one obviously bad, four interchangeable who have slightly spotty and not in-depth knowledge, and one who shoots the lights out and can go in-depth on a number of subjects. The last one I pass I bring to the attention of the hiring manager, the others I say they're minimally OK, with the occasional pass. Sometimes they're doing great technically but I know the manager will pass on them because they won't like they're attitude, but I pass on them anyway. Once me and someone else interviewed someone who passed the tech interview, but their behavior in the interview was odd and we both agreed to not pass them on.
Secondly:
> Is it my idea or are interviews more harder nowadays?
Interviewing can be hard.
I've been asked to show Github projects (as my IP assignment agreement might assign copyright of off-hours work to the company, I don't have a lot of motivation to do these), do work samples over a few nights, do 30-60 minutes Leetcode interviews in different languages, with a framework or without, to look at code, fix bugs, and check the code in to git, to whiteboard high level class design, to answer programming questions, language questions, framework questions, popular 3rd party framework extension questions, questions about how I deal with product managers etc. I hear FAANG grills you on graph theory depth first search and things like that which I haven't implemented from scratch since college (at work I'm usually doing CRUD or sometimes UI stuff, anything more complicated I am usually doing on my own time).
It's a lot to work a job and keep on top of these things.
I have been diving into learning some language-specific things in the past two years, and things which you can find across languages to some extent. I have done a little bit in learning the newer framework things coming out, or going more into depth on things I needed to know. If I was gearing up to interview I would probably put these things aside and learn how to Leetcode better and that sort of thing. Most of what I study can probably help me find work, but if I shifted what I was doing into learning how to do Leetcode quickly, correctly and compactly, that would probably help more. Things like that.
First off, I hate the "FAANG" acronym, its become a status symbol of some sort and is used so frequently in d*ck measuring contests on social media. I am cognizant of the fact that there are SDEs and great SDEs even outside of BigTech.
The reason Algorithmic challenges are used so frequently in FAANG companies is that when done properly they can be standardized pretty well with minimal source of biases. When done properly, you can observe candidates thinking out loud, communicate properly under time pressure which is what is required at most tech companies. Also, LC style problems cannot be memorized, you have to be incredibly lucky to see a problem you solved recently or the company's hiring process is so broken that their questions are already known to public.
Algorithm challenges are basically testing what you learnt in your undergrad CS curriculum, the topics are limited to fairly standard stuff you learn at university, regular DS like Stacks, Queues, LL etc and algorithmic techniques like DFS, BFS, Sorting, DP etc. Once you have done enough of these problems and understand them well enough, the LC interview isn't that tough. This is coming from someone who has been giving at-least 2 interviews a day for the past 2-3 weeks. I won't say my hit rate is 100% but I am fairly confident that given a problem I haven't seen before, I could solve it in an interview setting under time pressure. You face this situation quite frequently at most tech companies as part of your job.
At the same time, I would whole-heartedly agree that 90% of the work at tech companies doesn't involve applying Algorithms in real life. Never have I faced a situation where I have read an algorithm in textbook and applied it at work. Although, having worked at one tech company, I did see quite a few DS/Algorithms being used in real-life in Large scale services. I remember seeing Tries being used to speed up string search in some services in Exchange at MSFT, I did see clever applications of Bloom Filters, if you peek into the source for .NET Dictionary and you see how hashing is implemented in the real world. Say that the Keys you use in your real-world application are for some reason unevenly distributed and you store them in .NET dictionary, your read queries would considerably slow down and that might not be optimal for your customers. I wish that this were a contrived example but it isn't, I have seen many such situations occur at MSFT where Engineers didn't properly think of trade-offs when designing large scale systems. Algorithmic interviews can be a good filter to test these skills.
Also most tech companies don't necessarily want to hire domain experts. That does happen but only rarely and most teams are fairly generic, they aren't working in specific areas like Databases, Networks, OSs etc. I see folks saying that they are really great with specific frameworks but truth be told, Tech companies would rather hire someone who can learn specific frameworks on the job under extreme time constraints. I know that this is the exact opposite of Startups and smaller companies who need "domain experts" to ship stuff sooner. Amazon doesn't require new folks to know Spring MVC, MSFT doesn't require new hires to know .NET MVC etc, they all want developers who can pick up any XYZ skill whenever the job demands it. I know that quite a few of HN users might look down upon that and you have every right to, but that really is the job at BigTech. Most engineers are fungible, even though you cannot like for like replace engineers you lose. But at the scale that they are operating that is the only way.
Algo challenges test for raw intelligence, period. Now, even Algo challenges have varied levels of difficulties. I have heard horror stories of interviewees being asked questions that require particular tricks or complicated DS like Segment Trees etc. Unfortunately that does happen.
Also, most companies have rounds where they do test "domain knowledge", skills like OOD, System Design etc. Although I admit, these two are also beginning to be gamed. There are websites that sell "courses" for these and its getting to a point where interviewees just regurgitate info from these courses even if they haven't used them in real life at work but that is what happens when you deviate to something that is difficult to standardize. Additionally, from the interviewers perspective its difficult to judge what contributions interviewees have made to an organization when they haven't closely worked with them and the work might be in a domain they aren't familiar with, that is unless you have made major contributions to OSS, which can be verified easily.
Finally, I have to admit that in all this frenzy I just seem to have gotten lucky. I finished university four years ago. Algo challenges were wildly popular during my time and I still like solving them, although I am not as prolific as some of the folks I know in Bigtech. I did a lot of it in University and that helped me tremendously in interviewing at Bigtech. I realise that HN folks come from a diverse set of backgrounds. Some of you are much older and have familial commitments which certainly makes it tough to "practice LC" along with your work and spending time with family. In that, LC is really a young man's (or woman's) game and I have to admit that I have been a beneficiary of that. I can only soothe you by saying something cliched, Life isn't always fair.
That's because I met the principals directly and we spoke over the nanoscale particulars of a certain problem space we had both worked on and that was their basis for hiring me.
After that, there was a change in ownership and they hired the usual crop of cargo-culters and buzzword droppers and fake-it-till-you-make-it types. Who I'm dead certain would not hired me at all. Or even looked at my resume.
Even if you concede my position (and I know a lot of folks think all these questions are impossible / unfair), at the end of the day they're just a terrible signal of whether someone will be good at their actual job.
The folks that I've interviewed who really ace these puzzles often (but not always) end up writing terrible code, e.g. cryptic variable names, lots of use of indices into vector / array data structures instead of something more idiomatic like iterators and std::algorithm stuff.
My current approach is to show some subtle C++ gotchas and ask the candidate what will go wrong (e.g. where is the undefined behavior?). I don't even expect candidates to get all of them, as many of them are hard even outside of the interview set and setting. Then I ask them to write a hash table for values with large data (i.e. where using std::vector as a bucket would be a bad choice due to the 2x'ing of size on resizing) and just see what they write. The main thing I expect is for them to demonstrate that they know the stdlib stuff (e.g. std::list, std::forward_list, std::hash, templates, etc) and can explain the tradeoffs.
Surprisingly, far fewer people pass my interview despite it not being some obtuse mental brain teaser, but those that do have been great colleagues.