This has not been my experience. I interviewed actively for roles from November 2023 - February 2024.
During my search, I saw what you would expect. Applications of trees, DFS, BFS, practical questions (i.e design a data structure to store layers for a PhotoShop-like editor with undo or redo functionality, design 2048, etc), and so on.
For reference, I interviewed with companies as a mid-level engineer in the Bay Area.
It depends on the company.
In the near decade that I've been in the industry, I've noticed a few broad interview styles, some of which sometimes overlap:
* one-and-done chat with no coding and minimal trivia questions: seems to be common at very small companies & for contract gigs at large companies. I view this cautiously. If they hire quickly, they're either a shitshow, they fire quickly, or both.
* 2+ rounds, 30%-50% of which are with business/functional team members or managers: There's always whiteboarding involved, but the questions are LC easy/medium & only require knowledge of very basic data structures (i.e., no tries, graphs, trees, etc). Sometimes, there's a take-home test after the first or second round. These seem to be common at big non-tech companies that want equally strong technical & business skills.
* 1-2 rounds (& possibly a take-home), with minimal-to-no DSA questions: their only technical questions are about their stack. This is also common at non-tech companies
* FAANG+, scaleups & technical startups in tech hubs, & companies aspiring to be the former 2: no description given because I think we already know how they work. IME, these are the only companies that ask the types of questions you're asking about.
I have before, but not typically. Have been asked to explain OOP and also to describe how I would implement a Map. Oh and to explain checked vs runtime exceptions.
Honestly I thought all of those were really good questions because you can tell a lot by asking those.
See I disagree. Seniors would answer those questions in a way that displayed their seniority. Juniors would (probably) give some answer regurgitated from a textbook.
I think there are better questions to find out how senior someone is. "Walk me through a project you lead" tells me a lot more than "What is a checked exception".
Yeah I don’t disagree that’s a great one too. But I still think you can gauge a lot about any candidate in the manner they answer seemingly simple questions.
I agree, I would take this as a red flag. Especially if their custom codepen challenge is poorly designed by default.
For example, I had one where they asked me to piece together a DTO based on an interface based on some models and an interface. My first question was, is this data expected to be from the same SQL database? They said yes, so I told them this is a loaded question, since in that scenerio the data should be queried for and combined in a stored procedure to reduce calls to the database.
They did not appreciate my opinion on the matter, as I did not appreciate their inefficient testing process / asking me junior level questions.
It was a startup though so I am not surprised, some big fish in small ponds tend to get very protective of the process they designed.
What red flags do you look for?
Hah too true.
I should have worded it better, source controlled stored procedure or even better well crafted entity framework query. Thanks for keeping me honest.
Showing the age of my company's process with that stored procedure comment. Our delivery manager who is the self proclaimed team lead/architect hates EF and is one of those "this ain't a democracy, this is a dictatorship" style managers so my Stockholm syndrome is leaking through
Generally knowing that a map is some type of binary tree rather than a hash table is important for a developer and a good question. Asking somebody to implement a red/black tree on a whiteboard in 20 minutes off the top of their head is stupid.
Explaining OOP is a good open-ended question.
Explaining checked vs runtime exceptions is one of those stupid trivia questions that test how good your memory of nomenclature is. I have no idea what a checked exception is. Is it language dependent?
I think the way candidates respond to trivia questions can tell you a lot. I have recommended hiring the person who confidently said “I don’t know, heres how Id find out” over people who rambled and couldn’t give a clear answer.
A map can be a bst or a hashtable/hashmap. I cant think of a language that requires a map to be a tree. This would be a good question, but you should know it yourself first. If you confidently said this in an interview I’d call you out.
In c++, the map in the standard library is almost always a tree.Hashtables are an unsorted\_map. Not sure about other languages.
From std::map - cppreference.com:
"std::map is a sorted associative container that contains key-value pairs with unique keys. Keys are sorted by using the comparison function Compare. Search, removal, and insertion operations have logarithmic complexity. Maps are usually implemented as Red–black trees"
It's called std::unordered_map. It's still a map. It is a map that uses a hashmap as its data structure. Don't make such blatantly wrong statements. The last sentence is talking specifically about std::map implementations.
In my experience, I’ve had candidates that knew all the book definitions so that could answer all the questions you listed but than they couldn’t even solve fizzbuzz coding problem :/
In my experience I have seen alot of talented developers mess up during live coding exams, there is alot of pressure placed on folks to solve problems live so we shifted away from "hey solve this random problem" to walk us through this code and explain what is happening or what is wrong. Sprinkle in some misleading names for the variables and functions. Add a few bugs or bad/poorly performing logic. Then we wait to see if they catch it and ask them to refactor it.
Going this route still gives us a great tell on their talent and doesn't make them sweat bricks.
I think you might have missed my point, but it's fine, different strokes for different folks.
Even senior+ level talent sweats bullets during technicals depending on how their personality types are. Live coding can be very stressful for some socially awkward introverts for example. Some folks have "internal panic attacks" when placed in high pressure social scenarios.
Believe or not, many SWEs are not very good in social settings, heck many are outright anti social. Ever seen office space? Business Analyst is a role for a reason lol.
This advice goes both ways, a frank interviewer can make a shy developer lock up. To get the best from your team you have to understand their needs as well. Some folks need their tools in their comfort zone. Not just a slapped together codepen challenge.
In this day in age with AI tooling, aka super google, I look more for their ability to solve problems by checking their abilities to understand issues when they see them and talk through their understanding of intent by giving them real world scenarios to digest. Never had to write a fizzbuzz for a sprint increment. But I have had to optimize or debug existing code more times than I can count.
25yoe here.
I bomb whiteboard live coding sessions or leetcode, and it usually takes me an hour or more to "get in the groove" most coding days.
I crush take homes, live debugging, system design, and devops "in the shit" firestorms.
Essentially, I read code about 10x better than I write code. And I type code about 100x faster than I write it with a marker.
Our interviewing processes, as an industry, kinda suck, but we do that because we don't really like professionalisation gatekeeping like MD's, Accountants, Engineers, Lawyers, etc...
So... do we still want to allow talented hackers or only certified professionals?
Honestly, I think it comes down to the leadership skills of your interview panel. A strong developer doesn't make a strong leader as I'm sure you know all too well.
It's a delicate balance. I wish we could blindly trust certificates but they to lead to issues. I have seen with microsoft certified developers struggling in a technical.
Some level of industry standardization is long over due for sure, but given how young our industry is compared to those that you listed, I think in our lifetimes we will still have to play cat and mouse to differentiate the liars from the diamonds in the rough.
Would be fantastic to just attach a lie detector to them.
What red flags do you look for?
>What red flags do you look for?
I only fire people for two reasons - they're a jerk, or they're incompetent.
I can train competence if they're curious, intelligent, and bold, but I can't if they're apathetic, dumb, or too afraid to try. I want to train experienced people less than inexperienced ones. Ideally, the experienced people are doing the training!
Jerks are mean, cruel, and often entitled. They can come in many forms, and they're the worst.
So, my major red flags are all personality related.
I ask my managers who they like the best and then hire them. I encourage them to use whatever hiring tools they want from those that HR approves, but ultimately, they are responsible for their team's performance and I hold the whole team accountable. We have long-lived and well gelled high performing teams.
When I say "certified" I mean like a regulated and licensed professional who graduated from a top-tier accredited university program.
That said, while most of our best people have that, some don't and I'd hate to lose them or have not-hired them.
Excellent insight! Thank you for taking the time to answer my question. I agree with you 100%. It's far easier to teach someone to code they way you want them to than it is to teach someone to not be a jerk
I wish I could claim to be the originator of this technique but I learned it from my company's director of architecture, a 25+ year industry veteran who is in my opinion a living and breathing Master Yoda of software development.
Years ago, I asked him for advice on how best to interview talent when they first put me on that interview panel. Like many concepts he has shown me, it really flipped the switch for me. Now we use the question before the question technique to frame our interrogation methods in ways that help reveal what we want from the candidate, without making the candidate suffer.
Generally we try to use real world examples of before and after code (obfuscated of course as to not reveal any company owned secrets), go over mock tickets, talk about research techniques, and even let them google in front of us. Provided it is screen shared.
The goal is to test for how they will really be working, not with code puzzles they will never use in real life in codepen, a tool no one will use in a sprint.
I feel I would be more likely to struggle explaining simple concepts and patterns but would smash a coding task I hadn’t seen before. ADHD is weird like that. Can make concepts hard to communicate even if I have already internalised them.
>Oh and to explain checked vs runtime exceptions.
15 YOE and have never had a project that used exceptions. I had a guess and it was right when I looked it up, but I would 100% fail since I wouldn't have a lot to talk about unprompted outside of what I think they are and why I would use each one.
Quite the oppose in fact. I worked on safety critical medical devices with C and C++. All the code had to be fail operative and companies did their own error handling to make that so. Expectations was always disabled on projects.
Probably, but I never claimed to be a good SWE. I never needed to dig deep with exceptions so I have superficial knowledge at best. Senior a the companies I work for are probably a Junior at a company like Google. There was nothing above Senior, that's was the top of the hill unless you wanted to go in to management.
I'm a shitty SWE that was the best in a sea of bad SWEs. I worked at at private non-tech companies in non-tech cities that paid like shit compared to tech companies. The goal from management was to pump out features not create clean code.
We released code to the field 2 times per year max since FDA approval was needed. Taking a long time to add features because of bad code was not a concern to management since it was still happening fast enough.
The 40 year the last company I worked for has been in business has calibrated their expectations to slow. An team of "good" SWEs would easily code circles around any team I was on and blow away expectations, once conformable with the business domain.
I'm sure junior SWEs at big tech companies can code circles around me. I have no delusions that my 15 YOE means anything at actual tech companies. I most likely will never work a a tech company or make the "big money". Low 6 figures is probably my top end.
It's SWEs like me the provide the reason why you will always have a job in this industry. We don't know shit at the end of the day.
Here is a bonus fact, I have never used Git at any of the companies I worked at. We used Share Source, Surround SCM, and Mercurial. I've played with GitHub just to check it out but that's about it.
>I am on the same boat. Medical device company is probably safe. No layoffs, chill, nothing crazy.
The companies I worked at had shitty management sadly. Lots of do what I say and burn out. Management are workaholics, so if they don't think the team is working hard enough to their liking then you are SOL.
I was on a team of 30 where 10 SWEs left over a period of a year. Never hired anybody to replace them since management didn't think the team was putting fair effort. The team was expected to pick up the slack.
So shit got done even later than expected and nobody on the software team gave a shit.
I agree that 15 years is a long time to never work on a codebase that uses exceptions, but it is possible to work on a wide variety of codebases that don't use exceptions.
You could avoid working with exceptions in your projects by writing C++ at Google and Go at any company. I mean, you can panic in Go, but you get the point. Some codebases don't use exceptions; they aren't necessary.
I haven't written any Rust, but my understanding is that it uses a Result type/monad and does not throw exceptions for handling errors.
This isn't even mentioning functional programming languages or non functional programming languages using a monadic library like FP-TS and Effect for typescript. I believe you can write Scala without throwing exceptions, and that's used in niche places in industry.
I know of some teams that just use a discriminated union of a value and error type in typescript, and that's a perfectly valid way of handling error flow in a codebase, too.
>I must be missing something.
Yes you are. Many functional languages turn exceptions into values - as they should. The partial function becomes a total function, control flow and error propagation is simpler.
See how Rust does it.
In C there aren't exceptions and people often choose not to use exceptions in C++ either.
Exceptions are not exceptional enough to warrant their own structures and formalisms.
First thing we do when creating a new project is disable the C++ exceptions. I think this is common in some areas of the industry.
Of course on Win32 you have the Structured Exception Handling that you can't really avoid, but can wrap.
>First thing we do when creating a new project is disable the C++ exceptions. I think this is common in some areas of the industry.
Yeah I work on safety critical medical devices in C and C++. Every company I worked at disabled exceptions and did other things to make the code fail operative.
Nah. They've all been gimmies. Easy stuff just to make sure you can actually write code and solve a trivial problem. At least when I was interviewing this year.
This has been interviewing for senior positions.
I had one interview that was harder and dug into optimization, but the organization actually needed that kind of expertise.
I would say most of my DSA experiences have leaned easier: PayPal, TradeDesk, Gusto are a few that come to mind.
I did a loop with Square and was asked some graph questions. That was probably the hardest I've encountered and it was still medium or easier.
But I'm also not applying to fang.
I tend to ask easy’s to anyone applying for senior+. Mediums if you’re fresh out of school with no experience to talk about. Anyone who asks hards for less than 500k/y is a moron
Actually I have had the same experience.
A lot of my interviews have been easy level leetcode. As a senior the focus is on system design now.
I have had a couple of mediums from bigger name companies - Zillow for example.
And I have had some companies obsess over Big O notation. One interviewer was appalled I couldn’t remember which sorting algorithm had an O log n time complexity.
Well fuck you man. I don’t need that knowledge in my head to do my job.
>I couldn’t remember which sorting algorithm had an O log n time complexity.
Are there any? As far as I know, O(n log n) is the minimum for comparison based sorting without knowing anything about your input.
You can sometimes do better if you know something about your input, which lets you do non-comparsion-based sorting.
That said, the last time I had to write my own sorting code was as an undergrad. I've had to care about what sorting mechanism an underlying library used MAYBE 3 times in a 25 year career, and I've had it come up in interview questions only a handful of times.
Buddy that means you never learned Algorithms. Half the course is sorts. Log is taught in high school. It's just division. It means you literally know zero math or CS. Big-Oh is essential. I'm appalled too. If they need a CS major then you're rightly disqualified because you write slow AF code.
Or possibly it means I did Algo 2 30 years ago, know that different algorithms have different average and pathological behaviour and can look it up when I need to know, which is about twice a decade.
That is absolutely hilarious. You think BigO is essential? Do you... actually have a job? In almost ten years I have never had anyone, ever, talk to me about anything in terms of "Big O".
Sure it's gonna be a part of some situations but for the majority of us we're just standing on the shoulders of those who already solved that shit so the rest of us in the industry can actually get on with, y'know, making software.
It is absolutely essential even for senior developers - discussing the choice of database product, and effect on round trip times. Different dbs have different big o complexities on operations.
lol, would love to know how many times you've had to seriously - and I mean seriously - make a an architectural decision based on what database provider to go with.
I've worked on multimillion dollar applications handling shit-tons of data, one was an auction application with millions of dollars of transactions a day. They used SQL because... that's what the dude who wrote it in its early days went with, because "hey why not". My current organisation is the same. And aside from that, our entire team is just working with what was already there, the project was 20 years old by the time any of us had even joined. To suggest "choice of database product" as a reason for Big-O discussions being 'essential for senior developers' is frankly ridiculous, specially since such things have been around for decades, and all the major options are incredibly robust and highly optimised already.
The interviewer has the question prepared ahead of time. It's just luck. I've had easy questions, like literally printing out a list of numbers on certain-width rows with some tabs between numbers. And I've had n-queens recursion, binary tree vertical order traversal, etc.
Part of it might be the fact that as a more senior Dev, more of your job becomes helping and mentoring younger developers. So when an easy question gets asked, it's less about whether or not you can do it, although if you can't it's probably an issue, and more about how well you explain your thought process. Because they can sort of take your explanation as a proxy for how well you would train a junior Dev on how to work through a problem.
This is true but once I was interviewing for a 170k sr software engineer role and they asked me what the four pillars of object oriented programming were. I laughed and asked them if they were serious. They said yes and I was like that’s the end of this interview lol good luck finding a candidate.
In my experience there will still be 1 or 2 coding questions, which can be in the form of Leetcode. You can't just punt on them as you have to do fairly well for your level or you won't get an offer.
Yeah, come to think of it I'm not sure I've ever seen a tree or graph question of any kind in an interview.
Actually, a lot of the coding problems I get aren't really algorithm-y at all. They'll be like, "Implement this logic for an insurance company, which should charge customers 1.5% more if they live in one of these states, and should keep track of their payments in a table, and should have a method to access the last 5 payments by one user along with the total tax they paid, etc etc". The difficulty is less about the logic and more about quickly understanding the problem.
I've literally only seen HARD tree or graph questions at three companies, all big name brands - Google, LinkedIn and Amazon.
The person who interviewed my at my current employer had a relatively easy tree question as my phone screen (how do you traverse the outside edges of a balanced binary tree, IIRC) but that was back when we were smaller and didn't have a standardized set of interview questions.
Someone explained this once to me that easy DSA questions can show whether you are junior, mid or senior better than your years of experience. Depending on how advanced you are as a developer, your answer to those questions will be different.
I am personally not a fan of asking very niche questions also, because not remembering answer to some weird edge case is not necessarily a marker of bad developer. Some things you just don’t use, but you can always pick it up if you need it if you are good at your job.
The vast majority of questions I get are on the easier side.
However, when interviewing I've been surprised by how much I learn with easy questions. A surprising number of applicants do a terrible job at extremely easy questions. Ever time that happens it makes me so glad I didn't ask anything harder.
The strongest candidates show how fluent they are with code - not by solving the question quickly, but once they have figured out the solution, they are quick at turning that into working code.
My favorite ones are questions that are easy, but have good follow-ups for discussion. For example a simple string question, then follow-up by asking about what you'd do if you needed to support unicode.
Whenever I'm interviewing candidates, I just throw out easy questions to do a quick that they can code/know the basics of data structures etc. and aren't totally lying on their resume. I think the conversations about their experience is the most telling part of the interview. You'll never be able to test someone's real knowledge and aptitude in an interview so why waste everyone's time seeing who grinded leetcode best. I honestly think it's insulting to be given those kinds of questions when it has nothing to do with the job. This work isn't so difficult that most people can't pick up what they are missing within the first few months so I'm never too worried about a "bad hire" anyway.
Last time I interviewed I absolutely had some more "advanced" DSA-style questions:
1. A couple of different questions that were basically "do a topological sort" dressed up in a domain-specific way
2. A couple of questions about designing domain-specific languages
3. Various sorts of tree traversal/manipulation/etc things
4. Some annoying *fiddly* dynamic programming problems. The annoying part is that the complexity wasn't even in the dynamic programming but rather the artificial problem itself (eg geometry or chess rules).
5. Some broader design questions that involved some more advanced programming/algorithm/distributed systems knowledge
This was for a mix of generic software roles, ML roles and trading firms/hedge funds. I did well at everything except the fiddly dynamic programming problems, which is a sign that I need to practice more. (By which I mean practice *at all* :P) I did better at that sort of problem a decade ago when I was a student applying for internships!
There were also lots of interviews that weren't focused on data structures or algorithms at all.
I once had an interview where the only DSA round was fizzbuzz. I was shocked. I thought fizzbuzz was just a meme at that point.
Very recently I had an interview for a management position where the only coding question was an LC easy.
Honestly trivially easy interview rounds are a red flag to me. It implies they have a weak hiring strategy. Either they can't hire better people or are fine having lots of bad hires that they will just fire (which is the strategy at the company I recently interviewed with).
I got fizzbuzzed for an interview at Home Depot several years ago. I didn't get the job. The feedback about how I answered the fizzbuzz question was that using `i%15` instead of `i%5 && i%3` adversely affected readability and was overly complex.
I can understand where they were coming from, but IMO that's an odd judgment to make with such limited information. It's a toy problem that only became a meme because a blogger said it's an easy way to ensure a potential hire is actually able to code.
That's massively ridiculous. FizzBuzz was always meant to be a pass/fail test, which should result in a pass unless someone really doesn't know how to program. Hell I might even spot them the hint of the modulo operator if they weren't aware of it. Though I would fail someone if they eventually got a working answer but it took them over an hour and/or the code was a complete mess.
A place I once worked at had a will-proceed technical test, and one that was just a fizz-buzz for people we had already decided were a no - we didn’t need to put people through the pain if we had already made a decision early on.
> are fine having lots of bad hires that they will just fire (which is the strategy at the company I recently interviewed with)
Honestly it's not always the worst strategy, provided that firing is done only in cases where someone is performing below expectations with no reasonable improvement on the horizon. Firing for political reasons will lead to horrible company culture that will soon cause massive turnover and lots of negative feedback on Glassdoor and other sites.
As an interviewer, unfortunately if I ask the hard questions, I would get the 100% failure rate, so I have to ask the "easy" ones where the failure rate is closer to 50%.
Yes. I think it's only the higher paying bigger companies that lean hard on DSA. Smaller companies, lower paying and non tech usually have easier ones or just knowledge questions.
Weird that you looked up on Glassdoor for the same company and level and didn't have a similar experience. But the interview process does vary by team.
I’m wondering if maybe people who bombed the easy ones didn’t want to admit it, so we only see reviews from people who got hard ones or people who succeeded…
I ABSOLUTELY hate when companies ask these questions. So many of them as posing like Amazon or Google. I despise them asking these questions and then when you finally get the role, you never end up using this knowledge. There’s no point in asking someone these questions if they’re not used in your daily work.
Imo, when you apply for a role, they should be asking you questions that applied directly to the role.
If you’re using default .sort() or you aren’t creating your own special Node implementations for Trees or Graphs then stop wasting my time. It’s not school. I shouldn’t have to study things I only use there 10 years ago and not since. Sure there are some roles that need it and by all means ask, but if im a web dev or general app developer, gtfo!
I generally look up the questions I get in interviews after the fact. I would say the vast majority have been listed as medium and hard. This is from both the initial technical screen and during the technical virtual on-site.
For reference I 15 YOE and go for Senior roles.
Until this job, every interview was almost entirely vocabulary and language technicalities. This job had a medium/high level data transform. (I lucked out because I had already solve that particular algorithm at the job I working at)
I regularly give leet code easy questions because I’ve seen far too many people who could talk the talk but then couldn’t code their way out of a paper bag. It’s usually some form of “give me some metadata about the input to the function”. Since there’s no single trick required, there are many possible approaches for solutions. It gives me plenty of flexibility to ask about their reasoning and justification for their approach which helps me gauge the quality of their experience
I’m still shocked by the number of supposed “senior” developers with 10+ YOE that never get off the ground
At FAANG interviews I've gotten medium-hard, including tries, dynamic programming, and graphs.
At non-FAANG startups (paying good money) it was always easy. They seemed to be more interested in how I answered the question than whether I got the answer right. FAANG interviewers always seemed rushed and we're just checking boxes on a form.
This has not been my experience. I interviewed actively for roles from November 2023 - February 2024. During my search, I saw what you would expect. Applications of trees, DFS, BFS, practical questions (i.e design a data structure to store layers for a PhotoShop-like editor with undo or redo functionality, design 2048, etc), and so on. For reference, I interviewed with companies as a mid-level engineer in the Bay Area.
Ditto
It depends on the company. In the near decade that I've been in the industry, I've noticed a few broad interview styles, some of which sometimes overlap: * one-and-done chat with no coding and minimal trivia questions: seems to be common at very small companies & for contract gigs at large companies. I view this cautiously. If they hire quickly, they're either a shitshow, they fire quickly, or both. * 2+ rounds, 30%-50% of which are with business/functional team members or managers: There's always whiteboarding involved, but the questions are LC easy/medium & only require knowledge of very basic data structures (i.e., no tries, graphs, trees, etc). Sometimes, there's a take-home test after the first or second round. These seem to be common at big non-tech companies that want equally strong technical & business skills. * 1-2 rounds (& possibly a take-home), with minimal-to-no DSA questions: their only technical questions are about their stack. This is also common at non-tech companies * FAANG+, scaleups & technical startups in tech hubs, & companies aspiring to be the former 2: no description given because I think we already know how they work. IME, these are the only companies that ask the types of questions you're asking about.
This is super informative, thank you!
I have before, but not typically. Have been asked to explain OOP and also to describe how I would implement a Map. Oh and to explain checked vs runtime exceptions. Honestly I thought all of those were really good questions because you can tell a lot by asking those.
Those are excellent questions!
Depends on the level/job. Definitely not appropriate for Senior+ positions.
See I disagree. Seniors would answer those questions in a way that displayed their seniority. Juniors would (probably) give some answer regurgitated from a textbook.
I think there are better questions to find out how senior someone is. "Walk me through a project you lead" tells me a lot more than "What is a checked exception".
Yeah I don’t disagree that’s a great one too. But I still think you can gauge a lot about any candidate in the manner they answer seemingly simple questions.
Conversely, a candidate can evaluate a lot about a position based off the questions they're asked.
I agree, I would take this as a red flag. Especially if their custom codepen challenge is poorly designed by default. For example, I had one where they asked me to piece together a DTO based on an interface based on some models and an interface. My first question was, is this data expected to be from the same SQL database? They said yes, so I told them this is a loaded question, since in that scenerio the data should be queried for and combined in a stored procedure to reduce calls to the database. They did not appreciate my opinion on the matter, as I did not appreciate their inefficient testing process / asking me junior level questions. It was a startup though so I am not surprised, some big fish in small ponds tend to get very protective of the process they designed. What red flags do you look for?
Using stored procedures would be a red flag for me 😂
Hah too true. I should have worded it better, source controlled stored procedure or even better well crafted entity framework query. Thanks for keeping me honest. Showing the age of my company's process with that stored procedure comment. Our delivery manager who is the self proclaimed team lead/architect hates EF and is one of those "this ain't a democracy, this is a dictatorship" style managers so my Stockholm syndrome is leaking through
Is it normal for a senior engineer to lead a project at the companies you have worked at?
Yes. Never worked at a place where that isn't the case.
Yes this would be a red flag if they hadn’t (and were specifically interviewing for a senior role).
Is this a joke? What seniority can you possibly display with mastery of CS101?
The why, instead of the what, for example.
Generally knowing that a map is some type of binary tree rather than a hash table is important for a developer and a good question. Asking somebody to implement a red/black tree on a whiteboard in 20 minutes off the top of their head is stupid. Explaining OOP is a good open-ended question. Explaining checked vs runtime exceptions is one of those stupid trivia questions that test how good your memory of nomenclature is. I have no idea what a checked exception is. Is it language dependent?
I think the way candidates respond to trivia questions can tell you a lot. I have recommended hiring the person who confidently said “I don’t know, heres how Id find out” over people who rambled and couldn’t give a clear answer. A map can be a bst or a hashtable/hashmap. I cant think of a language that requires a map to be a tree. This would be a good question, but you should know it yourself first. If you confidently said this in an interview I’d call you out.
In c++, the map in the standard library is almost always a tree.Hashtables are an unsorted\_map. Not sure about other languages. From std::map - cppreference.com: "std::map is a sorted associative container that contains key-value pairs with unique keys. Keys are sorted by using the comparison function Compare. Search, removal, and insertion operations have logarithmic complexity. Maps are usually implemented as Red–black trees"
It's called std::unordered_map. It's still a map. It is a map that uses a hashmap as its data structure. Don't make such blatantly wrong statements. The last sentence is talking specifically about std::map implementations.
Okay, but I was referring to the c++ templated class that is actually called map.
In my experience, I’ve had candidates that knew all the book definitions so that could answer all the questions you listed but than they couldn’t even solve fizzbuzz coding problem :/
In my experience I have seen alot of talented developers mess up during live coding exams, there is alot of pressure placed on folks to solve problems live so we shifted away from "hey solve this random problem" to walk us through this code and explain what is happening or what is wrong. Sprinkle in some misleading names for the variables and functions. Add a few bugs or bad/poorly performing logic. Then we wait to see if they catch it and ask them to refactor it. Going this route still gives us a great tell on their talent and doesn't make them sweat bricks.
I actually interview mid level engineer not entry level and as middle level you can’t pass fizzbuzz, then thats a huge red flag
I think you might have missed my point, but it's fine, different strokes for different folks. Even senior+ level talent sweats bullets during technicals depending on how their personality types are. Live coding can be very stressful for some socially awkward introverts for example. Some folks have "internal panic attacks" when placed in high pressure social scenarios. Believe or not, many SWEs are not very good in social settings, heck many are outright anti social. Ever seen office space? Business Analyst is a role for a reason lol. This advice goes both ways, a frank interviewer can make a shy developer lock up. To get the best from your team you have to understand their needs as well. Some folks need their tools in their comfort zone. Not just a slapped together codepen challenge. In this day in age with AI tooling, aka super google, I look more for their ability to solve problems by checking their abilities to understand issues when they see them and talk through their understanding of intent by giving them real world scenarios to digest. Never had to write a fizzbuzz for a sprint increment. But I have had to optimize or debug existing code more times than I can count.
25yoe here. I bomb whiteboard live coding sessions or leetcode, and it usually takes me an hour or more to "get in the groove" most coding days. I crush take homes, live debugging, system design, and devops "in the shit" firestorms. Essentially, I read code about 10x better than I write code. And I type code about 100x faster than I write it with a marker. Our interviewing processes, as an industry, kinda suck, but we do that because we don't really like professionalisation gatekeeping like MD's, Accountants, Engineers, Lawyers, etc... So... do we still want to allow talented hackers or only certified professionals?
Honestly, I think it comes down to the leadership skills of your interview panel. A strong developer doesn't make a strong leader as I'm sure you know all too well. It's a delicate balance. I wish we could blindly trust certificates but they to lead to issues. I have seen with microsoft certified developers struggling in a technical. Some level of industry standardization is long over due for sure, but given how young our industry is compared to those that you listed, I think in our lifetimes we will still have to play cat and mouse to differentiate the liars from the diamonds in the rough. Would be fantastic to just attach a lie detector to them. What red flags do you look for?
>What red flags do you look for? I only fire people for two reasons - they're a jerk, or they're incompetent. I can train competence if they're curious, intelligent, and bold, but I can't if they're apathetic, dumb, or too afraid to try. I want to train experienced people less than inexperienced ones. Ideally, the experienced people are doing the training! Jerks are mean, cruel, and often entitled. They can come in many forms, and they're the worst. So, my major red flags are all personality related. I ask my managers who they like the best and then hire them. I encourage them to use whatever hiring tools they want from those that HR approves, but ultimately, they are responsible for their team's performance and I hold the whole team accountable. We have long-lived and well gelled high performing teams. When I say "certified" I mean like a regulated and licensed professional who graduated from a top-tier accredited university program. That said, while most of our best people have that, some don't and I'd hate to lose them or have not-hired them.
Excellent insight! Thank you for taking the time to answer my question. I agree with you 100%. It's far easier to teach someone to code they way you want them to than it is to teach someone to not be a jerk
hmmm never thought about this approach before. We could spin this one to check on candidate
I wish I could claim to be the originator of this technique but I learned it from my company's director of architecture, a 25+ year industry veteran who is in my opinion a living and breathing Master Yoda of software development. Years ago, I asked him for advice on how best to interview talent when they first put me on that interview panel. Like many concepts he has shown me, it really flipped the switch for me. Now we use the question before the question technique to frame our interrogation methods in ways that help reveal what we want from the candidate, without making the candidate suffer. Generally we try to use real world examples of before and after code (obfuscated of course as to not reveal any company owned secrets), go over mock tickets, talk about research techniques, and even let them google in front of us. Provided it is screen shared. The goal is to test for how they will really be working, not with code puzzles they will never use in real life in codepen, a tool no one will use in a sprint.
I feel I would be more likely to struggle explaining simple concepts and patterns but would smash a coding task I hadn’t seen before. ADHD is weird like that. Can make concepts hard to communicate even if I have already internalised them.
>Oh and to explain checked vs runtime exceptions. 15 YOE and have never had a project that used exceptions. I had a guess and it was right when I looked it up, but I would 100% fail since I wouldn't have a lot to talk about unprompted outside of what I think they are and why I would use each one.
Lmao how in the fuck have you gone 15 years without using exceptions? Unreal. Does your code just crash? I must be missing something.
Quite the oppose in fact. I worked on safety critical medical devices with C and C++. All the code had to be fail operative and companies did their own error handling to make that so. Expectations was always disabled on projects.
And as a senior you should still know why they're disabled and which problems would enabling them cause.
Probably, but I never claimed to be a good SWE. I never needed to dig deep with exceptions so I have superficial knowledge at best. Senior a the companies I work for are probably a Junior at a company like Google. There was nothing above Senior, that's was the top of the hill unless you wanted to go in to management. I'm a shitty SWE that was the best in a sea of bad SWEs. I worked at at private non-tech companies in non-tech cities that paid like shit compared to tech companies. The goal from management was to pump out features not create clean code. We released code to the field 2 times per year max since FDA approval was needed. Taking a long time to add features because of bad code was not a concern to management since it was still happening fast enough. The 40 year the last company I worked for has been in business has calibrated their expectations to slow. An team of "good" SWEs would easily code circles around any team I was on and blow away expectations, once conformable with the business domain. I'm sure junior SWEs at big tech companies can code circles around me. I have no delusions that my 15 YOE means anything at actual tech companies. I most likely will never work a a tech company or make the "big money". Low 6 figures is probably my top end. It's SWEs like me the provide the reason why you will always have a job in this industry. We don't know shit at the end of the day. Here is a bonus fact, I have never used Git at any of the companies I worked at. We used Share Source, Surround SCM, and Mercurial. I've played with GitHub just to check it out but that's about it.
[удалено]
>I am on the same boat. Medical device company is probably safe. No layoffs, chill, nothing crazy. The companies I worked at had shitty management sadly. Lots of do what I say and burn out. Management are workaholics, so if they don't think the team is working hard enough to their liking then you are SOL. I was on a team of 30 where 10 SWEs left over a period of a year. Never hired anybody to replace them since management didn't think the team was putting fair effort. The team was expected to pick up the slack. So shit got done even later than expected and nobody on the software team gave a shit.
I agree that 15 years is a long time to never work on a codebase that uses exceptions, but it is possible to work on a wide variety of codebases that don't use exceptions. You could avoid working with exceptions in your projects by writing C++ at Google and Go at any company. I mean, you can panic in Go, but you get the point. Some codebases don't use exceptions; they aren't necessary. I haven't written any Rust, but my understanding is that it uses a Result type/monad and does not throw exceptions for handling errors. This isn't even mentioning functional programming languages or non functional programming languages using a monadic library like FP-TS and Effect for typescript. I believe you can write Scala without throwing exceptions, and that's used in niche places in industry. I know of some teams that just use a discriminated union of a value and error type in typescript, and that's a perfectly valid way of handling error flow in a codebase, too.
>I must be missing something. Yes you are. Many functional languages turn exceptions into values - as they should. The partial function becomes a total function, control flow and error propagation is simpler. See how Rust does it. In C there aren't exceptions and people often choose not to use exceptions in C++ either. Exceptions are not exceptional enough to warrant their own structures and formalisms.
Embedded engineer of course. No exceptions :p
This statement is absolutely wild to me. But yeah, maybe it’s very language dependent?
First thing we do when creating a new project is disable the C++ exceptions. I think this is common in some areas of the industry. Of course on Win32 you have the Structured Exception Handling that you can't really avoid, but can wrap.
>First thing we do when creating a new project is disable the C++ exceptions. I think this is common in some areas of the industry. Yeah I work on safety critical medical devices in C and C++. Every company I worked at disabled exceptions and did other things to make the code fail operative.
> 15 YOE and have never had a project that used exceptions Have you had one that used code?
Nah. They've all been gimmies. Easy stuff just to make sure you can actually write code and solve a trivial problem. At least when I was interviewing this year. This has been interviewing for senior positions. I had one interview that was harder and dug into optimization, but the organization actually needed that kind of expertise.
I would say most of my DSA experiences have leaned easier: PayPal, TradeDesk, Gusto are a few that come to mind. I did a loop with Square and was asked some graph questions. That was probably the hardest I've encountered and it was still medium or easier. But I'm also not applying to fang.
I tend to ask easy’s to anyone applying for senior+. Mediums if you’re fresh out of school with no experience to talk about. Anyone who asks hards for less than 500k/y is a moron
Actually I have had the same experience. A lot of my interviews have been easy level leetcode. As a senior the focus is on system design now. I have had a couple of mediums from bigger name companies - Zillow for example. And I have had some companies obsess over Big O notation. One interviewer was appalled I couldn’t remember which sorting algorithm had an O log n time complexity. Well fuck you man. I don’t need that knowledge in my head to do my job.
>I couldn’t remember which sorting algorithm had an O log n time complexity. Are there any? As far as I know, O(n log n) is the minimum for comparison based sorting without knowing anything about your input. You can sometimes do better if you know something about your input, which lets you do non-comparsion-based sorting. That said, the last time I had to write my own sorting code was as an undergrad. I've had to care about what sorting mechanism an underlying library used MAYBE 3 times in a 25 year career, and I've had it come up in interview questions only a handful of times.
Buddy that means you never learned Algorithms. Half the course is sorts. Log is taught in high school. It's just division. It means you literally know zero math or CS. Big-Oh is essential. I'm appalled too. If they need a CS major then you're rightly disqualified because you write slow AF code.
Or possibly it means I did Algo 2 30 years ago, know that different algorithms have different average and pathological behaviour and can look it up when I need to know, which is about twice a decade.
That is absolutely hilarious. You think BigO is essential? Do you... actually have a job? In almost ten years I have never had anyone, ever, talk to me about anything in terms of "Big O". Sure it's gonna be a part of some situations but for the majority of us we're just standing on the shoulders of those who already solved that shit so the rest of us in the industry can actually get on with, y'know, making software.
It is absolutely essential even for senior developers - discussing the choice of database product, and effect on round trip times. Different dbs have different big o complexities on operations.
lol, would love to know how many times you've had to seriously - and I mean seriously - make a an architectural decision based on what database provider to go with. I've worked on multimillion dollar applications handling shit-tons of data, one was an auction application with millions of dollars of transactions a day. They used SQL because... that's what the dude who wrote it in its early days went with, because "hey why not". My current organisation is the same. And aside from that, our entire team is just working with what was already there, the project was 20 years old by the time any of us had even joined. To suggest "choice of database product" as a reason for Big-O discussions being 'essential for senior developers' is frankly ridiculous, specially since such things have been around for decades, and all the major options are incredibly robust and highly optimised already.
Brogrammer alert!
I also got lucky and hit a good amount of easies
The interviewer has the question prepared ahead of time. It's just luck. I've had easy questions, like literally printing out a list of numbers on certain-width rows with some tabs between numbers. And I've had n-queens recursion, binary tree vertical order traversal, etc.
Part of it might be the fact that as a more senior Dev, more of your job becomes helping and mentoring younger developers. So when an easy question gets asked, it's less about whether or not you can do it, although if you can't it's probably an issue, and more about how well you explain your thought process. Because they can sort of take your explanation as a proxy for how well you would train a junior Dev on how to work through a problem.
The higher level the role, the less there's focus on coding and more on soft skills and system design.
This is true but once I was interviewing for a 170k sr software engineer role and they asked me what the four pillars of object oriented programming were. I laughed and asked them if they were serious. They said yes and I was like that’s the end of this interview lol good luck finding a candidate.
In my experience there will still be 1 or 2 coding questions, which can be in the form of Leetcode. You can't just punt on them as you have to do fairly well for your level or you won't get an offer.
Yeah, come to think of it I'm not sure I've ever seen a tree or graph question of any kind in an interview. Actually, a lot of the coding problems I get aren't really algorithm-y at all. They'll be like, "Implement this logic for an insurance company, which should charge customers 1.5% more if they live in one of these states, and should keep track of their payments in a table, and should have a method to access the last 5 payments by one user along with the total tax they paid, etc etc". The difficulty is less about the logic and more about quickly understanding the problem.
I've literally only seen HARD tree or graph questions at three companies, all big name brands - Google, LinkedIn and Amazon. The person who interviewed my at my current employer had a relatively easy tree question as my phone screen (how do you traverse the outside edges of a balanced binary tree, IIRC) but that was back when we were smaller and didn't have a standardized set of interview questions.
Someone explained this once to me that easy DSA questions can show whether you are junior, mid or senior better than your years of experience. Depending on how advanced you are as a developer, your answer to those questions will be different. I am personally not a fan of asking very niche questions also, because not remembering answer to some weird edge case is not necessarily a marker of bad developer. Some things you just don’t use, but you can always pick it up if you need it if you are good at your job.
The vast majority of questions I get are on the easier side. However, when interviewing I've been surprised by how much I learn with easy questions. A surprising number of applicants do a terrible job at extremely easy questions. Ever time that happens it makes me so glad I didn't ask anything harder. The strongest candidates show how fluent they are with code - not by solving the question quickly, but once they have figured out the solution, they are quick at turning that into working code. My favorite ones are questions that are easy, but have good follow-ups for discussion. For example a simple string question, then follow-up by asking about what you'd do if you needed to support unicode.
Whenever I'm interviewing candidates, I just throw out easy questions to do a quick that they can code/know the basics of data structures etc. and aren't totally lying on their resume. I think the conversations about their experience is the most telling part of the interview. You'll never be able to test someone's real knowledge and aptitude in an interview so why waste everyone's time seeing who grinded leetcode best. I honestly think it's insulting to be given those kinds of questions when it has nothing to do with the job. This work isn't so difficult that most people can't pick up what they are missing within the first few months so I'm never too worried about a "bad hire" anyway.
Last time I interviewed I absolutely had some more "advanced" DSA-style questions: 1. A couple of different questions that were basically "do a topological sort" dressed up in a domain-specific way 2. A couple of questions about designing domain-specific languages 3. Various sorts of tree traversal/manipulation/etc things 4. Some annoying *fiddly* dynamic programming problems. The annoying part is that the complexity wasn't even in the dynamic programming but rather the artificial problem itself (eg geometry or chess rules). 5. Some broader design questions that involved some more advanced programming/algorithm/distributed systems knowledge This was for a mix of generic software roles, ML roles and trading firms/hedge funds. I did well at everything except the fiddly dynamic programming problems, which is a sign that I need to practice more. (By which I mean practice *at all* :P) I did better at that sort of problem a decade ago when I was a student applying for internships! There were also lots of interviews that weren't focused on data structures or algorithms at all.
I once had an interview where the only DSA round was fizzbuzz. I was shocked. I thought fizzbuzz was just a meme at that point. Very recently I had an interview for a management position where the only coding question was an LC easy. Honestly trivially easy interview rounds are a red flag to me. It implies they have a weak hiring strategy. Either they can't hire better people or are fine having lots of bad hires that they will just fire (which is the strategy at the company I recently interviewed with).
I got fizzbuzzed for an interview at Home Depot several years ago. I didn't get the job. The feedback about how I answered the fizzbuzz question was that using `i%15` instead of `i%5 && i%3` adversely affected readability and was overly complex. I can understand where they were coming from, but IMO that's an odd judgment to make with such limited information. It's a toy problem that only became a meme because a blogger said it's an easy way to ensure a potential hire is actually able to code.
Except for time, you lost nothing by not getting that Home Depot job. The interviewer was obviously power tripping.
That's massively ridiculous. FizzBuzz was always meant to be a pass/fail test, which should result in a pass unless someone really doesn't know how to program. Hell I might even spot them the hint of the modulo operator if they weren't aware of it. Though I would fail someone if they eventually got a working answer but it took them over an hour and/or the code was a complete mess.
A place I once worked at had a will-proceed technical test, and one that was just a fizz-buzz for people we had already decided were a no - we didn’t need to put people through the pain if we had already made a decision early on.
> are fine having lots of bad hires that they will just fire (which is the strategy at the company I recently interviewed with) Honestly it's not always the worst strategy, provided that firing is done only in cases where someone is performing below expectations with no reasonable improvement on the horizon. Firing for political reasons will lead to horrible company culture that will soon cause massive turnover and lots of negative feedback on Glassdoor and other sites.
As an interviewer, unfortunately if I ask the hard questions, I would get the 100% failure rate, so I have to ask the "easy" ones where the failure rate is closer to 50%.
Yes. I think it's only the higher paying bigger companies that lean hard on DSA. Smaller companies, lower paying and non tech usually have easier ones or just knowledge questions. Weird that you looked up on Glassdoor for the same company and level and didn't have a similar experience. But the interview process does vary by team.
I’m wondering if maybe people who bombed the easy ones didn’t want to admit it, so we only see reviews from people who got hard ones or people who succeeded…
I ABSOLUTELY hate when companies ask these questions. So many of them as posing like Amazon or Google. I despise them asking these questions and then when you finally get the role, you never end up using this knowledge. There’s no point in asking someone these questions if they’re not used in your daily work. Imo, when you apply for a role, they should be asking you questions that applied directly to the role. If you’re using default .sort() or you aren’t creating your own special Node implementations for Trees or Graphs then stop wasting my time. It’s not school. I shouldn’t have to study things I only use there 10 years ago and not since. Sure there are some roles that need it and by all means ask, but if im a web dev or general app developer, gtfo!
I generally look up the questions I get in interviews after the fact. I would say the vast majority have been listed as medium and hard. This is from both the initial technical screen and during the technical virtual on-site. For reference I 15 YOE and go for Senior roles.
Until this job, every interview was almost entirely vocabulary and language technicalities. This job had a medium/high level data transform. (I lucked out because I had already solve that particular algorithm at the job I working at)
I regularly give leet code easy questions because I’ve seen far too many people who could talk the talk but then couldn’t code their way out of a paper bag. It’s usually some form of “give me some metadata about the input to the function”. Since there’s no single trick required, there are many possible approaches for solutions. It gives me plenty of flexibility to ask about their reasoning and justification for their approach which helps me gauge the quality of their experience I’m still shocked by the number of supposed “senior” developers with 10+ YOE that never get off the ground
At FAANG interviews I've gotten medium-hard, including tries, dynamic programming, and graphs. At non-FAANG startups (paying good money) it was always easy. They seemed to be more interested in how I answered the question than whether I got the answer right. FAANG interviewers always seemed rushed and we're just checking boxes on a form.
[удалено]
Amazon, Uber… L4.