3 ms·
> 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
by 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.
- that_guy_iain 6y ago> 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? And 1-2 tech test is extremely common.
- amf12 6y agoYes, 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.