When I see a candidate is not sure about some syntax trivia e.g. indexing expressions in Python, names for some library functions like charAt, size, length etc. I tell them to pick one (make it up) and move on. Though lately I've been using a runnable whiteboard with autocomplete so they have been able to figure it out on their own.
It makes me sad to think how hard it would be to remove bad interviewers like above. But as long as they perform reasonably well they won't get fired, and I don't think there is any interview QC system to feed back into the org. And thus we slowly slide from A to B and C territory...
This is why the real-tests should be entirely in pseudo-code and about the logical structure.
Any optimization should happen after a basic algorithm that works and might go along the lines of (telemetry suggests our platform has a bottleneck here) how would you speed things up if there's an issue in this section?
Re:Why I Turned Down an AWS Job Offer
by ShakataGaNai on Monday August 05, 2019 @05:35PM
(#20619281)
I'm with you on this, even beyond the first week. Been doing primarily Python for more than a year now and sometimes I still slide back to my Perl days and write the C-style for.
Okay, I need to iterate through a collection. Which is it again?
foreach (int element in elements), no that's C#.
for (int element : elements) .. nope that's java
for (var element in elements) .. There we go.
Probably wouldn't exactly go like this, I know js isn't typed when I sit down to write it. (except for when it is!) ;)
Regardless, I call this my "tooling up" period. Each day i'm faster, and it takes about a week to get to 100%. but then I'm golden until the project is done and I inevitably have to switch techs again. I probably need to flex more than specialists in interviews because of this. Whenever pseudo code is on the menu I breath a sigh of relief.