5 ms·
It's hard, and interviewing is better suited to answering "nope, not you!" questions than "yes, you'll be a good fit." Onsite interviews with a range of approa
by Syonyk 2y ago
It's hard, and interviewing is better suited to answering "nope, not you!" questions than "yes, you'll be a good fit."
Onsite interviews with a range of approaches seem to be the best I've found over the years. As much as it pains me, things like fizzbuzz are still useful, because people still lie about their ability to program in languages. If you claim to know C very well and can't knock that out in 5 minutes, and it takes you 45 minutes of prompting, well, you don't know C usefully.
I've seen good results with having a pre-done sort of template program that's missing functionality, and the person completes it out based on comments (for remote interviews), and you can generally tell by watching them type how familiar with the space they are. Again, perfection isn't the goal, but if someone claims to know C very well and is trying to make Javascript syntax work, well, they're full of crap about knowing C.
That said, probably the best approach I've seen for hiring junior dev sorts is a formal summer internship program - and some places have a pretty solid system for doing this, with 20-30 people coming in every summer for a few months. That's a far better way to get to know someone's actual technical skills. In the programs I interacted with, it's safe to assume that if you have 30 people, you'll have about 15 that are "Thank you for your time, good luck..." sorts, maybe 5 or 8 that are "Yeah, you'd probably be a good fit here, and can be trained up in what we need, you'd be welcome back next summer!" and if you're lucky, one or two "HIRE NOW!" sorts that leave the summer program with a job offer.
It's obviously a lot higher effort than interviewing, but the "Throw things at people for three months and see what they do, with a defined end of the program" process seems to be a really good filter for finding quality people.
- withinboredom 2y ago> If you claim to know C very well and can't knock that out in 5 minutes, and it takes you 45 minutes of prompting, well, you don't know C usefully. I recently had an interview and a "skill test" in C. It was proctored by the interviewer in-person. I had so many questions about the questions. It was like, what is the output of "some code" and while obvious, there were some questions where specific CPU architecture mattered: #include <stdio.h> int main() { unsigned int x = 0x01020304; unsigned char *c = (unsigned char*)&x; printf("First byte of x: 0x%02x\n", *c); return 0; } I was like, what architecture are we running on here? So, I answered that "it depends" and explained how it would depend on the architecture. They came back and said that I didn't know C. Sure, whatever. Probably dodged a bullet.
- clarebear123 2y agoWhat architectures would it not be 04 on?
- withinboredom 2y ago(older) ARM (aka, big-endian) it will be 01
- clarebear123 2y agoI just ran it on my M2 mac and got 04. Don't compilers typically take endianness into account for things like this anyway?
- odo1242 2y agoNo, compilers don’t take endianness into account. (especially not C) You need to use a bit mask in order to make this code endian-independent rather than a pointer alias. Like (uint8_t)(int & 0xFF), or something like that.
- Panzer04 2y agoWhy would it do that? You're asking for a raw memory address value.
- Syonyk 2y agoYou'll have to be a lot more specific than "ARM" - Most newer ARM systems are little endian in practical operation, and ARM has been "flexible endian" (you can switch between big and little endian - SCTLR has the relevant bits to control the accesses on most recent ARM ISAs) for some long while now.
- musicale 2y agoIIRC several currently used architectures (e.g. ARM, Power, z/Architecture, RISC-V) can all run in big-endian mode. And in the embedded space I think PowerPC and MIPS are still around.
- 2y ago
- commandlinefan 2y ago> things like fizzbuzz are still useful I think you're right here but, to play devil's advocate... isn't there some survivorship bias going on here? I assume you've never tested the negative hypothesis and gone ahead and hired somebody who couldn't program fizzbuzz to validate your assumption.
- Syonyk 2y agoYou're right. When interviewing for a team that writes mostly in C and assembly (assembly for various different ISAs), we're not going to hire someone who claims to know C and fumbles through some basic problems and can't reason about hardware in the slightest.
- alienthrowaway 2y ago> I assume you've never tested the negative hypothesis and gone ahead and hired somebody who couldn't program fizzbuzz to validate your assumption A former employer of mine inadvertently did! He wasn't asked to complete FizzBuzz, but I am confident he couldn't answer it as I worked on the same team as him. He was a very charismatic individual who always "needed help" from team mates on all tasks, no matter how small. He managed to collect a salary for 6 months. Some time after he was let go, the police called my employer enquiring after him, and we learned he was a conman with outstanding arrest warrants with no prior SWE experience at all. The name we all knew him by was just one of many aliases.