4 ms·

>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. Th

>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.

that_guy_iain 6y ago
> 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.
- amf12 6y ago
  > 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.
  - that_guy_iain 6y ago
    > 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.

that_guy_iain 6y ago

> 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.

amf12 6y ago
> 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.
- that_guy_iain 6y ago
  > 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.