>I remember back in the day when we used to just ask people if they could do FizzBuzz now we're looking at if they used an interface to wrap their ORM usage. That's something that can get picked up at code review and taught. Not everyone is going to code by default at the style of a company but they can learn to do the things the company wants.
>Then there is the obivous, lets test people for things they aren't going to do. Google and co made this the in thing and the fact we now have books upon books just designed so people who are good at tech can pass a tech interview is a sign in itself that there is something rotten.
So which is it? Should interviews be related to the work at the job or not? The Google type interviews evolved precisely from the philosophy in your first paragraph I quoted: that a lot of domain knowledge can be learned easily and that it was most important to test for more fundamental knowledge and abilities as well as general problem solving skills.
Ultimately I think it's a lot easier to criticize the interview process than to come up with a good alternative, as well as establishing some basic criteria about what should be selected for and against. Not that I think Google style interviews are perfect or anything, mind.
> So which is it? Should interviews be related to the work at the job or not? The Google type interviews evolved precisely from the philosophy in your first paragraph I quoted: that a lot of domain knowledge can be learned easily and that it was most important to test for more fundamental knowledge and abilities as well as general problem solving skills.
If a company wants to test someones basic logical knowledge and fundmental programming knowledge, seems fair enough.
There is a massive difference between writing FuzzBuzz and knowing the differences and uses from all the different sort algorithms and being to write optmisied computer science code. One tests programming and logical skills to a childs level (FuzzBuzz is a kids game), the other tests computer science skills to a high education level.
If someone wants me to write a basic sorting function, then I would have no issues. But if someone expects me write an optimised quicksort function, nah.
The list of the things these Google style questions ask is big enough thath the books for these interviews is quite big. (Lots of fun to read tho, highly recommend them for people wanting to nerd out)
>Ultimately I think it's a lot easier to criticize the interview process than to come up with a good alternative, as well as establishing some basic criteria about what should be selected for and against. Not that I think Google style interviews are perfect or anything, mind.
Well, I think I did come up with a good alternative, basic interview with work trials. You want to know how good they work, not how good they interview and the two actually are different skills.
> If someone wants me to write a basic sorting function, then I would have no issues. But if someone expects me write an optimised quicksort function, nah.
Let me be a devils attorney here. Understanding efficient sorting and how quicksort works is fundamental CS knowledge. I would say the idea is if you know how quicksort works, you should be able to write the code, no? If one is okay with writing a basic sort function but not quicksort - it could mean (1) that person does not know quicksort, (2) knows quicksort but not a good enough engineer to write code for it or (3) idealistic.
That said, I personally don't believe in testing whether a candidate can write the code for quicksort. I have however found that 'general problem solving skills' typically correlate with good engineers at places where one isn't just building yet another MEAN stack app.
> Well, I think I did come up with a good alternative, basic interview with work trials.
Not practical enough. Do you expect, in the current scenario where there is a demand surplus, for candidates to happily sign up for a trial stint - that is for the "interview" to last one or three months? I personally won't be okay with it because it messes up with a persons stability, their ability to interview at multiple places.
Even if you expect this to be AFTER the onsite interviews, like a probation period, both the company and candidate will want to maximize the # of candidates staying on, which means it doesn't really solve the problem you intended to solve.
Sorting is fundamental. Quicksort is not. It’s a single algorithm out of many.
Quick, without looking it up, in 45 minutes, write an implementation of CC-Radix, cache-conscience radix sort. It is a sort, it deals with performance, therefore it’s fundamental, right? After all, in my last Google and Facebook interviews, the questions were all about performance.
While we’re talking about performance, let’s talk about cache. It’s a fundamental part of computing after all. I tell you that you can pick any architecture you like, except one that is four way set-associative. What percentage of candidates can answer that? 50? 25? What percentage who did not go to certain schools can answer that? Of those who could answer it, how many saw this issue ever come up?
I love hardware, but these days most things are out of my control. Either I’m running on my Mac or on some VM instance I didn’t spin up.
Our field is VAST. It is a natural tendency to be biased towards what you know. Many things can be argued to be fundamental, even writing AND, OR, NOR, and NOT gates from NAND. That’s about as fundamental as it gets. It provides zero insight into the candidate for most groups.
> Let me be a devils attorney here. Understanding efficient sorting and how quicksort works is fundamental CS knowledge. I would say the idea is if you know how quicksort works, you should be able to write the code, no? If one is okay with writing a basic sort function but not quicksort - it could mean (1) that person does not know quicksort, (2) knows quicksort but not a good enough engineer to write code for it or (3) idealistic.
Companies are hiring software engineer not computer scientists. If someone wrote a sort algorithm in a normal job I would expect that not to be used and a library to be used. This is also knowledge that people who studied and aced their tests in Uni forget, because no one in their right mind writes a quicksort.
> Not practical enough. Do you expect, in the current scenario where there is a demand surplus, for candidates to happily sign up for a trial stint - that is for the "interview" to last one or three months? I personally won't be okay with it because it messes up with a persons stability, their ability to interview at multiple places.
People actually sign contracts like that on a daily basis. That is literally what you sign up for. Here is the actual process: CV screening -> Tech Test -> Phone Screening -> Interview -> Trial or "probation".
And the rest of it about people looking for jobs, well that's why companies should be selling/recruiting. The whole "but people won't do that" is clearly wrong since they already do and often jump at their first offer.
> Companies are hiring software engineer not computer scientists. If someone wrote a sort algorithm in a normal job I would expect that not to be used and a library to be used. This is also knowledge that people who studied and aced their tests in Uni forget, because no one in their right mind writes a quicksort.
Typically these questions are asked to entry-level software engineers and not ones with some experience.
Again, I don't believe asking people to write quicksort provides any signal but I was arguing that there isn't any difference between asking a candidate to write a "basic sort" vs "quick sort" in an interview.
I also mentioned this is not a good question to ask if all you are hiring for is some MEAN stack app - but is an appropriate question if you do any development where some optimization is required.
> People actually sign contracts like that on a daily basis. That is literally what you sign up for. Here is the actual process: CV screening -> Tech Test -> Phone Screening -> Interview -> Trial or "probation".
Yes, typically for roles where it is difficult to vet a candidate's skills appropriately during the interview. It is also not an improvement for Software Engineering, imo. If you ask Software Engineers if they might prefer this process over the current process, I think, most would not.
> Yes, typically for roles where it is difficult to vet a candidate's skills appropriately during the interview. It is also not an improvement for Software Engineering, imo. If you ask Software Engineers if they might prefer this process over the current process, I think, most would not.
I think you would be surprised, I am sure there are lots of people who wouldn't be interested in such a methodogly. But you need to remember what the purposal is. Do you want to be interviewed and tested on your skills in an interview and then sign a job contract or would you rather do a possible 2 day tech test. You also need to remember the job market, if I have 5 companies in my job pipeline (I stop adding companies at 5) why would I want to do 5 1 day tech tests?
Yes, its certainly an improvement over the whole-day-take-home-test. I was comparing it with the leetcode style format for junior-mid level engineers and system design for senior level. I would much rather prefer that over contract thing; and also my social bubble. Maybe I am biased.
Although, I do agree that sometimes engineers ask questions that they don't expect to work on at the company. When I interview I ask questions (leetcode style because of the nature of systems involved) based on what problems we typically solve. I never go into advanced graph etc. But good understanding of basic data structures, understanding time complexity, testing is utmost important.
>Then there is the obivous, lets test people for things they aren't going to do. Google and co made this the in thing and the fact we now have books upon books just designed so people who are good at tech can pass a tech interview is a sign in itself that there is something rotten.
So which is it? Should interviews be related to the work at the job or not? The Google type interviews evolved precisely from the philosophy in your first paragraph I quoted: that a lot of domain knowledge can be learned easily and that it was most important to test for more fundamental knowledge and abilities as well as general problem solving skills.
Ultimately I think it's a lot easier to criticize the interview process than to come up with a good alternative, as well as establishing some basic criteria about what should be selected for and against. Not that I think Google style interviews are perfect or anything, mind.