3 ms·

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

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

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