Common problems I see in technical interviews
blog.interviewing.io
blog.interviewing.io
Holy Cow. 100 lines in an interview ? I had an interview like that once and never again. Want to see 100 lines of my code - github.com/mikadosoftware. In an interview - no thanks
Look we all know interviewing is broken. Hell I have worked with people for months before getting to know them and their coding styles. I think ultimately we are all being a bit too privileged about this : Hiring has three states, acquaintance, friend, spouse.
Some people are not skilled enough to be a work collegue - fizzbuzz and 20 minutes chat tell us that - we all know people who after 20 minutes we think we will pay money to avoid the next 20. Fine
Friends are harder - we gel in some fashion. This is the mid point for most of us - as long as we pass fizzbuzz / basic design, then we can make things work. Yes it might have friction but we can make it work.
Spouse is obviously the perfect level - that ideal together.
I fear that far too much effort is put into finding the perfect spouse in an interview - when really we can be fine with a friend. (no benefits!)
When hiring set your sights lower ...
In my head I just think - Bro why are you asking me to paste code I can memorise?
I use this to figure out which jobs I don't want. It's not the best metric but its worked ok so far.
If you ask me about fizzbuzz I'll complain. Or maybe try to do it in a quirky way
You should have addressed if the candidate knows how to write basic code in the phone interview, not wasting my time with a stupid problem on a whiteboard
Fantastic - you have just shown an ability to play with code, indicating you are likely to be good at the basic part of the job. Honestly "fizzbuzz" is short hand for "eliminate the set of people who apply for every coding job, but have no ability to code, or can only just take existing code and twist it about"
(this last I used to think was laziness, but I think there is an ability to execute code in your head that is necessary - and if you can't do that then making any changes to a code base is scary because you cannot reason about it.)
Do I use fizzbuzz anymore? No because it has been years since I have had to go "out to market" - but if I am interviewing you then I will have checked you pass this - reading your code, talking to co workers. I don't go in cold very often any more.
(im not saying Im right in this)
You can filter people who can't make fore loops works without resorting to fizzbuzz
Will they refuse to manually fix up the test data because it is "beneath" them? Will they think that getting the HTML to float right on that screen is for juniors only?
At some point meet the interviewer halfway.
[0]: https://aphyr.com/posts/340-acing-the-technical-interview
Because fizzbuzz isn't about the code. It's a starting point for a candidate to show an ability to code something, and an understanding of the requirements, and an ability to talk about their code and why it does things in the particular way they wrote it, and to discuss what the next steps would be (streaming, optimizations, etc).
If the coding test is literally just 'write fizzbuzz' then it's a terrible test, but if it's more like 'write fizzbuzz and then we'll talk about it' then it can be a great test.
Coding interviews (and just coding as an art really) should never be about solving a problem in a limited amount of time. The problems we face as developers usually need a few rounds of thinking, experimentation, more thinking, implementation, optimization, and so on. You can't do that process properly in an interview. Using things like fizzbuzz is an attempt at a shortcut.
Also, as someone who interviewed lots of people and used fizzbuzz as a test in the past, I can assure you that simply being capable of implementing it takes you out of the bottom 30% or so. Being able to talk about it and suggest ways to do more with it, or to extend it, would put you in the top 30%. There are a lot of developers out there who are not great.
In my experience, I have been unable to comply with the fizzbuzz questions in interviews - which has generally ended with me or the interviewer slowly closing the interview.
At the same time I was one of 2 people who built a major airlines checkin system within a couple of months.
The interview for this role? A phone call, after looking through my CV.
The roles which asked me fizz buzz? generic roles in companies that since went nowhere, I even got a callback telling me the technical hiring manager had since been fired ( or left ) and if I would re consider interviewing, which I then had to turn down.
I am not saying you are wrong, I am probably wrong to judge a person if they are assessing my years of experience with a test aimed at an 18 year old.
But be aware of how fizzbuzz makes some developers react.
If you have no problem building a major airline checkin system, you must have some practical skills. Can you explain why you couldn't implement fizzbuzz in an interview? What went wrong?
If you designed an interview question which would show off your skills instead of undermine them, what kind of technical questions would you like to be asked instead?
If my friend said to me in a bar "tell me why computers are good" , I would have a deep conversation with him that would cover different domains from philosophy to the sciences.
If an interviewer for a job, requiring a specialist in 4 frameworks, 2 languages, a nosql db, cognito authentication, a complex portfolio which matches the job spec and real world examples of viable commercial products, sat me down in a room, and asked me to answer the same question, as an opener, and it was timed to a minute - I would flounder.
The experienced dev vs the fresh graduate Sure I could have done some research into the several domains, written down a good short concise answer, which covered a general aspect of each domain and recited it. However I did not. I would have no reason to prep for such a question due to the amount of time Ive spent in the commercial sector developing solutions rather than rehearsing interviews like a fresh graduate who has never programmed before would do. Can I solve the problem? Ofcourse, but not as quickly as someone who has revised for it, even if I take a couple of minutes longer, it would be taken badly - regardless of whether it was rote or freshly devised.
You arent selecting for a good developer - you are selecting for someone who has had the time to prepare for interview questions ( a massive red flag in my book )
The answer? Atleast for me.
Is he experienced? Does the conversation flow naturally? Do you feel he is a loyal, dependable person who can clearly communicate? Well I would say that covers 90% of the issue. Hire the guy, see how he performs.
> Is he experienced? Does the conversation flow naturally? Do you feel he is a loyal, dependable person who can clearly communicate? Well I would say that covers 90% of the issue. Hire the guy, see how he performs.
Interesting idea but unfortunately this isn't a viable strategy. There's a mountain of people who are perfectly charming but can't program, and we need to screen them out. And there's plenty of great programmers with awkward social skills who we would love to hire.
A few years ago I interviewed an Indian developer with broken english, who'd spent the last 10 years working on Oracle internals. She wasn't charming or a good conversationalist and her resume had obvious typos. I had very low expectations - but when I interviewed her I realised her technical knowledge was top notch. It took both me and my boss to bat for her for the client to give her a chance. But she ended up outlasting everyone else on her team. The company we placed her at absolutely adore her now. If I didn't go deep on technical content, I wouldn't have known that and we would have passed her up.
Regarding the developer with the broken english, how long a developer stays in a team is not necessarily a good sign, the others could have left because she was hard to work with.
However you said the new company liked her, so thats good, maybe she was great.
When you made your last point about "going deep on technical content being good" I don't think you've understood my point of view very well.
I'm not saying not to ask technical questions, Im saying ask complex ones, where possibly relating to the developers experience.
I have no knowledge of the specific, but I think most people have experienced a freeze up in an interview - I certainly have. (I tried to reimplement basic math functions on a coding test - I still have no idea what happened)
That's why there is no silver bullet - fizzbuzz is an indicator. But we rely on expertise to spot itself - or spot potential. Which is why we need to be careful of just cloning ourselves and our cultural biases.
For example, you could put your Indian dev in front of me and I would not have the Oracle depth to recognise her as skilled enough to go to bat for. But Python internals? Yeah maybe. PostgreSQL once upon a time.
Its frankly still a hard problem.
Then the CEO wanted a quick chat and asked me a simple technical question - and I could not do it. My brain simply froze and he clearly thought I was an idiot or some marketeer pretending to be technical. The reverse being far closer to the truth!
Edit: I've interviewed a lot of people over the years and would never had believed this could happen until it happened to me.
I realise this is a problem with me and stress during long interviews, but it was still a little funny at the time.
When I interviewed regularly I felt like that was probably the biggest difference between a great interviewer and a terrible one. Any decent programmer can ask technical questions, but great interviewers will do everything in their power to help you stay relaxed and calm while you answer them.
When you get too stressed, your creativity then your memory stop working properly. So its simply impossible to fairly assess the technical skills of a candidate while they're on their way to a panic attack. Knowing how to keep people calm is rarely on the job description, but its an essential skill of any good interviewer.
For what it's worth I've been on both sides of the table. I don't bother with code when I interview because it's a waste of time. I may show a (non-critical, not-worth-NDAing) section of code to a prospective employee and have a discussion about it, but in general I can suss out whether someone knows what they are doing in less than 30 minutes just by having a conversation with them. Why make the applicant or me wade through 2-3 hours of code and not get a sense of what they are truly capable of when I can talk to them for 30 minutes and assess their technical ability, communications patterns, and fit for work culture simultaneously?
The smartest people I've ever worked or interviewed with don't bother with code as interview.
That doesn't tell me whether you can code; it's entirely possible the other person did all the coding and you did architecture, requirements, user stories, testing, integration, office politics, SnapChat.
You might still be a great asset to the company; my job as a technical interviewer though is to assess whether you can code.
As an aside this reminded me of "benefit of clergy", where one could get a reduction in sentence if you could prove you were literate in court - by reading out a Psalm in Latin. Now, as it was always the same psalm, illiterate people could memorise the psalm and recite it as if reading.
(of course this was a legal fiction to allow courts to avoid handing out death sentences to all comers).
The thing is fizzbuzz is like Miserere Mei - it's a quick proxy for a form of literacy. Yes, anyone already literate could easily swot up that psalm. But anyone not literate could only learn the words off by heart - and any simple test such as read the next psalm, would unmask them.
So the easiness of fizzbuzz is kind of the point - we are not trying to work out if you are Phd or undergrad level. Just literate.
IIRC, until the literacy test was abolished and the benefit made generally applicable to first-time offenders, the judge had the option of demanding a different work.be read if he suspected the privilege was being abused.
> (of course this was a legal fiction to allow courts to avoid handing out death sentences to all comers).
Well, it evolved into such a fiction (and eventually even the literacy test was removed). But it didn't originate as one, and didn't originally involve a sentence reduction but transfer to ecclesiastical court from secular court.
The interviewing developer was all smugness when looking through the code because he didn't like my bracketing style, or my variable style, and so on, and pissed and moaned because I had a couple of syntax errors in the entire class.
I was offered the job. And I turned them down. I did it to prove I could do it. Then I walked away. That was pretty much my last ever formal interview.
They left me alone for two or three hours and didn't speak to me and at the end I had a chat with the CTO about the code and he was happy enough and all was OK.
The main bit to me was they left me alone - if someone had asked me anything, or even worse, watched me coding I would never have been able to do it.
The time pressure didn't hurt. Had to remind myself about the order of all the necessary system calls on the client and server side to set up the sockets, listen and connect, define a suitable message format, and whatnot. But I had a working client and server talking to each other doing their thing.
What I like about this style of interview is that it demonstrates your ability to be given a high-level problem and then go through requirements, design, implementation, testing then when given new requirements, iterate over the process to meet them. It's much more representative of day to day job requirements than a whiteboard. And being thrown that challenge shortly after coming onsite demonstrates that you can handle the pressure of being given new requirements and new tasks out of the blue and roll with it.
It's 2020: computers have multiple cores, and it's great to know how to use them, but time and time again I see candidates get tripped up with basic concurrency concepts. Deadlocks in go, event loop blocking in node.js, unsafe memory access in Java or C, they come up all the time in interviews I've done.
"Track the median value in a stream of integers"? No problem. Clean code, no errors.
"Track the median value of two streams of integers which are coming in concurrently"? Data loss, deadlocks, concurrent modification exceptions... Sad times.
I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. Every language has libraries of data structures already written, but concurrency solutions are often context specific and need handwritten solutions.
Wanted to second this as it sounds like a great design problem. I personally love reasoning about concurrency models.
You are right, that is hard. Especially in an interview setting. But I 100% agree that it's better than questions about algorithms.
Please recommend the book I wish I had read before jumping in?
My expectations are that a candidate can identify that there is a concurrency consideration to be made in the first place, and have some knowledge around how to handle concurrency issues in their language of choice, since different languages take very different approaches.
For JS/node that could mean identifying that the main execution is single threaded, so you need to use async/await or callbacks for asynchronous tasks to prevent blocking all other execution. In go that could mean understanding that passing messages is generally safer than sharing memory. In java that could be an awareness of the concurrency primitives that the language has like atomics and concurrent data structures (I could never expect a candidate to fully grasp the concurrency nightmare that is java).
I also usually give candidates a laptop and free use of the internet. I try to ask questions that are more grounded in the actual work we do and not just toy algorithms, which means letting people look up documentation, data structures, and whatever else they want. If we're being honest with ourselves, the ability to effectively search the internet is just as important to software engineering as the coding itself, if not more so.
There were no programming tasks. It was a 3-tiered conceptual question on designing a backend system. They asked me how I would do this and that. How would I handle this edge case? What if the user did this? What if the data was shaped like this?
I don't think I even did that well in it, but it was the most enjoyable interview process I have had.
I think most egregious problems are:
1) candidates assuming that I am only interested in them producing a solution
2) candidates assuming that I am interested in checking their knowledge of the language or standard library
In fact, the process is mostly what I am interested in and I am pretty happy to give hints and especially when it comes to trivia like what is the name of the function that does some specific thing and what kind of parameters it takes.
I just would like to see how the candidate approaches and deals with the problem. Does he/she have analytical, planned, ordered approach or is everything chaos?
High on my list of things that don't impress me is solving the problem by running the code dozens of times. This shows the person cannot write any stretch of the code without running it because he/she does not actually have a mental model of what is going on and relies on actually running the code as a crutch for their lack of understanding.
And about running the code often, what's the problem with getting early feedback? There are people (that I agree with) that run the unit test on the code they're writing every added line or two. Some who also commit every line or two and then squash the commits once the whole "unit" is done. By no means does this mean they don't know what's going on
I think giving the candidate a hint has a purpose and that is to keep the process of finding a solution progressing. Otherwise the candidate may get stuck and as an interviewer this is bad because we are now wasting time to let me know the candidate.
At the very beginning I tell the candidate some of the things that I feel are fine or not fine. For example, I will tell the candidate that I am happy to give out names of functions and lists of parameters as long as the candidate can describe exactly what the function is doing. So I give these for free because in normal work I would expect he/she can find it in couple of seconds on the internet, anyway, and that's also how I do this. What I don't give for free (ie. mentally deduct points for) is give larger hints that would normally be thought as part of the solution.
Likewise, when I start technical question section I tell candidates that "I give 5 points for not answering the question". Most people are quick enough to figure out this means I penalize bad answers and would prefer the candidate to say they don't know something rather than keep talking nonsense.
The failings of interviewers are whole other, not less interesting, story.
As to your point, it is completely misplaced in that list which is list of problems with my candidates.
When I interview candidates I am expected to do my job which is to treat the candidate humanely and give back quality, actionable feedback.
Why wouldn't I be able to evaluate candidate's approach? Can he solve the problem? If his approach is so good I can't understand it why then he wasn't able to solve the problem?
Why would that happen on a problem I chose? When I put up a problem for my candidate I have already solved it in every imaginable way so I know ins and outs of every possible solution. I do that so that I can stop focusing on the approach and focus on the candidate because that is ultimately my task. I can imagine the candidate providing another solution but why wouldn't I be able to even evaluate the solution if I have spent so much effort on relatively simple problem already?
It is also important to understand, that the job of the interviewer is not to approve every good candidate. The job is to prevent bad candidates from getting hired. It is expected that some good candidates will be lost in the process and it is acceptable, because hiring a bad candidate is much, much worse than loosing a good one. If you loose a good candidate you have a queue of other candidates so the worst that will happen is you will spend a little bit more on acquisition and maybe make a little suboptimal decision. If you hire bad candidate you are tied to him/her for a long time and usually have to expend huge amount of resources before the candidate is finally let go or maybe while he/she stays indefinitely, blocking your ability to find better candidate.
I think there's more to being a successful employed programmer than that. How do you avoid people who are nice as pie in the interview, but play politics and are rude to people under your nose on the job? How do you avoid people who can deploy algorithms on demand, but have very little motivation day to day and fail to get anything substantial done?
At a job, you're interacting with people every day. I don't think you're looking for the best-performing algorithm every day. In most cases, best performance doesn't matter.
If I'm treated like this at an interview I'm going to assume it's the kind of company where seagull managers write tickets with confusing titles and no descriptions, and expect developers to do their job.
I can either think OR talk, I can't do both at the same time. I can happily think and THEN talk but when I've interviewed with companies that have this interview culture (i.e. Google) they don't let you do this. They start telling you they want to hear what you're thinking. Also, most of the time thinking is disjointed and nonsensical and is way faster than what you can express so it's actually disrupting the problem solving. I really don't understand what's wrong with letting people think for a few minutes.
Additionally I am perfectly fluent in English and talk code everyday in English but it's not my mother tongue so having me chit-chat my thinking away while I think (potentially in another language) hinders me since I focus more on what I am saying than actually solving the problem.
>> "My typical work process in a technical challenge like this is to spend a minute or two thinking quietly about the problem and writing down notes, I’ll share those thoughts with you in a moment to get your input"
That's great, but that hasn't been my experience. Interviewers constantly tell you to talk and it's specially bad during a phone interview. I'd be fine if the interview was really setup as a collaboration between two people, but it's not, you're given a problem and a whiteboard.
Usually, they'll pose the task, sit back, and stare at you. You ask a clarifying question, but you know you're stalling for time. The task is clear. You just need to remember the LeetCode solution. The interviewer looks at you impatiently.
You take a stab at describing the solution. You say, "I think this is a job for prefix trees," and look at the interviewer.
The interviewer says, "OK," and gives you a look of alarm and pity.
You solve the problem the way you've solved ten very similar problems on LeetCode. The interviewer says, "Are you sure this works the way you think it does?"
You panic. What did you do wrong?! The interviewer gives you another look of pity.
If you're writing live code, you run it with some test cases. The test cases pass. You think of some edge cases. They pass too. You look at the interviewer. The interviewer says, "OK." A moment elapses.
A few days later the recruiter calls you and extends you a verbal offer. Or they send you an email that says that you won't be getting an offer. The interviewer's expression of pity is the same in either case.
My experience is in the games industry and interviews there are usually more about what you've done which eventually leads to implementation details from where you can easily gather if the person knows what they're talking about.
What about sharing expectations and the way the dev will be evaluated with them beforehand?
> Interviewers want to know what’s going on in your thought process. It’s important that they know how you’re making decisions. How are you qualifying or disqualifying ideas? Why are you choosing to implement something in a particular way? Did you spot a potential problem in your code? What was it?
That is a very good way to hire people that are good at interviewing or selling themselves, not so much for very good developers.
Speaking loudly about every tiny decision you take for simple algorithms is very hard and inefficient. It is even worse when you have a lot of experience, because you just know which designs will be wrong or not without even thinking twice about it.
It is okay to expect communication about the overall design, specifications, input, outputs and behavior, not about the algorithm itself. If spoken human languages were efficient at expressing this kind of thoughts patterns, we wouldn't have invented mathematics notation or programming languages.
> “I wonder if … hmm … well, I was thinking about implementing this as a depth-first-search, but given a constraint around ___ I think a better approach might be ___, what do you think?”
If you have this kind of expectations, you are again hiring people that are good at interviewing, that is all. I have been a developer for 15 years and I don't know how most of the basic algorithms are called in English, because it is not a useful vocabulary in my everyday work.
I make specific algorithms to efficiently solve specific problems. I do not blindly copy patterns from Stack overflow or from a book. I would not know what is a "depth-first-search" unless I start searching and looking for some code in Google either.
First, you have to understand that most candidates who apply for a technical position don't really know how to program. The obvious reason for this is that weak candidates spend more time trying to be hired, and thus they apply for far more jobs than qualified candidates. I'd estimate about half the people who apply for an advertised software engineering position can't program something as simple as fizz buzz. Many of these people are lovely humans, have families to support and are depressed from being turned down from job after job. But if you can't program, I can't hire you for a programming role. And for everyone who's competent, I get it. Simple programming problems are a waste of your time. But as an interviewer, I need to quickly differentiate you from someone who spent 3 days watching python videos on youtube then forked some random repositories into their github account.
As an interviewer, I'm really trying to answer this question: If I put you in a team of programmers, would you be able to meaningfully contribute? If you want to know how to land your dream job, take a minute to brainstorm which what qualities would make you effective in the role you're applying to. Then demonstrate those qualities in an interview. Your list will look almost identical to mine - be proactive, have good communication skills, know how to program, know the domain (web / ios / ...), etc.
If you can't demonstrate a skill in the interview, your interviewer will assume its because you don't have that skill. This is a reasonable assumption and - despite all the grumbling in these threads - usually true. Most people who fail interviews either have poor technical skills or poor communication skills or both. If your interviewer can't tell the difference between you and the mountain of disappointing candidates they're drowning in, its your job to figure out why thats the case and fix it. If you apply for a frontend web position but you can't tell me what a CSS selector is, its not the fault of "the system" when you don't get hired.
Lots of folks here are convinced technical interviews are fundamentally broken. I still haven't seen any fairer way to assess programmers that can filter out the flood of weak applicants. If you think technical interviews are broken, I challenge you to suggest a viable alternative. Please - prove me wrong!
I gave up looking for work, when I realized that it was my job to throw the seed into the interviewer’s nest.
”God gives every bird its food, but He does not throw it into the nest." -J.G. Holland
I was a hiring manager for 25 years. Hiring people was always a huge commitment. I had to fight like hell for every headcount, and I kept high-end engineers for decades.
I wasn’t just interviewing workers; I was interviewing family.
I could usually determine basic engineering (not just “coding”) skills after a half hour, and without having to write a single line of code. A big reason for that, was because I worked hard to maintain my own engineering chops throughout my management career, and that helped me to relate well with prospects.
Most of the interview was about whether or not the employee would strengthen or weaken the team. Whether they would be conscientious and disciplined in their approach; whether they would be enthusiastic and spend time learning the why of a task, as opposed to just the what.
I was interviewing really senior-level engineers. These were people that would need to write high-performance pipeline code, and most of the prospects had no experience in that particular field. I needed to hire people that would learn new algorithms and techniques. Enthusiasm, flexibility, humility, and open-mindedness were the currency; not rote and bluster.
I also wanted them to know what they were getting into. I wouldn’t ever lie to prospects, and that probably cost me a few, but I wouldn’t want to establish a relationship on sand. I loved what I did, and wanted people that would also love it.
I’m not egotistical, but I am confident in my own engineering (there’s that word again) skill and experience. I don’t demand worship, but I want some simple respect. If you won’t give that to me in an interview, then why should I expect it from you, once you have the free milk? I have had many friends that have left their jobs; uprooted their lives, and headed for greener pastures, only to come back, a few months later, humbled and broken.
If you are interested in me, then you are interested in someone that can make an enormous difference in your company. I’m not God’s gift to programming, but I have a unique mix of skills and experience that could really give your effort a big push.
I’m also a damn decent person, which becomes obvious after a fairly short conversation. I interview well.
But I test badly.
It was never the company. It was me. The company was a corporation, and they were way too stuffy to do that whole "family" thing.
I kept senior-level C++ engineers for decades (I am not exaggerating). It was a small, high-functioning team that wrote image processing pipeleines for a very well-known company.
I am aware that today's entire management style is based on engineers staying at a company for an average of eighteen months. That's crazy. I worked for a Japanese company, and the Japanese would barely even acknowledge my staff, until they had been there at least a year. It was really important for me to keep engineers for as long as possible.
NEVER underestimate the impact of decent first-level managers. It is often said that armies run on their sergeants. First-level managers are the sergeants of the workforce. I was never interested in becoming a commissioned officer. I liked staying close to the ground. I'm entirely capable of doing extremely good strategy; I just didn't like it. I had to be dragged kicking and screaming into management, and being a sergeant was as high as I could tolerate.
I'm a really good manager, but I also never liked it. That's why I have returned to my engineering roots.
Pretending that everyone is a friend is not necessarily good either because straightening a friend is much more harder than a colleague, so you end up not taking the right decisions by fear of frustrating and losing your friend.
I agree with rimliu for those reasons. Coworker relationships have to be different than family or friends, but that does not mean being inhuman or disrespectful, and it is not incompatible with a good and fun ambiance.
You are correct. It is a different type of relationship.
In my experience, I had two primary goals:
1) The corporate strategy and tactical direction. 2) The productivity, cost-efficiency, well-being, and cohesiveness of the team.
My stuff came after that.
In any case, you're determined to find fault with my experience and outlook. I get that. I am quite aware that my approach is orthogonal to "industry standard," and that makes people uncomfortable. No problem. We'll probably never work together, which may actually be sad. I'm a pretty decent person to work with. I wouldn't be surprised if you were, as well.
I'm big on having an open portfolio. I think that it is a really important component in interviews.
I think an almost perfect interview, is for the prospect to supply some projects, and the interviewer then asks them about their submissions.
Like for me, since I do device control and communication software, a good discussion might be around the patterns that I use to synchronize local model with the server state (spoiler: I use what I call my "staged model" pattern, which I'm considering farming out into another one of my general-purpose SDKs).
This is key. And I understand that not every industry, company or team can hire with the goal of keeping people around for decades, but I can't think of a better place to work or hire people for.
otherwise it's mostly just a power trip for the interviewer and a lousy signal.
oh, and people who like problem #19 on project euler shouldn't be interviewing humans. In fact programmers should not be interviewing other programmers at all, it's not their job.
In a scenario where a programmer leads a team of programmers, why shouldn't they get a say in who will be on the team? Who else would be in a better position to judge team fit? Or aptness at the daily tasks?
Your algorithm will likely be an O(n^2) (n-squared) algorithm because you’ll be iterating over the data in an exponential way
Ok, so the technical interviewer mixes up exponential and polynomial run-time in a blog post about interviewing. Can you spot what's wrong with interviewing in SE?
So if you're thinking of advocating for changes, a single enthusiastic person can often get it done!
Of course, you can only ever change interview processes you've already passed and you'll never have to pass again - so many people focus their attentions elsewhere.
The bigger problem is those who don't recognise the implications at all, or know but don't care. I've worked with both.
Actually I did exactly this when being interviewed, talked about exponential. The interviewer obviously got annoyed and moved on but didn't do the right thing which was to ask me to be precise. Had he, I could have said I meant quadratic. He didn't so we both lost an opportunity.
But putting this kind of thing into an article that has presumably been reviewed by multiple people does, in my view, a fair bit to undermine their credibility.
Don't be snarky."
But--there's absolutely a data interface in C#/.Net called "a grouping". It's fundamental to LINQ: https://docs.microsoft.com/en-us/dotnet/api/system.linq.igro...
Shameful to spread the idea that software developers haven't created an industry-standard interface for groupings of enumerable data in 2020.