3 ms·

I think this is an 'okayish' position to take. There are some people who absolutely can't handle being wrong, and I've personally seen them wreck havoc when th

by Verdex 4y ago

I think this is an 'okayish' position to take. There are some people who absolutely can't handle being wrong, and I've personally seen them wreck havoc when they get out of their depth. However, there has to be a limit to the nature of the questions that are being asked. If I'm spending my free time to go check some place out because they're telling me that they might be willing to give me a job, then I'm going to be kind of put out when they start asking me questions about what the 50th letter is in shakespeare's macbeth. The questions have to be somewhat on point. This isn't a medieval system of patronage where I have to be subject to every whim of my patron. We owe each other to not waste each other's time. And if they're going to 'break trump' then I don't see why I shouldn't as well. I can hear the objection though, 'oh primes are relevant to development.' But are they really? Maybe for advanced data structures like hashes, but what are you doing with a web framework that necessitates you write your own hash function? Besides, if you know about prime numbers, but not weak primes, strong primes, strong pseudo primes, safe primes, etc do you really know about primes and their CS applications? No, you just picked up some random trivia in high school and you're put out that everyone isn't as excited about it as you are.

checkmypythons 4y ago
I think you forget that even technical interviews are still aimed at examining soft skills. "What is the 50th letter in macbeth?" could easily be interpreted as "How would you go about finding the 50th letter in macbeth?" which is plenty relevant to basic scripting. "Do I have a source I can pull macbeth from?", "How does that source work?", "Can I query it for individual characters/words/chapters/etc.?" I think a fundamental problem a lot of people in the comments section are missing is that these interviews are designed to examine the approach to solving problems, not the actual answer to the problem. Sure, if you get a question about traversing a tree, they probably just want you to repeat some basic knowledge. Maybe something that will illustrate my point: If you happened to know the 50th letter of macbeth off the top of your head, it would defeat the purpose of the question. The point is to examine your problem solving process. If you were to just answer "r", then the interview would quickly pivot to: "Ok, what is the 307th?" or "Ok, what is the 50th letter of Othello?" The point is not to answer the question, so much as to establish the person's ability to answer questions. Any answer that was a straight up answer isn't useful in any way. There are all sorts of ways your example could be expanded into a useful examination of someone's programming abilities. If prompted, the interviewer might provide: "Let's say we have an api for querying the text of a given shakespeare work" "Could we expand that to other historical plays?" "What if we wanted a service to provide an arbitrary letter from an arbitrary play?" "What if we wanted to allow the user to specify between several options for the api we might use?" "How could we handle differing responses from different apis?" "Should we be counting punctuation or whitespace?" It isn't so much that a certain subject (historical plays) might be relevant to the job requirements, it's that these questions are more about examining problem solving approaches.
- jordanozang 4y ago
  Alternatively, this could be taken to fall into the bucket of brainteasers, where a good answer might be "e", since it's the most frequently occurring letter in the alphabet in english texts.

by Verdex 4y ago

checkmypythons 4y ago

I think you forget that even technical interviews are still aimed at examining soft skills. "What is the 50th letter in macbeth?" could easily be interpreted as "How would you go about finding the 50th letter in macbeth?" which is plenty relevant to basic scripting. "Do I have a source I can pull macbeth from?", "How does that source work?", "Can I query it for individual characters/words/chapters/etc.?" I think a fundamental problem a lot of people in the comments section are missing is that these interviews are designed to examine the approach to solving problems, not the actual answer to the problem. Sure, if you get a question about traversing a tree, they probably just want you to repeat some basic knowledge. Maybe something that will illustrate my point: If you happened to know the 50th letter of macbeth off the top of your head, it would defeat the purpose of the question. The point is to examine your problem solving process. If you were to just answer "r", then the interview would quickly pivot to: "Ok, what is the 307th?" or "Ok, what is the 50th letter of Othello?" The point is not to answer the question, so much as to establish the person's ability to answer questions. Any answer that was a straight up answer isn't useful in any way. There are all sorts of ways your example could be expanded into a useful examination of someone's programming abilities. If prompted, the interviewer might provide: "Let's say we have an api for querying the text of a given shakespeare work" "Could we expand that to other historical plays?" "What if we wanted a service to provide an arbitrary letter from an arbitrary play?" "What if we wanted to allow the user to specify between several options for the api we might use?" "How could we handle differing responses from different apis?" "Should we be counting punctuation or whitespace?" It isn't so much that a certain subject (historical plays) might be relevant to the job requirements, it's that these questions are more about examining problem solving approaches.

jordanozang 4y ago
Alternatively, this could be taken to fall into the bucket of brainteasers, where a good answer might be "e", since it's the most frequently occurring letter in the alphabet in english texts.