7 ms·
But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not i
by ma2rten 4y ago
But many senior candidates actually can’t code anymore.
Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.
- ilikehurdles 4y agoOK. What novel problem is the senior engineer solving using a hash table in a coding interview?
- zach_garwood 4y agoYa know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.
- toomuchtodo 4y agoI used to be an infra engineer. Can’t code (just never made the time to buckle down and grind leetcode or Project Euler out, bit of personal development regret on my part), can glue components together with code (have open source projects I maintain that reflect this), but not an SWE, and the expectation seemed to be you’re either a SWE or an SRE (which is just an SWE in an on call rotation). It taught me to leave for infosec/risk/compliance (more comp, no code or on call expectation). People out there who can’t code interviewing for SWE roles, I can’t speak to, but there are definitely folks being asked to be fluent in code for non SWE roles who aren’t SWEs, so it makes sense everyone gets put through the leetcode grinder rubric to calibrate their level. I don’t think this is about misrepresentation, but expectation misalignment and a crude tool being necessary to evaluate human skills against a baseline. (nearing 40, 22 years in tech, getting out asap, ymmv)
- userbinator 4y agoI've interviewed a few. The most memorable being someone who struggled with what a linked list is, and thought two nested loops over the same number of times was a linear-time algorithm.
- ThrowawayR2 4y agoI have. Supposedly an experienced fellow but put out code that would embarrass an intern (and a bad intern at that).
- zach_garwood 4y agoSo, they could code, just not up to your standard.
- ThrowawayR2 4y agoThe resulting code didn't build either so, no.
- makeitdouble 4y agoThey are out there, but usually in a 3~4 step process they get filtered out before the coding interview. I did a bunch of really quick 15~20 min pre-interviews to check if the person was entering the right process before we both wasted hours of our time. Some who were supposed to have coded and deployed whole applications didn’t know how their versioning system worked. Or they reviewed PR/MRs a lot and tweaked a few lines here and there but had little practical knowledge of issues you’d regularly hit when developing, and only heard of popular tools and resources by name. We could still had them onboard and give them time to get up to speed, but it’s harder to do when they weren’t upfront about it and you’re there trying to guess what else they’re bulshitting on their resume.
- inlined 4y agoI interviewed a while ago at a well rated (but not MANGA) company. I was livid when the interviewer decided to move to an easier question and was skeptical when I “solved” in-order traversal of a binary tree without thinking. “Oh, you’ve seen this problem before?” “Yeah; a few weeks into college…” I’m a staff engineer and tech lead at a MANGA company. I code in up to 5 languages a day. I’ve written Network stacks, compression software, virtualization software, and the backbone of multiple PaaS platforms. And they were focused on whether I knew niche algorithms (apparently based on EXT3) and other stupid stuff.
- ldjkfkdsjnv 4y agoLiterally had the same thing. I've lead large scale software projects for a critical service at a FAANG, and the interviewer will just nit pick on some random detail. Very odd feeling failing an interview like that and then going into work on Monday and banging out software on a highly competitive team
- Izkata 4y ago> a MANGA company That's a new one to me, what's it made of? (All that's coming to mind is I presume totally unrelated: https://en.wikipedia.org/wiki/Manga https://en.wikipedia.org/wiki/Manga )
- zrail 4y agoIt's FAANG but rearranged and using Meta's new name instead of Facebook.
- nunez 4y agoi definitely 150% have there are a lot of them
- zach_garwood 4y agoThat's too many percents.
- native_samples 4y agoBe grateful! They definitely exist. At my last company, I joined as their lead developer and discovered they already had another developer in the pipeline they were thinking of hiring. They thought the guy was super senior, and when I read his CV sure enough he came across that way. He emphasized on his CV that he was not only a Java expert but an expert on the internals of HotSpot itself. Probably he'd been saying that for years, and given how many firms use the JVM it's probably a great line. Unlucky for him he got an interviewer (me) who actually was an expert in the HotSpot internals and liked to relax by reading its source code. Guess what? He knew nothing about the JVM, not even stuff you'd learn by reading the user guide. I got the sense he'd read one or two popular press articles about it 20 years ago, put it on his CV and never updated it. So we progress to some coding. He can't code. He struggles with even the basics of starting a new program in an editor and compiling it. The guy was demanding a huuuge salary and great perks. After I wrote up what I'd found from the coding interview he was quietly dropped from the pipeline. They'd been about to accept because they were so dazzled by his claims but weren't checking them. The "knew it once maybe sorta" problem is common, especially with C++ where lots of people were struggling with it in the 90s and then jumped to Java/C# as soon as they came out. But they still list C++ on their CV. Ask them to write a C++ program (that does anything at all) and they'll just refuse or state point blank they'd feel really uncomfortable doing that. Lots of people lie about their experience unfortunately. They probably don't think of it as lying. They just write down every possible thing they've ever thought or read about and exaggerate, gambling that they'll never be called on it. And, they're probably right. That's why coding interviews took off.
- lapcat 4y ago> They probably don't think of it as lying. They just write down every possible thing they've ever thought or read about and exaggerate, gambling that they'll never be called on it. Well, job postings are infamous for listing a ridiculous number of "requirements" that aren't really requirements. Those who are familiar with hiring know that job postings themselves are lies and encourage people to ignore the requirements and apply anyway. Even the people who work for the hiring company say this! So it's a two-way street. There are already perverse incentives created by the hiring companies. And we also know that resumes are screened for specific buzzwords. You may not be recruited or interviewed unless unless your resume has the right buzzwords.
- dagmx 4y agoIt's not a boolean can/cannot code. It's a cannot code at the level expected of the seniority. I interview tons of software engineering candidates (pre pandemic it was at least one or two a week). At least half of my senior candidates fail basic phone screener questions. These are questions that reflect something they'd be doing day to day in the role, but also are incredibly standard in our field. The issue in most of them is that they've taken their support network for granted. The tons of developers before them who laid groundwork, and the others currently who take care of many tasks they consider junior. Well that leaves them in a weird spot where they've not actually done a lot of the foundational work their predecessors set up for them, and they've let a lot of their skills atrophy by delegating to juniors. They'll even say as much and say "oh so and so does that, or they had it set up and it's great" But then what am I hiring them for? Certainly they're not bringing a wealth of programming ability over, so maybe soft skills? That's hard to hedge bets on for a SWE, maybe as an product manager or something.
- ldjkfkdsjnv 4y agoI think actually whats happening is some people are just not good at interviewing on the spot. And people are looking for gotchas in these interviews, "He didnt know how to use breadth first search?!?!?!", when the senior engineers daily life is probably more like a surgeon operating on a highly convoluted large scale code base full of business logic.
- dagmx 4y agoThat may be true for some other interviews, but like I said, I ask questions based on what we'd be doing day to day. I don't care about CS theory jargon or language gotchas. Again, at least half of software engineers I talk to for the screening round are not strong developers for the reasons I mentioned above.
- gedy 4y agoThen tell your company to not to reach out to recruit senior & experienced candidates if you aren't sure if they can code from looking at their experience, github, etc. I'm personally very tired of answering recruiters & hiring managers for specialized roles, then the interviews end up being some unrelated CS quiz, mostly from people with less experience than I have.
- tombert 4y agoI once had an interview that told me to “design Twitter”. I drew some diagrams on the whiteboard, and the topic of the database came up. I asked “do we want to have consistency or availability for this?”, to which the interviewer said “I want both”, to which I said “umm, I’m pretty sure you can’t have both, CAP theorem and whatnot”. We spent two minutes arguing which led to me taking out my phone and pulling up the CAP Theorem Wikipedia page, and eventually the interviewer begrudgingly admitted I was right. I surprisingly did get an offer after that interview but I found it a little annoying to be interviewed by a person with less experience than me who I have to argue with because his understanding of computer science is wrong.
- Apocryphon 4y agoDoes the industry even need engineers who can code? This is a hyperbolic rhetorical question but consider how much of modern work really is CRUD API gluing, and how much of that work is not rigorous engineering, but tedious implementation as per documentation and wading through hastily-thrown together legacy cruft written during previous crunch time. How much of that work involves novel programming and memorized understanding? Most of it requires study of existing codebases, not given a blank REPL to hash out something new.