Yes, because we all know that your ability to implement a red-black tree from memory has a direct correlation with your ability to implement some random business logic or CRUD app. Oh wait, they don't.
I used to think along these lines. Then I started doing 10+ interviews a month and realized a very clear reality: basic CS knowledge and problem skills is far more important to me and my team then knowing how to slap together some semblance of a working CRUD system.
I ask "algorithmic" questions, normally expressed as a legitimate business case (invent a real world problem, solution is implement some algorithm or use specific data structure). My warm up question typically is a simplistic "find the subset in a given collection that matches this specific criteria" (with a subtle implication of "do it efficiently"). The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements.
Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". The scenario of a coder who can't solve my warm-up being let loose on code I actively maintain makes my stomach churn.
Until I see the average bar for problem solving go up, I'm going to keep asking basic CS questions in my coding interviews. The job is to solve complex, typically ambiguous problems. Coding is one of the tools - and I want peers who understand the theory behind using those tools.
(I should note, I tend not to pay attention to credentials on a resume. I care more about ability to do the job then past history - though if a candidate has a masters in some field of CS, I might delve into it a bit out of curiosity... they are an expert afterall)
"I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate." Scott Meyers
I'll take this guy's word over yours I'm sorry. Your supposedly simple use case is given in a different environmental surrounding than a typical day on the job.
At no point did I suggest I ask anyone to design anything - it's a simple question with a simple solution (if they know how to program).
My opinion, of course, but a "good programmer" can think through the solution entirely in their head without hands touching keyboard. Code is the byproduct of the person's thoughts. I'm looking for people who think like programmers. If that bar is too high, I'm rather disappointed with the state of the programming community.
Some of us don't "slap together some semblance of a working CRUD system", but put a bit of thought into it in order to make a maintainable app that works as it should and is scalable when necessary. That requires plenty of knowledge, but algorithmic CS stuff isn't high on that list.
That requires plenty of knowledge, but algorithmic CS stuff isn't high on that list.
I'm not sure I agree – in my experience there is at least a direct correlation between 'knows about scalability, performance and maintainability' and 'knows about data structures and algorithms'. Maybe they aren't going to be able to tell you about the performance edge-cases of different sorts or whatever, but I'd probably still expect to see at least awareness of a difference existing.
>The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements.
>Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions".
You need to ask yourself why you believe the "average coder" should be able to solve that because clearly your beliefs are not founded in reality.
This is what I cannot understand about interviewers who are constantly frustrated with the population's skillset: You obviously have higher skill standards than the average. That is fine. Just accept you will have less hires because none of you are capable of fixing the entire population's skill levels.
"You need to ask yourself why you believe the "average coder" should be able to solve that because clearly your beliefs are not founded in reality."
Oh, stop.
The problem he describes is trivial, and something that you'll encounter as an entry-level web developer on a regular basis. If you can't solve it, you're absolutely not up to the job. In fact, I'll go further: if you literally cannot find an efficient way to filter a list of stuff based on a criteria, you're not even a programmer yet. It doesn't matter if you've "written" a dozen toy webapps by stringing together NPM modules -- not knowing these basic things makes you a danger to any team that hires you.
You can't judge the quality of a test exclusively by the number of people who fail it. If you resume screen for "has written code before" and 80% of your applicants fail that test, is your standard set too high?
(In case you're wondering, that's not a hypothetical example.)
> If you resume screen for "has written code before"
I wish that was the resume screen criteria at all the places that ignored my applications.
The more I read these threads the more I think resume filtering is part of the problem. It makes some sense; if the bad applicants have to apply to hundreds of jobs to get hired they have likely learned how to game the resume scteen.
Resume filtering is terrible - I tend not to be involved in the process since usually recruiters or hiring managers do this. However, when someone stops by my desk and asks "should we schedule a phone screen with this candidate who lists HTML, CSS, and jQuery, as programming languages" for a senior web developer position, I say no.
A huge problem is people list technologies as keywords on their resumes and rarely indicate they know what those words even mean. This makes screening next to impossible at scale (think 1000's of resumes coming in for a single position).
I know this isn't always the case, but how does one note competency in a given language or with a given tool(set) while fitting a resume on a single sheet. Especially if it's for a senior/lead or higher position?
There's a lot that's broken with the hiring process. One of the toughest thing as a potential candidate is how to properly tailor a resume to fit the bill without "gaming" the hiring process. There is no standard - only methods that work better than others in most situations.
"find the subset in a given collection that matches this specific criteria"
So basically, a loop through a single table. That's as simple as it gets. You can make the problem more complicated, of course (e.g. "write a method to find the minimum and maximum ages of the male users"), but it's still pretty simple stuff.
A slightly less trivial "algorithm" question that should be equally easy for any decent programmer: I give you a document of english words. Write a function that counts the words, and returns the top ten words seen, by frequency. Now...solve the same problem when it's not a single document, but a stream of words of unspecified length. Don't run out of memory.
Depending on the wording it looks like his go to intro problem is actually easier than Fizz-Buzz as it is just filtering. For example say it was "Given a set return a subset where the values are less than 10." (such as set.Where(i => i < 10))
I would like to see a solution to your problem with bounded memory.
In particular, the case where I want the top 3 words, you don't know the length of the stream, and you get random permutations of the same 4 words until I stop emitting them (where I will end by emitting 3 to break the tie).
That's not to say your problem isn't interesting -- just that while specifically constructing a problem as an example, you created one that's unbounded in required memory (in both storage per value and potentially number of values to store) and then demanded a solution that doesn't run out of memory.
I think most interview questions are similar nonsense.
That's more advanced then the question I ask typically. Though I might use something like this if I'm interviewing someone with many years of experience (10+).
As I explained above, my question is a warm up - meant to break the ice, calm nerves. But it's surprising to me how effective even a simple list traversal is at identifying weaknesses in a candidates programming ability.
Depending on the platform, there's at least 2 ways to do that :-)
E.g. - "functional" is simply something like:
subset = filter( predicate, superset )
... but on a "procedural" platform, it's a bit more challenging, starting with how much space to allocate for the result, or whether to mutate the input, and other wading through the swamp.
But, yeah, I can see how it would get people to start up talking somewhere, or else go into "deer in the headlights" mode.
Just out of curiosity: how would you feel if I answered this question by using existing function [1] in stdlib? Would you consider that as (good) sign of knowing the tools or would you prefer a fresh implementation?
Heh, at my previous employer the only coding question we asked during interviews was: "Find the largest element in an array of integers." Some of the ways people found to not solve that simple problem were amazing.
Now, I'm generally against asking hard-core CS questions in a live interview... but a simple bozo filter is probably a good idea.
You interpreted what he said as "average applying coder", but he probably meant "average employed coder".
The people that weren't successful during the interview today? They are going to have more interviews tomorrow and next week too. Doesn't mean they are representative of the average coder (most of whom are not being interviewed, because they have jobs already).
The population is skilled enough, it's just that of those who are left, most are not (so it takes more time to fill positions).
I think the key to the questions being asked at an interview is "relevance". How relevant are the interview questions to the actual job that I am applying for ? The off the hand warm up questions are fine, but in my personal experience of 18 interviews, I have not been asked a single question that I would consider relevant to the work I did/will do. Trees? yeah. Design this and that? yeah. Puzzles? you name it. Java specifics and countless Big O and Sigma questions. What about Refactoring? Nope. About designing especially for webapps? Nope. Ok, optimizing legacy code ? nope. Database structure and query optimization? Nope. Data migrations? Nope. Multithreaded support for this piece of code? Nope.
The thing is I have an arsenal of useful information and skills that I have learnt over the years that will not be asked in my next interview. I have personally been developing a list of interesting issues that I face on a day to day basis. I share it with as many people as I can some who participate actively in the interviewing process. Many do not agree with me and I do not hold them for it. I have started small and hope make a change.
Can we quit using this ridiculous example? I'd be willing to bet that less than 1 in 100,000 technical interviews have asked someone to implement an r-b tree considering a full implementation is 100s of lines of code.
I ask "algorithmic" questions, normally expressed as a legitimate business case (invent a real world problem, solution is implement some algorithm or use specific data structure). My warm up question typically is a simplistic "find the subset in a given collection that matches this specific criteria" (with a subtle implication of "do it efficiently"). The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements.
Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". The scenario of a coder who can't solve my warm-up being let loose on code I actively maintain makes my stomach churn.
Until I see the average bar for problem solving go up, I'm going to keep asking basic CS questions in my coding interviews. The job is to solve complex, typically ambiguous problems. Coding is one of the tools - and I want peers who understand the theory behind using those tools.
(I should note, I tend not to pay attention to credentials on a resume. I care more about ability to do the job then past history - though if a candidate has a masters in some field of CS, I might delve into it a bit out of curiosity... they are an expert afterall)