"The biggest problem with interviewing self-taught programmers, is that their vocabulary is often weak"
Would you mind explaining/elaborating this point?
Would you mind explaining/elaborating this point?
For example:
- intuitively applying SOLID without knowing that there is a set of principles
- knowing how to play with closures without knowing the dictionary definitions of “closure”
This makes interviewing a bit harder and might lead people to (falsely) assume that the candidate isn’t any good.
Very much like bike shedding: zealously insisting on <acronym> for every triviality, never doing so for more complex situations.
[x] closures
[ ] solid
Candidate had 1/2. Rejected. Now back to shitposting on HN.
(Not to mention they are, in essence, very subjective principles)
Closure don’t seem to be widely discussed outside of certain areas, so be it.
SOLID is rather surprising though. It seems to be quoted and (supposedly) adhered to religiously. Though I suspect it’s akin to people preaching TDD in public while we all know that’s rarely the case.
SOLID sounds nice but I don't think I've ever seen anyone adhere to it religiously. Easy exercise: take any Java program, and imagine the spec changed the width of integers it needs to support, from 32-bit to some other size. How many files would you need to touch to make this change? Clearly, no class in the program has the Single Responsibility of this. The first letter of SOLID is already violated.
It sounds like they're just describing recursive data structures? When most people talk about closures, aren't they referring to this (from Wikipedia)?
"In programming languages, a closure, also lexical closure or function closure, is a technique for implementing lexically scoped name binding in a language with first-class functions. Operationally, a closure is a record storing a function[a] together with an environment."
EDIT: My SICP quote was actually from somebody's notes, not the book itself. But the point remains.
I'm sure the opposite exists too, interviewees who can rattle off the names and principles at interview, but don't actually apply them in their code.
Provided many candidates fall on one side or the other, what does one prefer?
When I talk to a person who studied algorithms in school they know phrases like amortized analysis and big O notation for time and space complexity. For self taught programmers they can often tell me an expected runtime and expected runspace.
For concurrency persons often use words like counting-semaphore, threads, and blocking operations may not be universal
Self taught programmers may know about unit and regression tests and code coverage, may not be thinking about execution paths as a graph problem.
The understanding is usually there. It is often even the case that a self taught programmer have no standard words for a particular pattern they use regularly. It becomes the interviewer responsibility to decide how much of the vocabulary is important for the job.
----
This is a different problem than not knowing how to use a domain. Things like SOLID, I have never been asked in an interview. I have never studied them in school. I would be subject to the same interview challenges as someone who was self taught in these topics despite my degrees