It shows you can iterate over an array and use conditionals, something literally everyone should be able to do if they know the language. These kinds of tests are a quick way to screen out applicants who are straight up lying about experience with a particular language.
It's not like asking them to write a sorting algorithm or implement Dijkstra's algorithm, which requires specific knowledge of algorithms and isn't trivial to implement. And it's not some obscure brainteaser that has no relevance to their normal work.
Iterating over arrays and using conditional logic is something I do every day. In fact, I'd say that's basically 80% of what my job is.
Granted this is a rural area and ymmv depending on the local average skill level, but still if you want to grade someone from zero to ten you need to start with exercisers close to zero.
Otoh if your interview questions are all 9 or 10 in difficulty most of your candidate will fail them and you'll have no data for a decision because all 8s will fail to answer in the same way as 6s and 3s
Much better to start with some stupid loop and work up from there.
Besides, it's a waste of their time and yours to have someone attempt a 9 or 10 before they show they can pass a 1.
One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identifying the duplicates and eliminating them takes some simple verbal requirements but has a lot of depth. If they cant't do max/min/mean/median, they surely can't do answer that (which our least senior developer was able to do, with guidance (mostly on optimization)).
We have other questions that are much more relevant to day-to-day tasks, but both kinds are important.
Does that problem not require separate thought processes though?
In terms of a max/min/mean/median style problem, the candidate needs to come up with an algorithmic solution to find those values. In the later case of finding duplicates, there is minimal (depending on problem complexity, I suppose) amount of algorithmic complexity and the focus is more on data structures; for instance, does the candidate know they could use a data structure like a hashmap or variant to find unique items with the drawback being an additional storage unit.
So, I guess what I'm trying to trace back to is how you say if they can't answer one then surely they can't solve the other, but (while relatively 'simple' problems) I'd argue they take different mindsets to solve. Obviously in the grand scheme of things one mindset works for both, but in this it can vary a bit.
Anyway, late-night thoughts so hopefully that's not a jumbled-up response.
They aren't exact duplicates. Instead, the code to send an impression was firing repeatedly, so it'd be more like that person refreshing the page once per second thousands of times (except the page content never changes if they don't refresh).
At it's most basic, you're essentially just finding chains of impressions based on lag from the last impression. In practice, we also need to maintain data integrity (foreign keys) and deal with several other issues stemming from common cases where the assumption 'if they are within X seconds, count as duplicate' doesn't hold.
So you could completely ignore performance and still have a question that could prompt a lot of discussion with a candidate (though performance should be part of that discussion). I'm not sure if we'll end up using it due to the relatively large amount of baggage associated with the problem (table layout and business requirements), I've just been toying with reducing the problem down to a simpler prompt that would be feasible.
I'm fairly new to interviewing/hiring, but I really like questions that cut across multiple 'areas of competency' and are amenable to asking followup questions ('what if we wanted to add X?'). Algorithmic questions have their place, but have less day-to-day relevance. We can teach algorithmic stuff on the job.
I think your point would be fair for more complex problems, but getting the max of a list is something anybody of a logical mind could easily do even without knowing any formal programming language. And for those that do know a formal programming language it comes down to the most incredibly trivial basics of a language - comparison/variable/iteration.
In other words a self declared software developer who can't tell you how to get the max of a list is not going to be a good software developer.
I think what you’re might be missing is the basic fact that programming is so stupid lucrative, especially compared to the other jobs that are out there, people will do anything to get these jobs. I’m pretty sure you want your new hire to know HOW the magical library list.max is written. Writing code is surely more than piecing together other people’s utility functions and ideas?
By way of analogy, should your new EE hire be able to compute basic ohms law voltage drop over a resistor? We teach kids this formula. Is this knowledge too below a senior electrical engineer to still know? Of course not.
Finally, someone’s attitude towards answering these questions will tell you a lot about what kind of person they are to work with. If they are surely and refuse to implement list.max, well then, what will their attitude be when it comes to grungy code tasks?
I interned in a medium sized cloud company this summer and they require you to complete a homework project within 4 hours before interviews. You have to setup an environment in your language of choice, query an rest api, parse some json, do a rather easy rearranging of data and post that back to the api as json. Took me about 1 1/2 hours with simple documentation and cleaning up my code. It really only asked basics you should know, if you ever worked with a CRUD app. They also told you before the clock started that it's about HTTP, REST and JSON so you could prepare.
I heared from multiple people from the local colleges that were friends with other interns that this project was way to hard and they had no way of doing it. But it was the bare minimum you needed to do your job there without having to be babysitted by a senior fulltime.
Even if you usually would use a library function, finding the max of a list or similar problems are still sufficiently simple tasks which every programmer should be able to perform. It's straightforward and not about remembering some complicated algorithm from some CS class years ago nobody ever implements themselves.
Those devs don't understand the reality of interviewing or take offense too easily. The reality is that people lie on their resumes, which makes such questions necessary. If they can pass, they can feel scoff all they want, but they had best answer the question or I will assume they are acting to avoid showing they can't answer it.
It's an unfortunate waste of everyone's time.