this post was submitted on 12 Feb 2024
755 points (97.5% liked)
linuxmemes
21613 readers
450 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
A lot of the time I find "spot the bug" questions to be more informative, especially for junior roles. We stopped asking fizz-buzz - just about everyone has heard of it by now and it's pretty easy to just rote learn a solution. Instead we give them the spec for fizz-buzz and a deliberately broken implementation and ask them to fix it. If they get flustered, just asking "what does this program output" usually give a pretty clear indication if they can reason about code in a systematic way.
That's fine if there are no weird pedantic ropes to fall over. I am not a compiler or linker, that's what I have compilers and linkers for. Same with an IDE. I don't know many details of the stdlib or other common libs, because why should I waste space in my brain for stuff code completion can show me...
The kind of bugs I'm talking about are things like "the logical flow of the code is broken because the order of the if/else if/else branches is wrong", "this program never finishes because you don't increment that counter" and "you specified print the numbers 1 to 100, but that counter starts at 0".
I'm testing your ability to think logically, not your knowledge of stdlib trivia
No, that approach is completely fine even if pedantic because you get the candidate to reason about their choices and their approach which tells you so much more about them than rote memorization. Being pedantic is the whole point of it.
That's likely not what I mean by pedantic. If your code example has syntactic errors or calls functions with not enough or too many parameters and you expect them to notice, you want them to do, what a compiler does or to know technical documentation by heart. Which is completely academic and pointless.
Concentrating on "algorithmic" solution at hand is fine, though. Unless you again expect them to recognize stuff like "hey this is almost Dijkstra's algorithm but wrong", because the interview should not be a university computer science test.