this post was submitted on 12 Feb 2024
753 points (97.4% liked)
linuxmemes
21291 readers
939 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
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 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I love when cheaters fail to prosper.
Back when I still used Reddit, so many posts were just CS students trying to get other Redditors to do their homework for them. I don't think I ever came across any technical interview cheaters, but I'm sure there were some.
I remember one interview I had with a candidate. It was for a database analyst position that required SQL.
The first round was typically a phone screen where I chat with the candidate, get to know them a bit.
Second round was code review. I asked them to do a SQL query that did x.
The queries were simple. The goal was to get the candidate to walk through the query.
I had one candid that, over screen share, wrote the query flawlessly. Then I asked them to explain what it was doing. The candidate froze.
I can get understand getting nervous so I moved onto an insert statement. I had them write one and then do another without using certain terms (often leading to a sub query).
Again, flawless. I asked what situations would you use one over the other.
Again, they froze. I started to get suspicious that they were cheating and had them, instead of typing the answer, say the answer. When they couldn't, I knew enough that it wasn't going to work.
I had an applicant very obviously read to me that Wikipedia article about Active Directory.
Knowing how to quickly look something up isn't a bad skill. The problem is when that's all they do
Sure, look up specific configuration points or architectures, but looking up AD is a bad sign.
Worse, it was just a generic question about exposure for a low-level position. I.E. Can you tell me what big thing this is used for?
It depends on the question being asked. However, good problem solving is critical and hard to find.
When in doubt I ask them what RAID 45 is.
Ooo and there's even a serious looking page "explaining" it as the first result when looking it up on Google
I'm definitely stealing this idea
Steal away. An old boss knew the person who maintains that page. If I remember correctly it's entire reason for being is for that one question.
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.
I wonder why people do this. You wouldn't apply to a welding job if you can't weld. Why so many people apply to programming positions if they can't actually code (or a database analyst position without knowing SQL)?
Some people seem to think you can just Google stuff or more recently use AI to do the coding, not knowing that being a dev is mostly about knowing what to search and that being a dev isn't just coding.
I mean, Google and AI can be really helpful, but you should be able to do stuff without it. Google won't help you if you have a problem with a customer/company specific problem that requires knowledge about the whole technical infrastructure.
If you are a junior sysadmin - sure as hell you can and you will. Not everything has good manpages. Not every configuration of something is trivial to imagine, and it is useful to see what somebody else did.
Money? Maybe the get the first pay until they get thrown out again.
My current job just hired someone as a senior Salesforce admin with a bunch of certs who in reality lacks any Salesforce skills at all. He's been here for 6 months now and is really just dead weight on the team, but the only reason he hasnt been let go yet is because middle managent above him has its own host of issues, and the only reason he's on thin ice is because of some of my team has been very loudly forwarding complaints against him up the chain and clearly communicating that he's not showing the competencies that are required for the role and that he claimed to have. I give it another 6-12 months before he either gets fired or bounces
That's where you refocus the conversation by saying "tell me what you do know"
I could freeze like that because of being only shy/nervous, just saying. Over things I knew.
Say, "what it does" may bear different weight when you are autistic. You try to grasp the thing from iron to logic to computers to B-trees to database itself etc.
To know that you only have to say a simple thing also requires experience which juniors may not have.