The author mentions CLRS. It’s an introductory level algorithms book and is used in Junior/Senior years of undergrad. Expecting a senior engineer to be well versed in undergrad level algorithms is not a monoculture problem.
The problem is not the expectation but that something like that can even come up during an interview for a senior position!
It is like testing a surgeon's suturing skill during a job interview. Of course, it is an essential skill for them to have, but that's something for a school exam and not job interview for someone with verifiable credentials. Or do you think that surgeon didn't suture in their previous job and just "winged it through" for years? What exactly do you hope to achieve with such an interview question?
That's exactly what is wrong with software engineering hiring and interviewing. It is focusing on examining nonsensical minutiae instead of whether the person has any sort of design skills, is capable of teamwork or has any sort of project management skills.
These are way more important for a senior engineer than whether or not they have crammed algorithms for a month and can reproduce them on the spot in front of a whiteboard (and will promptly forget them in a week or two again). That algorithm can be looked up in 5 minutes if needed, lack of project management skill could pretty much doom the company in the worst case.
> It is like testing a surgeon's suturing skill during a job interview. Of course, it is an essential skill for them to have, but that's something for a school exam and not job interview for someone with verifiable credentials. Or do you think that surgeon didn't suture in their previous job and just "winged it through" for years?
Yes, absolutely, I think that some surgeons can be less skilled at suturing after years of experience, and it'd be wise to have them demonstrate these skills in an objective way during a job interview rather than relying on credentials. eg:
> Most methods currently used to assess surgical skill are rather subjective or not adequate for microneurosurgery. Objective and quantitative microneurosurgical skill assessment systems that are capable of accurate measurements are necessary for the further development of microneurosurgery.
> To the researchers’ surprise, there were huge variations in operative skill between the practicing surgeons, with the lowest ranked surgeons working at what the reviewers considered a level only slightly better than a trainee at the end of residency, and the highest-ranking surgeons working like “masters” in their field.
Software engineer interviews are absolutely imperfect, but I don't think other professions have this figured out either.
And you want to say that such assessment is actually done during a job interview and not during, you know, actual surgeries? With a more senior doctor on the team evaluating (and likely mentoring) the new hire?
I was going for brevity. You might be missing my point here, which is: relying on credentials isn't working out as well as people might think for surgeons. They have a much stronger credential requirement, so if it isn't working for them, it probably won't work for hiring software engineers either.
But to answer your question, of the two links I included:
* the first is an artificial test that can be taken any time. Yes, it could be actually done during a job interview, and maybe it should. Alternatively, maybe it should be done yearly, whether that's enforced by the medical licensing board, the hospital, or insurance (either the patients' insurance forces it or the doctor's malpractice insurance).
* the second mentions criteria for ranking performance from a video of an actual surgery. No, I'm not suggesting applicants perform unnecessary surgery on a live patient during the job interview. They can bring a video of their most recent surgery instead.
The details of the best method for surgeons might not be that relevant to hiring software engineers, but I do think for both it's better to evaluate current skill rather than rely on exams from school years ago. Software engineering does this better than most fields, even if it sometimes leads to really bad results like not hiring Dan Luu. [1]
>that's something for a school exam and not job interview for someone with verifiable credentials
The problem is the "verifiable credentials" vary widely in rigor. There is no analogous standardizing and credentialing body like their is in medical fields. So the "basics" need to be tested repeatedly at every new interview. The solution is to have an analogous standardizing body, but people in this field seem to be reflexively against it.
That's BS. Verifiable credentials mean that you pick up a phone and call the references the candidate gave you.
What you are describing is essentially "it varies widely in rigor - so we must subject every candidate to a full CS exam, because we don't trust anyone."
Even in medical field the schools and standards vary, especially between countries. And there are good and bad doctors. Heck, some have even got their diplomas fraudulently.
However, that doesn't mean you will have the prospective hire sit in for an multiple hours/days of redoing university examinations during an interview - as it seems to be the rule in software engineering (and pretty much nowhere else). You would be laughed out if you tried that.
Especially for a senior position, where the candidate has a past experience you could ask about (i.e. not a freshly out of school student).
A standardizing body has its own downsides. The medical credential stigma is real- nurse vs traditional school vs osteopathic school, many of which have been closed to specific races or gender identities historically.
EDIT: Of course, that and the fact technology is extremely rapid. Does this mean software people need to re-credential regularly?
Only if the role you're hiring for requires directly applying those algos. A high level understanding is good but implementation knowledge isn't.
I've been in this industry for almost 15 years. I've never once had to write a low level algo implementation. On the few occasions I had to dig that deep into code I looked up what I'd forgotten. If someone asked me to whiteboard bubble sort I'd choke.
There's no need to know it all by heart and recall it on demand unless the job you're doing requires it.
You rarely need to write your own sort or hashmap, but you should absolutely understand at a high level how those algorithms work, how to analyze them, and the key concepts that go into their design.
The point of the undergrad CS syllabus is not to teach you specific algorithms, but to give you a toolkit for solving problems. The goal of a SWE interview should be to test your ability to apply that toolkit to a "new" problem.
IMO that's not a good interview question even f2f, let alone on email. As an interviewer I would learn nothing from that, and I agree it's unreasonable to give an interviewee homework.
As far as I know, that is not SOP for FANG interviews.
Disclaimer: I'm in a position at FB where I participate in candidate reviews.
> If someone asked me to whiteboard bubble sort I'd choke.
I came in to FB just shy of 20 YOE, and I consider "Google" to be a valid answer to that sort of question. Writing low level algorithms is a waste of time, not a skill. That said, I think it's ok to expect people to be aware of them.
Could you describe the algorithm for it, though? What about traversing a tree? Would you be able to talk it through and then be able to implement it? What about proactively verifying that your algorithm was correct for standard and edge cases? Can you evaluate your solution for time & space complexity?
If the answer to these is yes, that's sufficient to pass the coding interview. This is also where I think think more experienced candidates really shine. Aside from handcrafting algos that are best left to libraries, the others are things that senior folks who have been there and done that just do intuitively.
Interviewers definitely want code that works, but being able to do the other things is equally important. The review process itself also doesn't allow one bad interviewer to sink the candidate.
It is like testing a surgeon's suturing skill during a job interview. Of course, it is an essential skill for them to have, but that's something for a school exam and not job interview for someone with verifiable credentials. Or do you think that surgeon didn't suture in their previous job and just "winged it through" for years? What exactly do you hope to achieve with such an interview question?
That's exactly what is wrong with software engineering hiring and interviewing. It is focusing on examining nonsensical minutiae instead of whether the person has any sort of design skills, is capable of teamwork or has any sort of project management skills.
These are way more important for a senior engineer than whether or not they have crammed algorithms for a month and can reproduce them on the spot in front of a whiteboard (and will promptly forget them in a week or two again). That algorithm can be looked up in 5 minutes if needed, lack of project management skill could pretty much doom the company in the worst case.