Point of programming assignment is to see if you can actually write code. No one is waiting for perfect implementation, just working code that fills the spec, documentation, and tests.
Point of programming assignment is to see if you can actually write code. No one is waiting for perfect implementation, just working code that fills the spec, documentation, and tests.
10 years ago, nearly no candidate pulled a distributed queue solution in a design interview and now it is a standard answer in their pocket.
However, there's always room for the interviewer to muck things up.
For the anagram problem, there are a range of solutions, including elegant & inefficient, clever & efficient, and robust & efficient. Do you dock someone depending on which they reach for first?
There's limited time, and a candidate may assume you're mostly interested in "how they think" and thus focus on the algorithm alone. After the interview, do you run the candidate's solution against test cases that you never mentioned, docking them for "missing" matters of casing or non-alphabetic characters? If the candidate themselves wrote unit tests, do you dock them for missing test cases you felt should have been included?
Do you dock them for not checking for invalid inputs, even though the candidate might normally work in a type checked variant of the language that wouldn't have permitted that anyway?
So many possible hidden assumptions. I know I've been rejected for similar unstated expectations in the past, and in retrospect, I know I've been guilty of doing the same to others.
This isn't a programming contest and your company isn't ACM
Just asking since it's a very easy task but I'd wanna doublecheck how to reverse a string in that language.