If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.
> Past companies and open source contributions are not perfect indicators.
This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase? I run a tiny throwaway open source project (~600 GH stars) and even my reviews are pretty stringent. This point of view is not consistent. It's like saying "I know people that ran in marathons, but couldn't even run for half a mile in my interview."
> If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.
I've seen similar. I wouldn't say 80%, but somewhere in the 20% range of people on phone screens. If I ask a similar modulo question that isn't obviously a rephrased FizzBuzz (i.e. "write a function that returns every 4th item in a list"), that percentage goes up dramatically. A lot of candidates memorize FizzBuzz without actually understanding what's happening and how to use it.
> This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase? I run a tiny throwaway open source project (~600 GH stars) and even my reviews are pretty stringent. This point of view is not consistent. It's like saying "I know people that ran in marathons, but couldn't even run for half a mile in my interview."
There are no time constraints, and no way to tell how much of their contribution is from their own knowledge and how much is copied from StackOverflow/other open source projects/etc. The point of view is consistent; I can't run a marathon, but I can walk 26 miles. That's fine for the local charity marathon, but it's not going to cut it if I want to do competitive marathons. The constraints and expectations are wildly different.
Programming verbally over the phone is a skill that requires learning.
I can run a marathon but I can't run 100. Your interview is one of many that I am making time over lunch. I'm tired and getting a perfect mark on a take home isn't as important as getting it done quickly so I can find time to apply to other positions before I go back to work.
If you are not paying someone to do the interview you are not going to get anyone's best. Even if you pay people are trying to juggle things to get the interview to work.
And to the parent post. 50% of people being late means they took the time out to talk to you and come to your offices and didn't gage the time or didn't think it mattered. That doesn't make them bad programmers and shouldn't even matter to the interviewer. Was the car service the employer used late picking the employee or did they have to come on their own?
Even ignoring the fact that you keep moving the goalposts and are taking my "marathon" analogy way too literally, the argument that any kind of real-world coding involves "time constraints" akin to a 30-minute stress-ridden whiteboard interview is just bonkers.
>This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase?
They could maybe just be making small or simple changes. Or perhaps mostly working on markup, templates, CSS, etc.
It's possible they know a bit of programming but just don't happen to know how to check if a number is evenly divisible by another number. This isn't something an open source project would necessarily know you don't know. (I agree it's something any programmer should know, but I can see how someone could contribute certain things to certain projects without that knowledge gap being discovered.)
I learned about the modulo operator very early on, but if I didn't know it existed, I'd admittedly struggle with the question for a bit and would seem like I don't know how to program; especially in a pressured interview environment. If it were Python or something I think I'd come up with something awkward like `if i / divisor == float(int(i / divisor))` within a minute or a few minutes, but who knows, maybe the pressure would mess with me.
> If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.
I dunno about the back half (blowing up million dollar system) but the front half, certainly.
We used to ask "write min()" at a previous employ, and the pass rate was probably <50%. I still to this day structure my coding question around "it has to get them to write a for() loop". It's not trick questions (I understand why people don't like those, and those can die out, yes.) it's things like "here's a sample grammar, how would we go about parsing it?" which is something that I've used any number of times in my career.¹ Other candidates fail to display understanding, let alone deep understanding, about things like HTTP or Linux. Not exactly niche topics, and during this example period my employer at the time was clearly posting for "backend software engineer". And not just one or the other, but all of them, simultaneously. Since I can't establish any proof of anything, so… what other choice is there, but to pass?
¹while there are parsing libraries, yes, and I'll use those first / when I can, I would also say that 50% of the time, for whatever reason — better error reporting, better control — I end up going with a partially or mostly hand-rolled state machine or recursive descent parser. Also, while I wish people would just encode their data in something like JSON, or YAML, or whatever, it doesn't really matter, they. keep. making. new. grammars. Often inside those other grammars. Just today I had to deal with a config — a YAML config! — that wanted "key values". Turns out, it wanted strings formatted like "key:value", not YAML mappings.
> If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection.
With a bad pipeline, it's extremely likely, especially if you cheap out and try the bootcamp route (there's a reason Lambda is desperate enough they will "loan" a student you can try before you hire!).
If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.
> Past companies and open source contributions are not perfect indicators.
This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase? I run a tiny throwaway open source project (~600 GH stars) and even my reviews are pretty stringent. This point of view is not consistent. It's like saying "I know people that ran in marathons, but couldn't even run for half a mile in my interview."