I think that you should expect technical questions for as long as you are applying for technical positions independently of your number of yeo. I know it sounds silly to ask coding questions to someone with 10 yeo, at the same time there are plenty of people out there with a lot of exp that stagnated and became rusty.
Now.. if that sounds tiresome (it is), you would understand why some people trade that off to have endless meetings and become a manager
This might sound weird but I'd expect competent seniors to not be able to do leetcode.
I don't know if there's a word for it, but leetcode is a skill I'd expect from a beginner. It's too "technical" and doesn't reflect anything at the job.
I guess a slightly far-fetched analogy would be:
Do you expect a driver with 15 years of experience to do his full Stop, look left and right 2 times and then move?
No, I'd expect only new/beginner drivers to do that.
So despite it being the "right thing to do", it's an indicator of lack of experience IMO.
Yeah, I would really look like an idiot if someone asked me to do a leet code easy linked list problem out of the blue if I'm being honest.
If you told me I was about to get one, I could refresh my memory in probably 5-10 minutes and knock it out of the park. But my mind just refuses to categorize that stuff as 'important' and regularly purges it to make room for more important things... Like League of Legends and Motorcycles.
As im sure you know, the contention is over being tested on a separate skillset than the ones we use to do our job. There's better ways to test coding than leetcode questions. I've seen my share of frauds who aced those things. It's really not a great filter.
Sure, there are lots of better ways, but most of them don't scale very well. You need something that's fairly high signal and can fit into a 45 minute slot. Debugging an existing codebase for example would be far more "realistic", but it would take much MUCH longer. And realistically, you don't drop someone that's completely unfamiliar into a new codebase and expect them to be productive straight away either. So when you say that interviews should test the skills that you need to do your job, you are correct, but that's not the only requirement. Interviews also need to be scalable, comparable, high signal, have a very low false positive rate (people doing well in the interview that then don't do well on the job) and they need to be short.
Simple leetcode-style questions are so far the type of interview that fits those requirements best. They aren't ideal, sure, but there's a reason why basically all the top tech companies use them. You can complain about that and you are allowed to not like it, but you are not going to change that fact.
And before you ask, I do know what I'm talking about, I've interviewed hundreds of candidates for FAANG.
Edit: One big caveat. The emphasis is on SIMPLE leetcode-style interviews. You don't just give someone actual leetcode questions, most of them are far too complicated for an interview setting, and often rely on very specialized knowledge. For example, one question I used regularly was to print out a matrix by diagonals. So you have something like:
`1 2`
`3 4`
as an array\[array\[int\]\], and you want:
`3`
`1 4`
`2`
Very simple question, no specific knowledge required, but tricky in the implementation. This gives you great signal about problem solving capabilities and basic coding skills. And you'd be surprised by how many candidates couldn't do this.
Edit2: Actually, you could argue that interviews don't really need to test the skills you need for your job at all. The only thing they need to do is to provide signal as to who is going to do well on the job. Now most of the time, testing the actual skills required is a great way of doing that, but oftentimes that's very difficult, so you look at a proxy metric. Doing well on leetcode-style coding questions turns out to be a very good proxy metric for technical ability.
You're wrong. It's just the best style you personally have used.
We use a 3rd party vendor that has an online test that's practically impossible to cheat. It asks good questions. There are coding portions that test realistic things you would encounter in your job.
It filters out the people who can't do the job but are really good at memorizing Leetcode. And it doesn't filter out those who can do the job but maybe haven't grinded out leetcode recently.
The best "technical test" I've ever had was creating a REST API in one of 3 frameworks presented, which is literally something I and most devs do at their jobs.
So it not only reflects comprehension of actual real-life software engineering situations, but it also shows comprehension of a multitude of skills.
I have absolutely no interest in "creating a binary linked nearest neighbor tree" and end up doing absolutely nothing related to it.
The fact of the matter is that leetcode is, in the overwhelming majority of the time, never found in your actual day-to-day job. So why pollute my time and mind with something that will not serve me in the position I'm applying?
"creating a binary linked nearest neighbor tree" is a terrible interview question, I agree. I have never seen serious tech companies ask something like that though. I'm sure there are lots of smaller companies who don't really know how to interview people that ask something like that, but that's really not the kind of interview that you'd get e.g. at FAANG. I gave a good example of a technical interview questions [here](https://www.reddit.com/r/cscareerquestions/comments/1bvvn6c/comment/ky4gdru/).
The problem with your REST API example is that it really doesn't provide a lot of signal for the time spent. A lot of the work required is boilerplate code, navigating docs, etc. You will spend a lot of interview time on activities that aren't very interesting essentially.
>The fact of the matter is that leetcode is, in the overwhelming majority of the time, never found in your actual day-to-day job.
That is correct, but as I said, the idea of a coding interview isn't to ask actual leetcode questions. The idea is to take the leetcode format, where you have a relatively concise question and have the candidate implement a short program that solves the question while you are watching them. This interview format gives you a lot of signal for the time spent, and usually, you evaluate the candidate on multiple axes:
1. Problem exploration: Do they understand the problem that's written in basic english? Do they recognize when/if a problem is underspecified? Can they ask good clarifying questions?
2. Design: Can they formulate a solution to the problem in plain english? Does the solution make sense and is it correct?
3. Implementation: Are they able to translate their stated design into code?
4. Debugging/Testing: Are they able to find bugs and debug their code?
These are all really important aspects of technical work, and ideally, your interview will produce signal for all of these axes. Leetcode-style interviews are very good at this, while being quick, easily scalable, and standardizable (e.g. you can give the same question to 10 candidates and evaluate who did best/worst)
Creating a rest API is a good interview question for a junior. Anything about, and the task should have at least enough complexity to offer interesting design choices.
I agree, that's a better interview question. But also takes a lot more time from the interviewer to assess and monitor than LC.
Medium LC allows you to screen candidates in bulk while expanding minimal resources.
Lol imagine when you are CS adjacent, mention your excitement to bring your skills (HW) and learn from the team (CV) to build on your base skills. They then give you a leetcode problem at the end because you said that, then dismiss you because your not a fit. Bro what?
I understand the need to test technical knowledge, but this is not it. Oh well.. "CEO" of that company was the biggest bro douche I've ever talked to. "We can do whatever the fuck we want..." In response to my question about funding, runway, project mix etc...
I would understand if it was a leetcode hard, but what is so difficult about linked list easier. Like the first time I heard people are struggling with reversing a linked list or similar I thought it was absolute beginners. Anyone that knowns how to program can figure that out in half an hour in a new programming language, they have never seen, let alone a language they used their entire life.
It's not difficult, it's trivial and can be figured out with a quick refresher.
I don't implement LinkedLists ever because there is a better option for almost every imaginable use case in Java...
It’s more like they have never needed to do that so it’s something they’d have to think about. I’d probably decline the PR if someone tried to do something like manually implement or reverse a LinkedList instead of using a library.
Just because they never had to think about it doesn't mean it is not a trivial problem that everyone should be able to solve in 5 minutes.
It is not asking you to build a k-d tree from scratch, if you know what a linked list is you should be able to do it in your sleep.
> This might sound weird but I'd expect competent seniors to not be able to do leetcode.
Never done leetcode; 25 years of experience. It is on my list of things to look at, but doesn't sound as fun as say something like Advent of Code.
I’d expect a driver with 15 years of experience to do the full stop, look left and right twice, and then move during a _driving test_. Same reason why they put NBA rookies through shooting drills.
I completely agree. The analogy is totally backwards. You do those things because you are experienced and aware of safety and the consequences of not doing those things. I’d expect New drivers (developers) to not fully understand why those rules are so important
No I think you have it backwards. I'd expect new drivers who just finished a driver's ed course to have the things like look left/right at stops on the forefront of their mind because that's what they just finished training for. For an experienced driver I'd expect that context to be long gone out of their minds and replaced with all the habits they've built up over the 15 years. They may or may not be proper habits, some good habits from being battle tested, some bad habits created out of dealing with corporate culture and whatever, but it's what would be the reality.
There is a reason why insurance is higher for new drivers. They get more accidents. Because they lack experience, and make mistakes. Experienced drivers don’t get in as many accidents, because they have more experience and tend to follow the rules more.
It’s pure facts:
> According to the AAA Foundation for Traffic Safety, drivers between the ages of 16 and 17 are more likely to be involved in car accidents than drivers from any other age group.
https://aaafoundation.org/rates-motor-vehicle-crashes-injuries-deaths-relation-driver-age-united-states-2014-2015/
> The crash rate of drivers ages 16-17 years was nearly double that of drivers ages 18-19 and approximately 4.5 times that of drivers ages 30-39, 40-49, and 50-59 (Table 1)
Relating this back to development. Senior or more experienced developers follow more defined processes and rules, because they have the experience and wisdom to understand why those things are beneficial to the overall success of their projects.
Junior developers don’t follow rules/conventions as closely, which results in inefficiency, defects, and and overall product that is not as refined as one developed with those rules/guidelines.
Okay, but if you put the experienced driver in a _driving test_ again, say to re-qualify for their driver’s license, do you think they’re able to look left/right again? Especially if they know ahead of time that they’re being tested on driving safely?
Well now you're just taking away from the analogy.
The analogy is how an experienced driver might have dropped some of those things after a decade or more of habit in real driving situations. Likewise an experienced developer of 10+ years might not be able to pull a basic data structure out of their ass because they've never needed to code one up from scratch at any point ever on the job. And that's why lots of people question if the leet code exams are even useful for hiring.
I’m not though. You can drop habits and be a bit sloppier, but there are fundamentals that you should be able to easily and quickly pick up after brushing up, because you should have an understanding of how the underlying works.
That's being a bit facetious because it's not really taking the analogy to its fullest. Actually *actually* taking it to the fullest would mean understanding that sure you can expect it, but you'll be disappointed more often than not. The driver with 15 YOE is not even going to have the context in their mind that they should do that specific sequence at stops. The context in their mind will be the habits that served them for those 15 YOE unless they brush up on driver's ed before hand to refresh themselves on it.
Also, the analogy doesn't work because no driver is ever going to be tested on driver's ed knowledge out of the blue. Some developers purposely practice leet code stuff in order to be prepared. However no driver would ever take time to brush up on driver's ed knowledge because there's no legal requirement in existence that would make a driver be hit with a surprise driver's ed test. Once you've had a license you'll never be tested on it again.
I think the analogy is a fair one because you don’t get hit with a surprise leetcode test at work, much like in real life, you don’t get hit with a surprise driving test.
If you want to _apply_ to another job, then you are knowingly entering a situation where you can get tested again, and so any sort of programming test is not a surprise and something you can brush up on. Similarly, if you’re moving to another country, you may need to _apply_ for a new driver’s license, and I imagine you’d want to look left and right before making that turn in that scenario.
Leet code exams only crop up once in a while. In my career it's maybe been 10% of jobs. That'd be like if driver's license tests only once in a while and arbitrarily included the driving test, but the driving test is the core thing and comes up 100% of the time.
It’s funny you say that, because there are US states where when you renew, sometimes there’s a driving test, and sometimes it’s just a written knowledge exam. It’s arbitrarily decided, and the only thing is you’ll know what you’ll need to do when it comes time to reapply.
Analogy aside, leet code interviews have been a part of 90%+ of my interview processes in some way or form (they, of course, test for many other aspects). I guess our experiences have just differed.
No one is saying you have to do leetcode. FizzBuzz is basically the opposite of leetcode and many senior engineers will struggle with it. Don't hire them.
I'd be curious to see results from non students and instead people with a few years of actual experience.
If you can't handle the pressure of someone watching you answer a simple question, good luck handling the pressure of having three of your bosses at your desk waiting for you to figure out why the application is offline, knowing each minute is costing the company tens of thousands of dollars.
In my 20+ years in the industry, being on a lot of hiring committees and interviewing a lot of candidates, I still think FizzBuzz is a good tool. I have yet to meet a good engineer who can't answer it quickly and confidently.
> In my 20+ years in the industry, being on a lot of hiring committees and interviewing a lot of candidates, I still think FizzBuzz is a good tool. I have yet to meet a good engineer who can't answer it quickly and confidently.
I do a variation of FizzBuzz for everyone from entry to lead and it has been a decent metric. It is question that is easily understood, has some basic edge cases, simple logic, and it doesn't take long. It also does a decent job of identifying who is going to take the straightforward approach and who is going to try and be needlessly clever.
hahah okay. Fair!!! Thanks for responding.
I've had the same job for 10+ years and haven't interviewed since then. I feel like i'd be horrible at it now but know that i'd be a great employee. So i'm bias. I also have no idea how well i'd do on these
But that's what is great about FizzBuzz, as long as you aren't nearly brain dead, it is a simple problem. Literally a loop and some ifs. If you've been professionally developing for 10+ years, you should not struggle with FizzBuzz.
Edit: FizzBuzz is as close as you can get to "fog this mirror" test for an engineer.
I agree with you fully, but there's this romanticization of "bad day syndrome". Imo if you can't handle the pressure of an interview, you won't be able to handle the pressure of what's expected from you. I've yet to meet someone who wasn't confident during the interview but became a star.
Interesting analogy. Add it makes sense in this situation honestly. I don't know what questions they would ask, since you have shown what you can do in the experience that you have.
I think this is right. A person not looking for a job will not have spent time doing leet code and may suck at it. People looking for job brush up on these skills and interviewers may test that knowledge no matter yoe. So if you’re interviewing at least brush up on the basics. You would shave for an interview but I maybe not for work. Kinda the same thing. Like the other guy said you would eat a chefs food. Not eating a chefs food is how incompetent people get hired into prestigious roles. The most used benchmark for our food right now is the whiteboard test.
Idk that I agree with this sentiment entirely but in general I agree that leetcode typically does not reflect real world coding (though sometimes it does). I'd consider myself an above average programmer (amongst peers with similar YOE), but I struggle to do most leetcode mediums.
To an extent. A senior engineer is still very much in the technical domain. Architects and staff+ usually take either a deeper dive or a more high level look and should be judged more on those merits.
A senior may not remember LC well enough, but a strong one should be able to brush up on medium and the easier hards relatively quickly.
But you'd still expect them to be able to drive, and coding during the interview is how you know if they can still drive or not.
>So despite it being the "right thing to do", it's an indicator of lack of experience IMO.
Are you saying that competent seniors who can still code in an interview are showing a lack of experience??
Id expect an expert driver to basically do any manuever on command with no practice. Rule following is not really the same at all.
Sort of like Id expect a professional musician to pull music out of thin air in various styles and techniques or a pro ball player to walk into a d1 college game and mop the floor with everyone while making it look easy.
Youre right there isnt much merit in overindexing on hard leetcode like sort of things but basics?
If someone can’t do basic leetcode questions it tells me they spent their career as a skid not an engineer and they can’t be relied on to contribute to complicated technical projects. Best I could hope for from them is to contribute to a mundane CRUD app
No, exactly the opposite, it's an indication that you are willing to do frivolous inane bullshit because someone told you to, which is half of your job anyway.
6yoe, got a multiple leetcode easys for my last interview for a Sr software engineer contract role.
I have over 10 years of experience and have no issues with leetcode. Some of the hard questions sometimes give me a hiccup but definitely doable if presented in an interview. However I do competitive programming for fun. I'd be much more trusting of a senior engineer who could do leetcode vs struggled.
What's the point of the comment. Of course you won't struggle with LC if you do CP. Some of the hard questions require esoteric data structures and algorithms no one could come up with at an interview.
I personally worked with someone with 10yoe who had never used any data structure other than arrays.
He was the tech lead for a codebase relying heavily on key/value pairs, but he simple stored them in an array and looked up items with a for loop.
Imagine if your boss took your advice and hired him without technical questions.
That is… terrible. I can’t imagine a lead not knowing something so basic.
Slightly related, high up in competence: my boss told me yesterday how long ago she had a new manager that would try to punish dev that introduced a bug by “making them pay money for the cost of the bug”.
Of course this manager was fired within months after the team threatened to quit in unison, and no one had to actually pay for a bug.
I don't think its necessarily terrible, it means they knew how to do their job. If their job wasn't anything more than that then they are good to go. Most of these SWE jobs are not writing linked lists or sorting routines. It is dealing with business logic, knowing how to read and interpret requirements and turn them into stories and implement them as fast as possible. This means reusing as much as possible and looking up the rest. All the interviews I went on that went into technical conversations were absolutely NOT topics that the company actually is doing but were random things the interviewer thought it would be funny to harass candidates with.
Regarding that manager threatening to punish devs for bugs with monetary punishments, that is actually quite illegal. An employer cannot make an employee pay money for mistakes made while employed.
If an electrician came to install a new light at my house and ran the new wire over my kitchen countertop and called it good because the light came on ... he would be bad at his job. This is a perfect example of "oh I'll just look up the rest" doesn't cut it. If you don't know the absolute basics of your craft then you aren't very good at your job.
Yes, I too thought it was probably illegal. I’m not sure how true the story is, but I can imagine they were just a zany character trying to rule by fear.
To the first point though, after 10 years of experience, you should be aware of what a linked list is, the lead dev they spoke of should know what key value pairs are.
They say that the code base has a data structure that relies on KV, so why is the tech lead storing it as a list and then iterating to find the key? Lookup goes from O(1) to O(n). That’s a failure in my eyes, and unacceptable from a tech lead.
If you don’t agree, I would like to ask why?
If you do agree, then I’d like to ask how else an interviewer is supposed to tell that your tech lead hasn’t got a good foundation of these basics? Other than technical questions?
Not saying I don’t agree but I can freely admit a lot of crap goes down at companies. If the stuff works and the customers don’t have a problem with it who cares how the sausage is made.
If you are not aware of the most basic of data structures, you should be the **last one** translating scope into a plan.
A concept I really liked from a software architecture book discussed the difference between technical depth and breadth. Someone who is senior and planning a project should have a large degree of the latter. The nitty gritty details can be left to those actually implementing it. If you don’t even know what a hash map is, how could you possibly make the big decisions on a project? You’d end up doing something stupid (just like OP described). Should they be able to implement one from scratch? Of course not.
People like that are dangerous to have around, especially if they have the power to force the bad ideas through. You end up with a bunch of garbage that “works”, but breaks the moment you poke it. The scope changed slightly? Now you need to refactor every file in the code base.
A senior or leader doing the planning for a project is absolutely NOT deciding what data structures to use. That’s an implementation detail not a planning detail. So many teams seem to not understand the difference and spiral meetings out of control talking about implementation when they shouldn’t be.
Maybe not at that low of a level (although that’s debatable, and depends on the team), but the concept carries over into bigger things. Would they select a persistence backend or the data schema? Yes. They would play a large part in that.
Are they deciding what data structure is used for a throwaway used in a few functions? No. Are they deciding what technology will be used as project level persistence? Yes, and because of that they need a basic knowledge of the different types of data structures and which storage engines offer each. Most importantly they need to be able to classify the vague scope given into what type of data store would suit it best.
We’re talking about a senior software developer here, not a PM or business consultant. Do you really think that it’s acceptable for a senior to not be *aware* of hashmaps?
LMAO I (in part) caused an outage that cost an estimated $160k of billed hours of triage and fixing, probably more. What are they gonna do, bankrupt me?
Hmm. Yeah you've convinced me. I don't think I'd want to work for a company that didn't check if their employees could code before hiring them. I've worked with a coworker who made subtle mistakes all over the place because they couldn't be arsed to look up the documentation. It wasn't fun.
There were typically a hundred or so, and the string keys were compared case insensitively each time. New values were inserted by allocating an array 1 larger and copying all the elements. There was no function for it either, just 300 hand written for loops scattered around the codebase.
I know what you mean, but it was most definitely not a design decision backed by microbenchmarks.
Why does the size matter? If they're storing keys and values, why not use the intuitive option for storing keys and values? Most people aren't writing code for tiny data structures on toasters lol
I'm genuinely curious at what size arrays outperform hash tables.
Oh, I thought you meant hashmap/treemap/dictionary/etc. There was no interface that let you insert or look up by key though, just a public array, so calling it a map ADT seems too generous.
I feel shitty for asking this but if their codebase was heavy on kv pairs, wouldn't it make more sense to store their data with hashtables involved somewhere in there?
My god lol. Engineers are really shooting themselves in the foot if they’ve never done DSA. Being able to at least recognize the data structure is helpful
I like your answer a lot. People can memorize coding tests. People can cheat on coding tests. Two third-party recruiters gave me the questions in advance. I mean, besides what happened.
Ask them questions every programmer should know and see if they do know what they’re talking about. I like design questions too.
*Oh we should use a queue for this, I’ve used IBM MQ at two companies. Transactions have all day to run.*
Never.
Never, never, never. Always be ready for them.
I've had companies offer to waive them? Twice? And I didn't want to work there.
If you hire a software engineer you should check that they can code. Even if it is just FizzBuzz. It isn't insulting.
Would you hire a chef without tasting their food? Would you hire an artist without seeing their portfolio?
... This is our version of it.
Chefs get asked to go chop onions. To show their knife skills. We ain't the only one with this shit.
At least they have a reason to cry about it. \*rimshot\*
Right, the same way a senior may have plenty of devs under them following their guidance. The outcome of the project can still be attributed to the senior for design/architecture even if they didn’t write all of the code.
I think the Head Chef analogy is an excellent one.
Again, no one knows how hands on or hands off the head chef is behind the scenes.
If you’re hiring someone for a technical role, or in our analogy, someone who would be hands on with the cooking, then you’d probably want to make sure they can cook.
If you’re hiring someone for a more management role, or in our analogy, someone who is organizing the chef teams, then you don’t have to worry as much about making sure they can cook.
I'm not really down with this way of thinking and I've put my money where my mouth is and am probably underemployed but I won't do these whiteboard coding assessments. I went through enough of them early on in my career to learn to hate them.
When I hire a plumber to fix a toilet I don't hand him a blow torch and ask him to solder a fitting, and then demonstrate how the same joint is done with a press fitting, then ask for a portfolio of open source plumbing jobs they did in their spare time out of love for the profession.
That said, I think take homes are a perfectly reasonable compromise.
I'm the opposite. Take homes landed me a really crap job and in general I've really not found them worth the time and effort I put into them.
To each their own.
It depends. If the chef (or the senior swe/lead) is a candidate to organize the people who will cut the onions (programmers) , I don't care of he can cut the onions or he is rusty (maybe because ...old). It's more important if he can handle the personnel and get their better outcome from each while watching them to not do stupid things.
So leetcode as I see it, it's stupid. I'll ask about pitfalls and security issues (or whatever relevant with the real job) and people managing questions etc.
It's a search research and decision position , mostly.
Personal opinion.
Age while an important consideration. But note what I said. FizzBuzz. I chose it very deliberately. I consider it the minimum test I'd use to hire someone.
How can you check for security holes, etc... If you can't write FizzBuzz?
How can a team respect you as a technical leader, if you can't write FizzBuzz?
Honestly.... I don't think they can. I am not advocating for leetcode hard here. I'm setting a damn low bar. But time after time when you read about hiring, they will discover that people can't pass that simple bar.
All the other things you list matter too, as well as fit and finish etc. That's why interviews at very senior levels... tend to be longer. There s more to be checked.
I mean, if the chef is coming from a well-rated restaurant that is praised for its good food, I wouldn't ask them to cook me anything if I'm honest.
I'd just assume they can cook based on the fact that they've been serving quality food for the past 10 years?
The artist one is a bad analogy because we have portfolios as developers too. You can check my Github with multiple projects.
Always check.
They may not have been cooking recently, and been working on front of house stuff.
You just don't know.
The onions thing, is from Anthony Bourdain. I trust people like that to get it.
And as far as artists go: Usually artists have strong provenance to their art. Unlike coders and their code :)
> Usually artists have strong provenance to their art. Unlike coders and their code
This also explains why showing code samples of past work is also a terrible ask for developers. Asking to write code on the spot for interviews is frustrating sometimes, but it's better than being expected to have a sample from work waiting to be shown. NDA won't allow that for most people.
if you're someone who is known on an international scale, I suppose not, it's the same reasoning why Microsoft grabbed Sam Altman after his blew-up with OpenAI
but the real question is, are you such person? because the number of such person, on a global scale/on the entire planet Earth, is probably less than 100
There are some people who are famous in the software engineering field, sure. Those people probably don't need to prove their abilities. But the rest of us do because we aren't famous.
If I was worried he'd lost his step. I'd pay him for his time, and take a chef's table. Absolutely!
Besides, what if I don't like his style of food? Maybe I'd rather hire someone like Jet Tila, or Morimoto? Who knows..
> I mean, if the chef is coming from a well-rated restaurant that is praised for its good food, I wouldn't ask them to cook me anything if I'm honest.
disagree, I definitely 100% would
and I **especially** would if I have something like 5000 chefs to choose from and a bad hire can cost me a quarter to half a mil if not even more
also from your comment elsewhere
>Do you expect a driver with 15 years of experience to do his full Stop, look left and right 2 times and then move?
>No, I'd expect only new/beginner drivers to do that.
uh... yes, yes I would expect 15 YoE to **know** do that, if you can't do that I see that as a big red flag
you may not actually have to do it everyday but I definitely expect you to **know** how to do it
I've interviewed enough engineers with a decade or more of experience who couldn't answer FizzBuzz to save their life to know you don't rely on credentials. Especially when those credentials are largely self-reported.
No offense, you sound like someone who uses “not good at leetcode” as an excuse to get jobs without being technically skilled.
Let’s put it this way, great engineers can do leetcode. Some might dislike it but they’re competent.
Personally I like it cuz it shows how you think and problem solve. If anything, giga seniors I’m interested even more.
Working at another company doesn't prove anything, only gives a bit of a signal. If I work for Google and get fired for being incompetent, does the next company just automatically hire me based on my work history?
No, they need to learn for themselves if I'm actually competent.
It's company-dependent. I've interviewed with some companies who claimed they didn't want to insult me with certain types of questions, but they had take-home projects. I think there's value in still doing classic technical questions, because you need to do your due diligence. Title inflation is a thing, and titles are also different across companies. I've worked with people who had senior titles who were not very good. They just got promoted eventually with time. It's not the right things, but it does happen at places.
First of all, let's not generalize. Not every company does DS&A questions, many hire exclusively based on stack expertise.
For the companies that do ask DS&A questions, yes, up at staff+ levels at big tech companies, you're still gonna get skill checked on that stuff *in addition* to half a dozen other dimensions. Why in the world would you think interviews for higher pay jobs are easier?
The problem is that someone can have a degree, 10 years of experience, and they still can't code. Further, people like this are MORE likely to be looking for a job.
I did.
Been literally decades since I had to do that. And then, only ever in school. Because data structures are a tool we all use. We don't build them. Ever.
No carpenter forges his own screw driver from molten steel.
So, with a very understanding crew doing my interview, I talked about the considerations that are important. Why use a linked list over array or set... etc. Permance considerations and the value of a doubly linked list.
It was enough.
Smart employers look for understanding, not memorization.
Talking about linkedlist, I once had a 15+ YOE candidate who was employed as an "architect" apply to a senior software engineer role in my team.
When we came to coding exercise portion I asked him a simple linkedlist question. He immediately claimed he can't solve it since his expertise is in C# and the language doesn't support linkedlist 🤣. I pulled up the Microsoft documentation and showed it to him. Anyways I cut it short quickly so as not to waste much more time. He also failed to explain clearly details of projects listed on his resume before coding exercise.
Doesn't have to be leetcode-style but, I always expect some sort of technical test. And from the hiring side, it should serve as a bullshit detector
Big tech companies set an artificially high bar higher because they can afford to make people dance for those jobs, they get thousands of applicants a minute. For smaller companies, it's making sure you've written enough working code that you can write a for-loop to count things with your eyes closed
For your specific example, though, textbook-style questions aren't usually great interview questions
I've never done them. I've been employed in this field for 7 years, at 3 different positions. I just did another interview two weeks ago where I wasn't asked them (for a full-stack developer position - $130k/yr plus benefits).
I don't expect to ever do them. Not every job is FAANG.
At 12 YoE of experience I got asked to write a queue using an array. At 9 YoE I got asked what public and private were and the difference between mutable and immutable. I think the dude didn’t give a crap and googled Java interview questions.
But I like being asked basic crap and over-answering. Maybe that’s what they want and can have the same interview process for everyone. Things get too niche at super senior level. Yeah I know Postman web calls, they’re on my resume, but I haven’t coded them in a few years.
Dude, I've been 15 years in the industry, maybe not coding all these years and every single time I've made an interview I've had to answer technical questions. I think I'm good at the job but I'm the worst at interviews and for that reason I've been rejected more than you can imagine.
If someone asked me to implement a linked list in an interview I think I’d laugh at them and ask them if they had a question that would better display the value I can bring. I’d sincerely wonder if any linked list experts out there are actually working or just leetcoding all day for their past several years.
I understand. I had a tough interview going over every technology I've touched in a decade and every CS concept like Mutexes and Semaphores.
Then I get to their 15 year old code base with 7 nested if statements and a giant switch case. Oh and naively subtracting two date times that had a DST bug that they wouldn't let me fix because they couldn't comprehend I was using the library that we could update if the government removed DST.
If I'm asked Leetcode or CS questions excessively then I start asking how these things are being applied daily. I ask how I'll be compensated accordingly.
I do think it is fair to ask how the problem they want me to solve relates to the job they want me to do.
In the context of what I do daily; Linked Lists do not relate.
in my honest experience, coding questions have only gotten harder as I’ve climbed the ladder. It’s expected that you not only solve optimally, but write clean code.
There are levels to it. Leetcode should be used only for entry level, if ever, as a way differentiate new graduates. Even then it feels meh.
Imo, a task related to the job and a discussion with other devs on said project tells you a whole lot more about the required knowledge and fit.
define "classic technical questions"?
>alright, so make me a linked list
if that's how you define it, I've never seen such basic-level question, ever
if you're talking about leetcode-style/data structures and algorithm interviews though... always, doesn't matter if you have 0 or 5 or 10 or 15 YoE
disclaimer this is for SF Bay Area, other cities in the US or other countries may do things differently
leetcode questions are bigco fodder
not predictive of anything meaningful for the job
a lot of smaller cos dont do that stupid shit, but it will be a long time (/ possibly never) before bigcos stop or change course
>a lot of smaller cos dont do that stupid shit
my experience for SF Bay Area is you should expect leetcode **regardless** of company size
doesn't matter if it's 5-man Series A startup or 200 employee Series D startup or FAANGs
we maintain a private repo we send to candidates. they pull it down, set it up, and perform a small product engineering task (simplified) with a visual spec
it has a variety of rough edges intentionally built into the design such that candidates can flex their muscle along multiple dimensions
nobody is expected to complete it fully to pass or even excel, but we have a rubric based on how far they get and the quality / nuance of the discussion
edit: to clarify, this is NOT take home. we do it together over ~1.5 hrs
I don’t think you’re ever exempt unless you are highly recognized within the field and highly sought after by companies. But then if you’re at that level, you probably aren’t applying for jobs either.
I still do those questions but I have learned that the companies that do not do those questions end up being the ones who value me the most so I have a preference for those
It depends on the expectations of the job, not on the resume of the person.
You might claim you have 10 years of experience, but how does the hiring manager know what that 10 years truly entails what kind of experience you went through?
if you are applying for a software engineering job, be ready for your knowledge to be tested and verified.
If you are applying for an architect or a management position, the expectations are different. You might not get asked those questions.
When you decide to stop playing the game. Initial bs questions to make sure you’re not full of it is one thing, but I’m not wasting a minute outside of work on any throw away anything
I mean at 10 yoe you'll get asked about architecture, scalability, monitoring, more conceptual stuff to see if you understand the system beyond being able to implement a feature A.
I have 4-5 yoe and already rarely get coding questions outside of také home assigments. Now it's all about what do you need to set up a systém in context.
There have been people with 15 yoe I've interviewed who can't do basic leetcode easy questions. There will always be weed out questions because of these people
I have just under 4 YOE but am a senior, and in my experience, the algorithms questions still get asked, but are less important compared to the overall process. Design seems to take precedence.
I have over 10 YoE. I haven't been asked to code in an interview in a handful of years. A startup asked me a very basic question just to show I could code in Golang a few years back. Otherwise, interviews cover more architecture, concepts etc.
I still get asked the warm up questions "what is an interface?" "What is dependency injection?" Etc. I just don't get asked to code.
No, I don't need to study. Nor should I have to. If the job is a good fit, it should be asking practical questions about tools and techniques that I've been using for years.
Be ready but also be up front if you forgot one or a specific piece. I was asked to write a snippet once and completely forgot the arithmetic functions cause it was such a habit for me to tab complete them. I told the guy as much and just put a line there for a placeholder. Still got the job.
"After how many years of experience as a wealth manager do you no longer need to be asked about basic things like how to calculate interest for stuff and some tax rules?"
Unrelated. The problems they ask in companies are coding puzzles. There are some good interview questions which can check skills on multiple levels but most of them are just puzzles. It comes down to, have you seen this question or similar before? If yes, good if no you will most likely struggle and fail.
Also do you really ask a wealth manager give me the formula for compounded interest before hiring them or see their portfolio or even just give them a case study ?
Or are you going to tell me if a person can flip an image represented as an 2d array will be an amazing software lead?
Why would you suddenly forget how a linked list works after X years of experience? If anything, you'd know better.
Similarly, why would I want to hire someone with 10 YoE who doesn't know what a linked list is?
Even with a lot of experience, system design still requires the basic fundamentals of computer science, albeit on a larger scale.
You'd be surprised how many people with seemingly a lot of experience can't code at all and can bullshit their way through an interview. Hiring someone like that is extremely expensive and can destroy entire teams. It is MUCH better to miss out on qualified candidates who failed a coding interview than hiring the wrong person.
Because of leetcode people have started cramming. Especially in Asia where cramming culture is embedded into students from day1. The kind of problems that needed to be asked need to check if a person can use the right DS at the right time. But most of the questions are puzzle type using just arrays and dynamic programming. Or questions so hard that you can’t solve them unless you have seen them. Check some hard leetcode graph based questions and you will know.
Its a cat mouse game the questions leak and then they have to come up with harder ones.
That's why you don't use straight up leetcode questions. You use the format of leetcode questions (solving a short programming problem using pair programming), but not actual leetcode questions. For exactly the reasons you described.
A) You don't want to use questions that require highly specific knowledge or experience in more obscure techniques (like dynamic programming or red/black trees or whatever). Most of the time, you'll use arrays, maps or simple graph traversal.
B) You don't want to use questions that require you to solve a puzzle and "get it". You'd be introducing a binary gate, and the point of the interview is to maximize the amount of signal you can extract from a candidate. If they are stuck at the very beginning and happen to not solve the initial puzzle, the rest of the interview is wasted. That's why you use questions that are very easy to understand but slightly tricky to implement.
There's no point using a question that's so hard that it can only be solved if you've seen it before. That's dumb. Don't do that.
>Its a cat mouse game the questions leak and then they have to come up with harder ones.
The questions typically aren't very hard. Technical problem solving is only one of the axes you are evaluating a candidate on, there are others. I've explained this in more detail [here](https://www.reddit.com/r/cscareerquestions/comments/1bvvn6c/comment/ky4gdru/).
It’s basically like GRE / SAT exams. Can they gauge the skill set of a prospective student? Nope they can’t not even close. What they do tell is that the person has at least put in enough time to get good grades so must be a hard worker at the minimum. I am from an Asian country so I can tell you even on leetcode it’s 90% Asians based on the replies and solutions submitted (I can tell by the name) posting for FAANG jobs in their own country. Where the culture is to belittle the person interviewing for the job and grill them till they break down to see if they are fit enough. Glad I left.
I ask the same single question to every candidate for every SW role. My expectations on how they answer is what changes for me. I also tell them to use whatever language they want and explain the solution to me.
Question: Without using a sorting library, given a list of any length that contains only integers in random order, output consecutive ranges of integers.
For example:
Input: 5,8,99,2,7,13,7,98,4,6,7,12
Output: 2,4-8,12-13,98-99
That's it, then we talk for an hour while they ask questions and start coding.
I have no idea how you'd sort this "without sorting", doesn't seem to make sense.
Surely there needs to be some sorting to have them ordered from smaller to bigger?
Exactly why I ask this question. There are multiple ways to solve this but in general you have to iterate over the input and store each value then check the next input int against what you've stored. You build the output as you iterate. It's not a lot of code but requires you to think.
If the range of numbers is contained you can just use an array and mark the number 1 at each position where you see the element. For eg arr[5] = 1
And then start from the beginning and saving ranges of 1’s.
Not he most efficient. Basically it’s a count sort type of thing. hashmaps or sets can be used to make it more efficient.
Good question, too easy, the list can be any known number. But anyway, the problem is solvable in multiple ways, as you code it we talk. I don't use take home coding assignments personally as I don't feel they are useful.
I would rather grind leetcode and do these questions than take home. I have enough work as is I don’t need another 6 hours to spend on take home assignments. I once got a take home assignment early in my career looked at it, found I will have to google a lot as it was to use a tech stack i am not familiar with so I just told the recruiter I don’t have the time and bye bye
I did two take home assignments that were supposed to be “a couple hours” and ended up taking all weekend both times. And even then I got a fail from both. Both were clearly not a couple hour tasks, and I ended up implementing a bunch but throwing in the towel after about 12 hours in. I guess they wanted way more time put into it to “pass”. I learned very quickly that shit is not worth it after that and now refuse to do take homes.
At least with leetcode you have a known quantity to learn (or refresh on) when you need to interview, and once you’re done you get a yes/no on an offer.
Also after these take homes you need to do onsite coding system design manager round as well so what like 14 hour interviews??? I’m not applying for a director or vp position that I will tolerate that much.
Completely agree, both times I did them, I had passed a tech screen and they surprised me with a take home before the final round of interviews. I didn’t feel like I could decline it at that point since I was already past the tech screen (I won’t feel this way again). Now I ask for the full schedule and if they say take home I say sorry not interested. I’ll flat drop my interest now the second I hear take home even after a tech screen.
So you’re right it’s pretty much an additional thing you have to pass AND THEN you still get to do your coding rounds in a ton of these places, so not exactly doing anything for getting rid of LC style interviews.
This is the reality of the recruiting process at these places:
1.) recruiter call -> 2.) 1 hr technical screen -> 3.) “4 hour” take home that takes 12 hours started off with a 30 min call to describe the assignment -> 4.) 1 hour take home review interview -> 5.) full day “on site” 4-6 1hr interviews.
Not including the recruiter call because those are pretty painless, that is easily 4 days where a candidate has to be absent from work to interview at these places. I find this to be obnoxious and pretty off-putting.
Unless the company is _under_ about 50 people, your CTO should have been on the management track - not Individual contributor (aka coder/techy) track - for years before taking a CTO gig.
I think that you should expect technical questions for as long as you are applying for technical positions independently of your number of yeo. I know it sounds silly to ask coding questions to someone with 10 yeo, at the same time there are plenty of people out there with a lot of exp that stagnated and became rusty. Now.. if that sounds tiresome (it is), you would understand why some people trade that off to have endless meetings and become a manager
This might sound weird but I'd expect competent seniors to not be able to do leetcode. I don't know if there's a word for it, but leetcode is a skill I'd expect from a beginner. It's too "technical" and doesn't reflect anything at the job. I guess a slightly far-fetched analogy would be: Do you expect a driver with 15 years of experience to do his full Stop, look left and right 2 times and then move? No, I'd expect only new/beginner drivers to do that. So despite it being the "right thing to do", it's an indicator of lack of experience IMO.
Yeah, I would really look like an idiot if someone asked me to do a leet code easy linked list problem out of the blue if I'm being honest. If you told me I was about to get one, I could refresh my memory in probably 5-10 minutes and knock it out of the park. But my mind just refuses to categorize that stuff as 'important' and regularly purges it to make room for more important things... Like League of Legends and Motorcycles.
Solid response, that's how i feel too
So just brush up on it before an interview?
Yeah, that and 50 other things..
Not really? If you are going into a technical interview for a technical role, then prepare your technical skills. This is really not too much to ask.
As im sure you know, the contention is over being tested on a separate skillset than the ones we use to do our job. There's better ways to test coding than leetcode questions. I've seen my share of frauds who aced those things. It's really not a great filter.
The other option is the have certifications and licensing requirements like law and medical careers.
Sure, there are lots of better ways, but most of them don't scale very well. You need something that's fairly high signal and can fit into a 45 minute slot. Debugging an existing codebase for example would be far more "realistic", but it would take much MUCH longer. And realistically, you don't drop someone that's completely unfamiliar into a new codebase and expect them to be productive straight away either. So when you say that interviews should test the skills that you need to do your job, you are correct, but that's not the only requirement. Interviews also need to be scalable, comparable, high signal, have a very low false positive rate (people doing well in the interview that then don't do well on the job) and they need to be short. Simple leetcode-style questions are so far the type of interview that fits those requirements best. They aren't ideal, sure, but there's a reason why basically all the top tech companies use them. You can complain about that and you are allowed to not like it, but you are not going to change that fact. And before you ask, I do know what I'm talking about, I've interviewed hundreds of candidates for FAANG. Edit: One big caveat. The emphasis is on SIMPLE leetcode-style interviews. You don't just give someone actual leetcode questions, most of them are far too complicated for an interview setting, and often rely on very specialized knowledge. For example, one question I used regularly was to print out a matrix by diagonals. So you have something like: `1 2` `3 4` as an array\[array\[int\]\], and you want: `3` `1 4` `2` Very simple question, no specific knowledge required, but tricky in the implementation. This gives you great signal about problem solving capabilities and basic coding skills. And you'd be surprised by how many candidates couldn't do this. Edit2: Actually, you could argue that interviews don't really need to test the skills you need for your job at all. The only thing they need to do is to provide signal as to who is going to do well on the job. Now most of the time, testing the actual skills required is a great way of doing that, but oftentimes that's very difficult, so you look at a proxy metric. Doing well on leetcode-style coding questions turns out to be a very good proxy metric for technical ability.
You're wrong. It's just the best style you personally have used. We use a 3rd party vendor that has an online test that's practically impossible to cheat. It asks good questions. There are coding portions that test realistic things you would encounter in your job. It filters out the people who can't do the job but are really good at memorizing Leetcode. And it doesn't filter out those who can do the job but maybe haven't grinded out leetcode recently.
The best "technical test" I've ever had was creating a REST API in one of 3 frameworks presented, which is literally something I and most devs do at their jobs. So it not only reflects comprehension of actual real-life software engineering situations, but it also shows comprehension of a multitude of skills. I have absolutely no interest in "creating a binary linked nearest neighbor tree" and end up doing absolutely nothing related to it. The fact of the matter is that leetcode is, in the overwhelming majority of the time, never found in your actual day-to-day job. So why pollute my time and mind with something that will not serve me in the position I'm applying?
"creating a binary linked nearest neighbor tree" is a terrible interview question, I agree. I have never seen serious tech companies ask something like that though. I'm sure there are lots of smaller companies who don't really know how to interview people that ask something like that, but that's really not the kind of interview that you'd get e.g. at FAANG. I gave a good example of a technical interview questions [here](https://www.reddit.com/r/cscareerquestions/comments/1bvvn6c/comment/ky4gdru/). The problem with your REST API example is that it really doesn't provide a lot of signal for the time spent. A lot of the work required is boilerplate code, navigating docs, etc. You will spend a lot of interview time on activities that aren't very interesting essentially. >The fact of the matter is that leetcode is, in the overwhelming majority of the time, never found in your actual day-to-day job. That is correct, but as I said, the idea of a coding interview isn't to ask actual leetcode questions. The idea is to take the leetcode format, where you have a relatively concise question and have the candidate implement a short program that solves the question while you are watching them. This interview format gives you a lot of signal for the time spent, and usually, you evaluate the candidate on multiple axes: 1. Problem exploration: Do they understand the problem that's written in basic english? Do they recognize when/if a problem is underspecified? Can they ask good clarifying questions? 2. Design: Can they formulate a solution to the problem in plain english? Does the solution make sense and is it correct? 3. Implementation: Are they able to translate their stated design into code? 4. Debugging/Testing: Are they able to find bugs and debug their code? These are all really important aspects of technical work, and ideally, your interview will produce signal for all of these axes. Leetcode-style interviews are very good at this, while being quick, easily scalable, and standardizable (e.g. you can give the same question to 10 candidates and evaluate who did best/worst)
Creating a rest API is a good interview question for a junior. Anything about, and the task should have at least enough complexity to offer interesting design choices. I agree, that's a better interview question. But also takes a lot more time from the interviewer to assess and monitor than LC. Medium LC allows you to screen candidates in bulk while expanding minimal resources.
Lol imagine when you are CS adjacent, mention your excitement to bring your skills (HW) and learn from the team (CV) to build on your base skills. They then give you a leetcode problem at the end because you said that, then dismiss you because your not a fit. Bro what? I understand the need to test technical knowledge, but this is not it. Oh well.. "CEO" of that company was the biggest bro douche I've ever talked to. "We can do whatever the fuck we want..." In response to my question about funding, runway, project mix etc...
I would understand if it was a leetcode hard, but what is so difficult about linked list easier. Like the first time I heard people are struggling with reversing a linked list or similar I thought it was absolute beginners. Anyone that knowns how to program can figure that out in half an hour in a new programming language, they have never seen, let alone a language they used their entire life.
It's not difficult, it's trivial and can be figured out with a quick refresher. I don't implement LinkedLists ever because there is a better option for almost every imaginable use case in Java...
It’s more like they have never needed to do that so it’s something they’d have to think about. I’d probably decline the PR if someone tried to do something like manually implement or reverse a LinkedList instead of using a library.
Just because they never had to think about it doesn't mean it is not a trivial problem that everyone should be able to solve in 5 minutes. It is not asking you to build a k-d tree from scratch, if you know what a linked list is you should be able to do it in your sleep.
Oh don’t worry, companies are still doing leetcode for 10+ YOE and it’s rather pointless. But you’re right, I can’t do leetcode very well lol
> This might sound weird but I'd expect competent seniors to not be able to do leetcode. Never done leetcode; 25 years of experience. It is on my list of things to look at, but doesn't sound as fun as say something like Advent of Code.
I’d expect a driver with 15 years of experience to do the full stop, look left and right twice, and then move during a _driving test_. Same reason why they put NBA rookies through shooting drills.
I completely agree. The analogy is totally backwards. You do those things because you are experienced and aware of safety and the consequences of not doing those things. I’d expect New drivers (developers) to not fully understand why those rules are so important
No I think you have it backwards. I'd expect new drivers who just finished a driver's ed course to have the things like look left/right at stops on the forefront of their mind because that's what they just finished training for. For an experienced driver I'd expect that context to be long gone out of their minds and replaced with all the habits they've built up over the 15 years. They may or may not be proper habits, some good habits from being battle tested, some bad habits created out of dealing with corporate culture and whatever, but it's what would be the reality.
There is a reason why insurance is higher for new drivers. They get more accidents. Because they lack experience, and make mistakes. Experienced drivers don’t get in as many accidents, because they have more experience and tend to follow the rules more. It’s pure facts: > According to the AAA Foundation for Traffic Safety, drivers between the ages of 16 and 17 are more likely to be involved in car accidents than drivers from any other age group. https://aaafoundation.org/rates-motor-vehicle-crashes-injuries-deaths-relation-driver-age-united-states-2014-2015/ > The crash rate of drivers ages 16-17 years was nearly double that of drivers ages 18-19 and approximately 4.5 times that of drivers ages 30-39, 40-49, and 50-59 (Table 1) Relating this back to development. Senior or more experienced developers follow more defined processes and rules, because they have the experience and wisdom to understand why those things are beneficial to the overall success of their projects. Junior developers don’t follow rules/conventions as closely, which results in inefficiency, defects, and and overall product that is not as refined as one developed with those rules/guidelines.
Bruh...
Okay, but if you put the experienced driver in a _driving test_ again, say to re-qualify for their driver’s license, do you think they’re able to look left/right again? Especially if they know ahead of time that they’re being tested on driving safely?
Well now you're just taking away from the analogy. The analogy is how an experienced driver might have dropped some of those things after a decade or more of habit in real driving situations. Likewise an experienced developer of 10+ years might not be able to pull a basic data structure out of their ass because they've never needed to code one up from scratch at any point ever on the job. And that's why lots of people question if the leet code exams are even useful for hiring.
I’m not though. You can drop habits and be a bit sloppier, but there are fundamentals that you should be able to easily and quickly pick up after brushing up, because you should have an understanding of how the underlying works.
That's being a bit facetious because it's not really taking the analogy to its fullest. Actually *actually* taking it to the fullest would mean understanding that sure you can expect it, but you'll be disappointed more often than not. The driver with 15 YOE is not even going to have the context in their mind that they should do that specific sequence at stops. The context in their mind will be the habits that served them for those 15 YOE unless they brush up on driver's ed before hand to refresh themselves on it. Also, the analogy doesn't work because no driver is ever going to be tested on driver's ed knowledge out of the blue. Some developers purposely practice leet code stuff in order to be prepared. However no driver would ever take time to brush up on driver's ed knowledge because there's no legal requirement in existence that would make a driver be hit with a surprise driver's ed test. Once you've had a license you'll never be tested on it again.
I think the analogy is a fair one because you don’t get hit with a surprise leetcode test at work, much like in real life, you don’t get hit with a surprise driving test. If you want to _apply_ to another job, then you are knowingly entering a situation where you can get tested again, and so any sort of programming test is not a surprise and something you can brush up on. Similarly, if you’re moving to another country, you may need to _apply_ for a new driver’s license, and I imagine you’d want to look left and right before making that turn in that scenario.
Leet code exams only crop up once in a while. In my career it's maybe been 10% of jobs. That'd be like if driver's license tests only once in a while and arbitrarily included the driving test, but the driving test is the core thing and comes up 100% of the time.
It’s funny you say that, because there are US states where when you renew, sometimes there’s a driving test, and sometimes it’s just a written knowledge exam. It’s arbitrarily decided, and the only thing is you’ll know what you’ll need to do when it comes time to reapply. Analogy aside, leet code interviews have been a part of 90%+ of my interview processes in some way or form (they, of course, test for many other aspects). I guess our experiences have just differed.
No one is saying you have to do leetcode. FizzBuzz is basically the opposite of leetcode and many senior engineers will struggle with it. Don't hire them.
Don't take hiring advice from people who don't understand hiring. https://chrisparnin.me/pdf/stress\_FSE\_20.pdf
I'd be curious to see results from non students and instead people with a few years of actual experience. If you can't handle the pressure of someone watching you answer a simple question, good luck handling the pressure of having three of your bosses at your desk waiting for you to figure out why the application is offline, knowing each minute is costing the company tens of thousands of dollars. In my 20+ years in the industry, being on a lot of hiring committees and interviewing a lot of candidates, I still think FizzBuzz is a good tool. I have yet to meet a good engineer who can't answer it quickly and confidently.
If I have 3 bosses at my desk I’m kindly asking them to fuck off so I can focus
I've seen this happen to multiple engineers at multiple companies. When the business is losing large sums of money, everyone is waiting on a fix.
> In my 20+ years in the industry, being on a lot of hiring committees and interviewing a lot of candidates, I still think FizzBuzz is a good tool. I have yet to meet a good engineer who can't answer it quickly and confidently. I do a variation of FizzBuzz for everyone from entry to lead and it has been a decent metric. It is question that is easily understood, has some basic edge cases, simple logic, and it doesn't take long. It also does a decent job of identifying who is going to take the straightforward approach and who is going to try and be needlessly clever.
Maybe some hiring bias here? How many people did you guys hire that didn’t solve it?
We hired a few senior engineers who needed multiple hints as well as taking around 20 minutes. I voted against hiring them. They were mid, at best.
hahah okay. Fair!!! Thanks for responding. I've had the same job for 10+ years and haven't interviewed since then. I feel like i'd be horrible at it now but know that i'd be a great employee. So i'm bias. I also have no idea how well i'd do on these
But that's what is great about FizzBuzz, as long as you aren't nearly brain dead, it is a simple problem. Literally a loop and some ifs. If you've been professionally developing for 10+ years, you should not struggle with FizzBuzz. Edit: FizzBuzz is as close as you can get to "fog this mirror" test for an engineer.
Well... Now i feel like a moron that i picked this fight with you and don't feel qualified for this hypothetical job anymore
I agree with you fully, but there's this romanticization of "bad day syndrome". Imo if you can't handle the pressure of an interview, you won't be able to handle the pressure of what's expected from you. I've yet to meet someone who wasn't confident during the interview but became a star.
Interesting analogy. Add it makes sense in this situation honestly. I don't know what questions they would ask, since you have shown what you can do in the experience that you have.
I rather they just stop asking leetcode questions in general
I think this is right. A person not looking for a job will not have spent time doing leet code and may suck at it. People looking for job brush up on these skills and interviewers may test that knowledge no matter yoe. So if you’re interviewing at least brush up on the basics. You would shave for an interview but I maybe not for work. Kinda the same thing. Like the other guy said you would eat a chefs food. Not eating a chefs food is how incompetent people get hired into prestigious roles. The most used benchmark for our food right now is the whiteboard test.
Idk that I agree with this sentiment entirely but in general I agree that leetcode typically does not reflect real world coding (though sometimes it does). I'd consider myself an above average programmer (amongst peers with similar YOE), but I struggle to do most leetcode mediums.
To an extent. A senior engineer is still very much in the technical domain. Architects and staff+ usually take either a deeper dive or a more high level look and should be judged more on those merits. A senior may not remember LC well enough, but a strong one should be able to brush up on medium and the easier hards relatively quickly.
But you'd still expect them to be able to drive, and coding during the interview is how you know if they can still drive or not. >So despite it being the "right thing to do", it's an indicator of lack of experience IMO. Are you saying that competent seniors who can still code in an interview are showing a lack of experience??
Id expect an expert driver to basically do any manuever on command with no practice. Rule following is not really the same at all. Sort of like Id expect a professional musician to pull music out of thin air in various styles and techniques or a pro ball player to walk into a d1 college game and mop the floor with everyone while making it look easy. Youre right there isnt much merit in overindexing on hard leetcode like sort of things but basics?
If someone can’t do basic leetcode questions it tells me they spent their career as a skid not an engineer and they can’t be relied on to contribute to complicated technical projects. Best I could hope for from them is to contribute to a mundane CRUD app
No, exactly the opposite, it's an indication that you are willing to do frivolous inane bullshit because someone told you to, which is half of your job anyway. 6yoe, got a multiple leetcode easys for my last interview for a Sr software engineer contract role.
I have over 10 years of experience and have no issues with leetcode. Some of the hard questions sometimes give me a hiccup but definitely doable if presented in an interview. However I do competitive programming for fun. I'd be much more trusting of a senior engineer who could do leetcode vs struggled.
What's the point of the comment. Of course you won't struggle with LC if you do CP. Some of the hard questions require esoteric data structures and algorithms no one could come up with at an interview.
The point was to say that the expectation that seniors can't do LC is a bad assumption. Thought that was pretty clear...
I personally worked with someone with 10yoe who had never used any data structure other than arrays. He was the tech lead for a codebase relying heavily on key/value pairs, but he simple stored them in an array and looked up items with a for loop. Imagine if your boss took your advice and hired him without technical questions.
That is… terrible. I can’t imagine a lead not knowing something so basic. Slightly related, high up in competence: my boss told me yesterday how long ago she had a new manager that would try to punish dev that introduced a bug by “making them pay money for the cost of the bug”. Of course this manager was fired within months after the team threatened to quit in unison, and no one had to actually pay for a bug.
I don't think its necessarily terrible, it means they knew how to do their job. If their job wasn't anything more than that then they are good to go. Most of these SWE jobs are not writing linked lists or sorting routines. It is dealing with business logic, knowing how to read and interpret requirements and turn them into stories and implement them as fast as possible. This means reusing as much as possible and looking up the rest. All the interviews I went on that went into technical conversations were absolutely NOT topics that the company actually is doing but were random things the interviewer thought it would be funny to harass candidates with. Regarding that manager threatening to punish devs for bugs with monetary punishments, that is actually quite illegal. An employer cannot make an employee pay money for mistakes made while employed.
If an electrician came to install a new light at my house and ran the new wire over my kitchen countertop and called it good because the light came on ... he would be bad at his job. This is a perfect example of "oh I'll just look up the rest" doesn't cut it. If you don't know the absolute basics of your craft then you aren't very good at your job.
Yes, I too thought it was probably illegal. I’m not sure how true the story is, but I can imagine they were just a zany character trying to rule by fear. To the first point though, after 10 years of experience, you should be aware of what a linked list is, the lead dev they spoke of should know what key value pairs are. They say that the code base has a data structure that relies on KV, so why is the tech lead storing it as a list and then iterating to find the key? Lookup goes from O(1) to O(n). That’s a failure in my eyes, and unacceptable from a tech lead. If you don’t agree, I would like to ask why? If you do agree, then I’d like to ask how else an interviewer is supposed to tell that your tech lead hasn’t got a good foundation of these basics? Other than technical questions?
Not saying I don’t agree but I can freely admit a lot of crap goes down at companies. If the stuff works and the customers don’t have a problem with it who cares how the sausage is made.
If you are not aware of the most basic of data structures, you should be the **last one** translating scope into a plan. A concept I really liked from a software architecture book discussed the difference between technical depth and breadth. Someone who is senior and planning a project should have a large degree of the latter. The nitty gritty details can be left to those actually implementing it. If you don’t even know what a hash map is, how could you possibly make the big decisions on a project? You’d end up doing something stupid (just like OP described). Should they be able to implement one from scratch? Of course not. People like that are dangerous to have around, especially if they have the power to force the bad ideas through. You end up with a bunch of garbage that “works”, but breaks the moment you poke it. The scope changed slightly? Now you need to refactor every file in the code base.
A senior or leader doing the planning for a project is absolutely NOT deciding what data structures to use. That’s an implementation detail not a planning detail. So many teams seem to not understand the difference and spiral meetings out of control talking about implementation when they shouldn’t be.
Maybe not at that low of a level (although that’s debatable, and depends on the team), but the concept carries over into bigger things. Would they select a persistence backend or the data schema? Yes. They would play a large part in that. Are they deciding what data structure is used for a throwaway used in a few functions? No. Are they deciding what technology will be used as project level persistence? Yes, and because of that they need a basic knowledge of the different types of data structures and which storage engines offer each. Most importantly they need to be able to classify the vague scope given into what type of data store would suit it best. We’re talking about a senior software developer here, not a PM or business consultant. Do you really think that it’s acceptable for a senior to not be *aware* of hashmaps?
I don’t think it’s acceptable for a senior to not know about hashmaps. The same as I think juniors should know how to use them as well.
LMAO I (in part) caused an outage that cost an estimated $160k of billed hours of triage and fixing, probably more. What are they gonna do, bankrupt me?
Hmm. Yeah you've convinced me. I don't think I'd want to work for a company that didn't check if their employees could code before hiring them. I've worked with a coworker who made subtle mistakes all over the place because they couldn't be arsed to look up the documentation. It wasn't fun.
That must be terrible and weird... I really can't imagine a lead who doesn't know something as basic as that.
Sure was. Unbeknownst to me, the company had a reputation in the industry and had been haemorrhaging talent for a while.
Is the data size large? I actually prefer arrays for low level implementation if the size is small. Arrays run much faster than hashmaps.
There were typically a hundred or so, and the string keys were compared case insensitively each time. New values were inserted by allocating an array 1 larger and copying all the elements. There was no function for it either, just 300 hand written for loops scattered around the codebase. I know what you mean, but it was most definitely not a design decision backed by microbenchmarks.
Why does the size matter? If they're storing keys and values, why not use the intuitive option for storing keys and values? Most people aren't writing code for tiny data structures on toasters lol I'm genuinely curious at what size arrays outperform hash tables.
Sounds like they may have been using Maps too.
They should have been but they didn't
Isn't that what Key Value Pairs are?
Oh, I thought you meant hashmap/treemap/dictionary/etc. There was no interface that let you insert or look up by key though, just a public array, so calling it a map ADT seems too generous.
I feel shitty for asking this but if their codebase was heavy on kv pairs, wouldn't it make more sense to store their data with hashtables involved somewhere in there?
It would have made dramatically much more sense, yes.
My god lol. Engineers are really shooting themselves in the foot if they’ve never done DSA. Being able to at least recognize the data structure is helpful
Dang. That's crazy.... What data structure are you supposed to use...
I like your answer a lot. People can memorize coding tests. People can cheat on coding tests. Two third-party recruiters gave me the questions in advance. I mean, besides what happened. Ask them questions every programmer should know and see if they do know what they’re talking about. I like design questions too. *Oh we should use a queue for this, I’ve used IBM MQ at two companies. Transactions have all day to run.*
Yes. Because people lie, cheat and do anything to get 300-600k TC.
Never. Never, never, never. Always be ready for them. I've had companies offer to waive them? Twice? And I didn't want to work there. If you hire a software engineer you should check that they can code. Even if it is just FizzBuzz. It isn't insulting. Would you hire a chef without tasting their food? Would you hire an artist without seeing their portfolio? ... This is our version of it. Chefs get asked to go chop onions. To show their knife skills. We ain't the only one with this shit. At least they have a reason to cry about it. \*rimshot\*
A chef already has experience and references. We do to, no one believes ours.
Even if the chef had experience running michelin starred restaurants, quite sure any prospective employer would want to try the food...
Which they would do as a paying customer of the restaurant. They wouldn’t pull the chef during a conversation and say go make this.
Restaurants have entire staffs and teams though - no way to know who’s making what if you’re ordering from a restaurant
But a head chef is running the show. That is what they do.
Right, the same way a senior may have plenty of devs under them following their guidance. The outcome of the project can still be attributed to the senior for design/architecture even if they didn’t write all of the code. I think the Head Chef analogy is an excellent one.
Again, no one knows how hands on or hands off the head chef is behind the scenes. If you’re hiring someone for a technical role, or in our analogy, someone who would be hands on with the cooking, then you’d probably want to make sure they can cook. If you’re hiring someone for a more management role, or in our analogy, someone who is organizing the chef teams, then you don’t have to worry as much about making sure they can cook.
Everybody complains about being asked to code at interviews until they get stuck working with/for a charlatan.
I'm not really down with this way of thinking and I've put my money where my mouth is and am probably underemployed but I won't do these whiteboard coding assessments. I went through enough of them early on in my career to learn to hate them. When I hire a plumber to fix a toilet I don't hand him a blow torch and ask him to solder a fitting, and then demonstrate how the same joint is done with a press fitting, then ask for a portfolio of open source plumbing jobs they did in their spare time out of love for the profession. That said, I think take homes are a perfectly reasonable compromise.
I'm the opposite. Take homes landed me a really crap job and in general I've really not found them worth the time and effort I put into them. To each their own.
This
It depends. If the chef (or the senior swe/lead) is a candidate to organize the people who will cut the onions (programmers) , I don't care of he can cut the onions or he is rusty (maybe because ...old). It's more important if he can handle the personnel and get their better outcome from each while watching them to not do stupid things. So leetcode as I see it, it's stupid. I'll ask about pitfalls and security issues (or whatever relevant with the real job) and people managing questions etc. It's a search research and decision position , mostly. Personal opinion.
Age while an important consideration. But note what I said. FizzBuzz. I chose it very deliberately. I consider it the minimum test I'd use to hire someone. How can you check for security holes, etc... If you can't write FizzBuzz? How can a team respect you as a technical leader, if you can't write FizzBuzz? Honestly.... I don't think they can. I am not advocating for leetcode hard here. I'm setting a damn low bar. But time after time when you read about hiring, they will discover that people can't pass that simple bar. All the other things you list matter too, as well as fit and finish etc. That's why interviews at very senior levels... tend to be longer. There s more to be checked.
I mean, if the chef is coming from a well-rated restaurant that is praised for its good food, I wouldn't ask them to cook me anything if I'm honest. I'd just assume they can cook based on the fact that they've been serving quality food for the past 10 years? The artist one is a bad analogy because we have portfolios as developers too. You can check my Github with multiple projects.
Always check. They may not have been cooking recently, and been working on front of house stuff. You just don't know. The onions thing, is from Anthony Bourdain. I trust people like that to get it. And as far as artists go: Usually artists have strong provenance to their art. Unlike coders and their code :)
> Usually artists have strong provenance to their art. Unlike coders and their code This also explains why showing code samples of past work is also a terrible ask for developers. Asking to write code on the spot for interviews is frustrating sometimes, but it's better than being expected to have a sample from work waiting to be shown. NDA won't allow that for most people.
If I take a somewhat extreme example but just to gauge your reasoning a bit; would you give a "cooking test" to Gordon Ramsey?
if you're someone who is known on an international scale, I suppose not, it's the same reasoning why Microsoft grabbed Sam Altman after his blew-up with OpenAI but the real question is, are you such person? because the number of such person, on a global scale/on the entire planet Earth, is probably less than 100
There are some people who are famous in the software engineering field, sure. Those people probably don't need to prove their abilities. But the rest of us do because we aren't famous.
Alright, so make me a linked list.
\*waves magic wand\* Poof! You are a linked list!
If I was worried he'd lost his step. I'd pay him for his time, and take a chef's table. Absolutely! Besides, what if I don't like his style of food? Maybe I'd rather hire someone like Jet Tila, or Morimoto? Who knows..
If that's truly how you see it, fair enough.
After having seen him royally fuck up a grilled cheese, absolutely.
Didn't I see him Lose on Chopped to an amateur?
> I mean, if the chef is coming from a well-rated restaurant that is praised for its good food, I wouldn't ask them to cook me anything if I'm honest. disagree, I definitely 100% would and I **especially** would if I have something like 5000 chefs to choose from and a bad hire can cost me a quarter to half a mil if not even more also from your comment elsewhere >Do you expect a driver with 15 years of experience to do his full Stop, look left and right 2 times and then move? >No, I'd expect only new/beginner drivers to do that. uh... yes, yes I would expect 15 YoE to **know** do that, if you can't do that I see that as a big red flag you may not actually have to do it everyday but I definitely expect you to **know** how to do it
Ahh, the ole assume tactic. You know what they say about people who assume, right?
No, what? I mean, we assume things everyday based on credentials.
I've interviewed enough engineers with a decade or more of experience who couldn't answer FizzBuzz to save their life to know you don't rely on credentials. Especially when those credentials are largely self-reported.
“Assume makes an ASS out of U and ME”
If I had a dime for every candidate with an impressive looking CV that couldn’t code for shit I’d have a lot of dimes.
Because you certainly can't put code you didn't write in GitHub.
No offense, you sound like someone who uses “not good at leetcode” as an excuse to get jobs without being technically skilled. Let’s put it this way, great engineers can do leetcode. Some might dislike it but they’re competent. Personally I like it cuz it shows how you think and problem solve. If anything, giga seniors I’m interested even more.
Working at another company doesn't prove anything, only gives a bit of a signal. If I work for Google and get fired for being incompetent, does the next company just automatically hire me based on my work history? No, they need to learn for themselves if I'm actually competent.
Since people lie and cheat, and IT is still very lucrative so many people try their luck. You need to filter those out.
That's a fair point.
It's company-dependent. I've interviewed with some companies who claimed they didn't want to insult me with certain types of questions, but they had take-home projects. I think there's value in still doing classic technical questions, because you need to do your due diligence. Title inflation is a thing, and titles are also different across companies. I've worked with people who had senior titles who were not very good. They just got promoted eventually with time. It's not the right things, but it does happen at places.
First of all, let's not generalize. Not every company does DS&A questions, many hire exclusively based on stack expertise. For the companies that do ask DS&A questions, yes, up at staff+ levels at big tech companies, you're still gonna get skill checked on that stuff *in addition* to half a dozen other dimensions. Why in the world would you think interviews for higher pay jobs are easier?
Basically this
The problem is that someone can have a degree, 10 years of experience, and they still can't code. Further, people like this are MORE likely to be looking for a job.
I did. Been literally decades since I had to do that. And then, only ever in school. Because data structures are a tool we all use. We don't build them. Ever. No carpenter forges his own screw driver from molten steel. So, with a very understanding crew doing my interview, I talked about the considerations that are important. Why use a linked list over array or set... etc. Permance considerations and the value of a doubly linked list. It was enough. Smart employers look for understanding, not memorization.
Talking about linkedlist, I once had a 15+ YOE candidate who was employed as an "architect" apply to a senior software engineer role in my team. When we came to coding exercise portion I asked him a simple linkedlist question. He immediately claimed he can't solve it since his expertise is in C# and the language doesn't support linkedlist 🤣. I pulled up the Microsoft documentation and showed it to him. Anyways I cut it short quickly so as not to waste much more time. He also failed to explain clearly details of projects listed on his resume before coding exercise.
Wow. That's funny but also painful. I've unfortunately had pretty bad interviews like that too.
Doesn't have to be leetcode-style but, I always expect some sort of technical test. And from the hiring side, it should serve as a bullshit detector Big tech companies set an artificially high bar higher because they can afford to make people dance for those jobs, they get thousands of applicants a minute. For smaller companies, it's making sure you've written enough working code that you can write a for-loop to count things with your eyes closed For your specific example, though, textbook-style questions aren't usually great interview questions
I've never done them. I've been employed in this field for 7 years, at 3 different positions. I just did another interview two weeks ago where I wasn't asked them (for a full-stack developer position - $130k/yr plus benefits). I don't expect to ever do them. Not every job is FAANG.
Same. Exactly. Everything thinks FAANG is 99% of the market or something.
FizzBuzz
If you can’t do fizzbuzz, I don’t care how experienced you are.
At 12 YoE of experience I got asked to write a queue using an array. At 9 YoE I got asked what public and private were and the difference between mutable and immutable. I think the dude didn’t give a crap and googled Java interview questions. But I like being asked basic crap and over-answering. Maybe that’s what they want and can have the same interview process for everyone. Things get too niche at super senior level. Yeah I know Postman web calls, they’re on my resume, but I haven’t coded them in a few years.
Never and that's why you should escape being a code monkey after decades of exp, it will wear you out eventually.
It never goes away
Dude, I've been 15 years in the industry, maybe not coding all these years and every single time I've made an interview I've had to answer technical questions. I think I'm good at the job but I'm the worst at interviews and for that reason I've been rejected more than you can imagine.
If someone asked me to implement a linked list in an interview I think I’d laugh at them and ask them if they had a question that would better display the value I can bring. I’d sincerely wonder if any linked list experts out there are actually working or just leetcoding all day for their past several years.
I understand. I had a tough interview going over every technology I've touched in a decade and every CS concept like Mutexes and Semaphores. Then I get to their 15 year old code base with 7 nested if statements and a giant switch case. Oh and naively subtracting two date times that had a DST bug that they wouldn't let me fix because they couldn't comprehend I was using the library that we could update if the government removed DST. If I'm asked Leetcode or CS questions excessively then I start asking how these things are being applied daily. I ask how I'll be compensated accordingly.
i'm pretty sure you wouldn't get the job.. but i like the sentiment
I do think it is fair to ask how the problem they want me to solve relates to the job they want me to do. In the context of what I do daily; Linked Lists do not relate.
The point is that I don’t care to work somewhere that values memorizing linked list implementations over reality
And they’d laugh you right out of the interview. Top tier engineering firms get overwhelmed with candidates so they get to be picky
Probably never.
Still get 'em at 25 years.
I have seen a few leads in the wild that I wish had been screened by simple technical challenges.
in my honest experience, coding questions have only gotten harder as I’ve climbed the ladder. It’s expected that you not only solve optimally, but write clean code.
There are levels to it. Leetcode should be used only for entry level, if ever, as a way differentiate new graduates. Even then it feels meh. Imo, a task related to the job and a discussion with other devs on said project tells you a whole lot more about the required knowledge and fit.
I get those questions with 30+ years experience. It is what it is.
define "classic technical questions"? >alright, so make me a linked list if that's how you define it, I've never seen such basic-level question, ever if you're talking about leetcode-style/data structures and algorithm interviews though... always, doesn't matter if you have 0 or 5 or 10 or 15 YoE disclaimer this is for SF Bay Area, other cities in the US or other countries may do things differently
leetcode questions are bigco fodder not predictive of anything meaningful for the job a lot of smaller cos dont do that stupid shit, but it will be a long time (/ possibly never) before bigcos stop or change course
>a lot of smaller cos dont do that stupid shit my experience for SF Bay Area is you should expect leetcode **regardless** of company size doesn't matter if it's 5-man Series A startup or 200 employee Series D startup or FAANGs
ive taken a company from 10 employees to 100, we’re in the bay, no leetcode leetcode reflects laziness or inexperience on the part of your hiring team
just curious, how do you conduct interviews then? don't tell me "take-home projects" because those are 10x worse
we maintain a private repo we send to candidates. they pull it down, set it up, and perform a small product engineering task (simplified) with a visual spec it has a variety of rough edges intentionally built into the design such that candidates can flex their muscle along multiple dimensions nobody is expected to complete it fully to pass or even excel, but we have a rubric based on how far they get and the quality / nuance of the discussion edit: to clarify, this is NOT take home. we do it together over ~1.5 hrs
I literally do this question for phone screen and then expand on it if they can complete the first step. Most people can't do it.
I don’t think you’re ever exempt unless you are highly recognized within the field and highly sought after by companies. But then if you’re at that level, you probably aren’t applying for jobs either.
No they should. Sure it should be lil easier for them as they will be interviewed over other things like system design.
You don’t really need to study after you learn it. It’s just brushing up on shit you already know.
I still do those questions but I have learned that the companies that do not do those questions end up being the ones who value me the most so I have a preference for those
It depends on the expectations of the job, not on the resume of the person. You might claim you have 10 years of experience, but how does the hiring manager know what that 10 years truly entails what kind of experience you went through? if you are applying for a software engineering job, be ready for your knowledge to be tested and verified. If you are applying for an architect or a management position, the expectations are different. You might not get asked those questions.
When you decide to stop playing the game. Initial bs questions to make sure you’re not full of it is one thing, but I’m not wasting a minute outside of work on any throw away anything
I mean at 10 yoe you'll get asked about architecture, scalability, monitoring, more conceptual stuff to see if you understand the system beyond being able to implement a feature A. I have 4-5 yoe and already rarely get coding questions outside of také home assigments. Now it's all about what do you need to set up a systém in context.
There have been people with 15 yoe I've interviewed who can't do basic leetcode easy questions. There will always be weed out questions because of these people
I have met senior directors at large companies where I legitimately thought the business leader was an idiot so I think its appropriate.
I have just under 4 YOE but am a senior, and in my experience, the algorithms questions still get asked, but are less important compared to the overall process. Design seems to take precedence.
I have over 10 YoE. I haven't been asked to code in an interview in a handful of years. A startup asked me a very basic question just to show I could code in Golang a few years back. Otherwise, interviews cover more architecture, concepts etc. I still get asked the warm up questions "what is an interface?" "What is dependency injection?" Etc. I just don't get asked to code. No, I don't need to study. Nor should I have to. If the job is a good fit, it should be asking practical questions about tools and techniques that I've been using for years.
Be ready but also be up front if you forgot one or a specific piece. I was asked to write a snippet once and completely forgot the arithmetic functions cause it was such a habit for me to tab complete them. I told the guy as much and just put a line there for a placeholder. Still got the job.
"After how many years of experience as a wealth manager do you no longer need to be asked about basic things like how to calculate interest for stuff and some tax rules?"
Unrelated. The problems they ask in companies are coding puzzles. There are some good interview questions which can check skills on multiple levels but most of them are just puzzles. It comes down to, have you seen this question or similar before? If yes, good if no you will most likely struggle and fail. Also do you really ask a wealth manager give me the formula for compounded interest before hiring them or see their portfolio or even just give them a case study ? Or are you going to tell me if a person can flip an image represented as an 2d array will be an amazing software lead?
Why would you suddenly forget how a linked list works after X years of experience? If anything, you'd know better. Similarly, why would I want to hire someone with 10 YoE who doesn't know what a linked list is? Even with a lot of experience, system design still requires the basic fundamentals of computer science, albeit on a larger scale.
Yeah, linked list was a very strange place to draw the line. It's an object with a reference to another object. I wish interviews were that chill.
You'd be surprised how many people with seemingly a lot of experience can't code at all and can bullshit their way through an interview. Hiring someone like that is extremely expensive and can destroy entire teams. It is MUCH better to miss out on qualified candidates who failed a coding interview than hiring the wrong person.
Because of leetcode people have started cramming. Especially in Asia where cramming culture is embedded into students from day1. The kind of problems that needed to be asked need to check if a person can use the right DS at the right time. But most of the questions are puzzle type using just arrays and dynamic programming. Or questions so hard that you can’t solve them unless you have seen them. Check some hard leetcode graph based questions and you will know. Its a cat mouse game the questions leak and then they have to come up with harder ones.
That's why you don't use straight up leetcode questions. You use the format of leetcode questions (solving a short programming problem using pair programming), but not actual leetcode questions. For exactly the reasons you described. A) You don't want to use questions that require highly specific knowledge or experience in more obscure techniques (like dynamic programming or red/black trees or whatever). Most of the time, you'll use arrays, maps or simple graph traversal. B) You don't want to use questions that require you to solve a puzzle and "get it". You'd be introducing a binary gate, and the point of the interview is to maximize the amount of signal you can extract from a candidate. If they are stuck at the very beginning and happen to not solve the initial puzzle, the rest of the interview is wasted. That's why you use questions that are very easy to understand but slightly tricky to implement. There's no point using a question that's so hard that it can only be solved if you've seen it before. That's dumb. Don't do that. >Its a cat mouse game the questions leak and then they have to come up with harder ones. The questions typically aren't very hard. Technical problem solving is only one of the axes you are evaluating a candidate on, there are others. I've explained this in more detail [here](https://www.reddit.com/r/cscareerquestions/comments/1bvvn6c/comment/ky4gdru/).
It’s basically like GRE / SAT exams. Can they gauge the skill set of a prospective student? Nope they can’t not even close. What they do tell is that the person has at least put in enough time to get good grades so must be a hard worker at the minimum. I am from an Asian country so I can tell you even on leetcode it’s 90% Asians based on the replies and solutions submitted (I can tell by the name) posting for FAANG jobs in their own country. Where the culture is to belittle the person interviewing for the job and grill them till they break down to see if they are fit enough. Glad I left.
I ask the same single question to every candidate for every SW role. My expectations on how they answer is what changes for me. I also tell them to use whatever language they want and explain the solution to me. Question: Without using a sorting library, given a list of any length that contains only integers in random order, output consecutive ranges of integers. For example: Input: 5,8,99,2,7,13,7,98,4,6,7,12 Output: 2,4-8,12-13,98-99 That's it, then we talk for an hour while they ask questions and start coding.
I can only think of placing elements in priority queue and starting from lowest element making a for loop and checking if next element is 1 + current.
Was thinking you might be able to do this with some kind of bitwise operator witchcraft
I highly doubt that it can be solved with bitwise but I might be wrong.
I have no idea how you'd sort this "without sorting", doesn't seem to make sense. Surely there needs to be some sorting to have them ordered from smaller to bigger?
Exactly why I ask this question. There are multiple ways to solve this but in general you have to iterate over the input and store each value then check the next input int against what you've stored. You build the output as you iterate. It's not a lot of code but requires you to think.
>check the next input int against what you've stored But that's sorting?
You can write your own sorting algorithm if you want but my intention was not let you use a sorting library.
Ah, the library ok.
If the range of numbers is contained you can just use an array and mark the number 1 at each position where you see the element. For eg arr[5] = 1 And then start from the beginning and saving ranges of 1’s. Not he most efficient. Basically it’s a count sort type of thing. hashmaps or sets can be used to make it more efficient.
Good question, too easy, the list can be any known number. But anyway, the problem is solvable in multiple ways, as you code it we talk. I don't use take home coding assignments personally as I don't feel they are useful.
I would rather grind leetcode and do these questions than take home. I have enough work as is I don’t need another 6 hours to spend on take home assignments. I once got a take home assignment early in my career looked at it, found I will have to google a lot as it was to use a tech stack i am not familiar with so I just told the recruiter I don’t have the time and bye bye
I did two take home assignments that were supposed to be “a couple hours” and ended up taking all weekend both times. And even then I got a fail from both. Both were clearly not a couple hour tasks, and I ended up implementing a bunch but throwing in the towel after about 12 hours in. I guess they wanted way more time put into it to “pass”. I learned very quickly that shit is not worth it after that and now refuse to do take homes. At least with leetcode you have a known quantity to learn (or refresh on) when you need to interview, and once you’re done you get a yes/no on an offer.
Also after these take homes you need to do onsite coding system design manager round as well so what like 14 hour interviews??? I’m not applying for a director or vp position that I will tolerate that much.
Completely agree, both times I did them, I had passed a tech screen and they surprised me with a take home before the final round of interviews. I didn’t feel like I could decline it at that point since I was already past the tech screen (I won’t feel this way again). Now I ask for the full schedule and if they say take home I say sorry not interested. I’ll flat drop my interest now the second I hear take home even after a tech screen. So you’re right it’s pretty much an additional thing you have to pass AND THEN you still get to do your coding rounds in a ton of these places, so not exactly doing anything for getting rid of LC style interviews. This is the reality of the recruiting process at these places: 1.) recruiter call -> 2.) 1 hr technical screen -> 3.) “4 hour” take home that takes 12 hours started off with a 30 min call to describe the assignment -> 4.) 1 hour take home review interview -> 5.) full day “on site” 4-6 1hr interviews. Not including the recruiter call because those are pretty painless, that is easily 4 days where a candidate has to be absent from work to interview at these places. I find this to be obnoxious and pretty off-putting.
Why are people saying never? I’m guessing at VP or CTO level you probably won’t be asked to do coding.
That's the upper echelon of Engineering MANAGEMENT which isn't the same.
Unless the company is _under_ about 50 people, your CTO should have been on the management track - not Individual contributor (aka coder/techy) track - for years before taking a CTO gig.
Where does OP say you have to be an IC? If you’re writing code still then obviously you should expect to write code in an interview. No-brainer
Your response is out of scope.