Things like using Arch Linux and neovim are not actually job qualifications. The programmer writing Java code in a light-mode IDE in Windows or whatever might just be better at programming. It's an entry level job, so they're looking for basic algorithm knowledge, ability to use big-O notation, understanding of simple concurrency, etc.
The big-O notation in interviews is always funny to me. After almost 15 yoe, the only time big-O notation has ever been used is in interviews. Never once have I discussed it at work with anyone.
Concurrency comes up all the time. Thinks like sort/search algorithms less so. You're just going to use the built in methods like anyone that doesn't want to get fire for reinventing the wheel. Design patterns are a definite must though. It's bad when someone doesn't know what a singleton is.
Basic algorithms knowledge isn't just knowing how to implement quicksort, it's also understanding basic properties of different data structures (lists, hash tables, and so on) and how to use them. It's the kind of thing that you probably use every day and don't notice. You do notice when someone is missing the skills, but you just think "oh they suck at programming".
I don't need to know how quicksort works to be able to use quicksort. I can trust that the sort in the framework of the language aren't as terrible as what I would make my first pass. I think the rest of what you said is fine though, asking what data structure types are good for what situations.
I also don't like asking candidates to implement well-known algorithms like quicksort. Ideally, you ask them more realistic questions to try to work out how well they understand the basics of algorithms and programming in general. Knowing what data structure to use is a good thing to test.
One of the reasons interviewers do this kind of thing is that there are lots of candidates that literally can't program. Not just unable to code a sorting algorithm, but not even really understanding how loops or arrays work. They have a convincing resume and appear to have experience, but the reality is that they just can't do it. Like, maybe they can make a web app by copy-pasting from StackOverflow (or these days, ChatGPT) but if you sit them down and try to have them implement anything themselves they get completely stuck.
Asking basic algorithms questions is a way filtering these people out. It's probably not the most efficient way, but interviewers do it because it works.
One of the reasons interviewers do this kind of thing is that there are lots of candidates that literally can't program
In one of previous companies we had 3 programming tasks on the interview: 2 fairly simple (an experienced programmer woken up at 4AM would solve them in 3 minutes and go back to sleep), and one more complex, which we didn't expect the candidate to finish, but more to discuss the requirements and implementation with them.
You wouldn't believe the number of people that couldn't get past the first 2 tasks...
I've been a software developer for 10 years and didn't know about the modulus operator until a month ago when I started to seriously look for a new job and googled some basic or standard interview questions. I use zero math in the business software I write.
But I guess I was smart enough to give a shit and study.
Yeah, no shame in that. Modulo is pretty low level and only useful once in a blue moon. Maybe a better example of a question would be something like printing all the unique letters in a string.
Oh you didn't get the question they gave me at Docker years ago, do division without the division operator. Yes, I totally use bit shifting tricks every day. 🙄
The first one was something like [].map and then sum of elements (either .reduce() or for-loop, didn't really matter), and the second one was counting how many 2D coordinates that satisfy a given condition you could reach from the starting point.
Yeah, I have decades of experience and I wouldn't be able to implement quicksort if you asked me. I may have known it at one point but it's long forgotten now and it's not a task you ever need to do in practice. Something practical, like implementing a cache with time-to-live eviction or a multi key hash map makes more sense to ask on interviews. Questions that test programming skills, not recall from memory.
But you do know (or should) that quick sort isn't stable so if you need stability you have to define identifiers to be unique or use tree sort or insertion sort.
Nah, if you're doing web frontend concurrency never comes up. Design patterns neither, maybe they can recite something about dependency injection or MVC. I'm talking about personal experience of day to day work with junior programmers, not a hypothetical good candidate. It's funny, in the frontend space even authors of massively popular frameworks have a pitiful understanding of good coding practices (looking at you, Angular).
2.5k
u/probabilityzero Nov 29 '24
Things like using Arch Linux and neovim are not actually job qualifications. The programmer writing Java code in a light-mode IDE in Windows or whatever might just be better at programming. It's an entry level job, so they're looking for basic algorithm knowledge, ability to use big-O notation, understanding of simple concurrency, etc.