You were interviewing senior engineers with Java experience and they couldn't come up with Assert.assertEquals("radar",StringUtils.reverse("radar"));
I suspect you were actually looking for the implementation of StringUtils.reverse() and if that's the case then you were focused on the wrong skills.
1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume)
I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume.
If you honestly think implementing a reverse string method is "too complicated"...
Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.
It's not that I think the question is too complicated, just not the best marker.
In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops.
This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.
I didn't ask them to implement dijkstra's algorithm, or even something as "hard" as breadth-first or depth-first search (which I feel any senior that deals with trees should be able to do).
It's a marker of this... Can the candidate solve a basic problem? Once they solve it, can they explain their solution? Do they understand the memory/time tradeoffs they chose? Do they know whether the code they wrote is thread-safe? If you don't feel a senior engineer should be able to answer those questions, to a very basic problem, how do you expect them to tackle something more complex?
As for the interview itself, well I've never needed to ask someone to reverse a string to determine if they're going to be of value with the criteria mentioned above.
But to be fair I've never worked on a project where implementing StringUtils.reverse() was required. If I were interviewing someone to work on Apache Commons or the JDK then I suppose that would be a relevant question.
What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview.
And when their resume looks good and claims they are an expert, and you call them in and talk to them and they say they are an expert, and you start by opening a warmup question on the most basic levels of their expertise and they totally flunk it on multiple levels - unable to even handle the situation with tact or diplomacy in any way, are you still going to trust what they say about the systems they've "deployed and supported"?
usize len = strlen(foo);
char* bar = malloc(len);
for (int i = 0; i < len; i++) {
bar[i] = foo[len - (i + 1)];
}
The only competent programmers I can think of that wouldn't be able to come up with that off the top off my head work in embedded or FPGAs where strings are rarely relevant.
And yet, despite how easy the question is people still fail it. It's frankly absurd to me that a senior software engineer can fail this question. It's practically a freebie slam dunk for anyone with basic competency. Briefly drop that you can use your language's core function or method to do it. Then declare a new array and iterate through the string backwards, appending each character to the new array. When you're done, collapse the array to a string.
In other words, it's testing if you can write a for loop. How many times in your job do you expect to implement a for loop? I use for loops quite often.
What about multi-byte characters?
If you were interviewing with me, I'd ask you to do the (usually expected) ASCII/array-of-graphemes version first. If you did that, you'd pass, and get a positive shout-out in the feedback session for asking about multibyte chars.
If you, after solving the array-based form, had some ideas or even working code for how to handle multibyte characters directly, without falling back to the standard library of $language's idea of "what is an iterable character-equivalent unit in a string", and demonstrated similar insight in your other interview problems, I'd give a positive shout-out with the addendum that we might be interviewing you for the wrong (too junior) position.
In my experience, most people don't ask about multibyte chars. That's fine, if they solve the problem. It's not a positive or negative. If an interviewer is building questions with hidden "must-ask" gotchas like that, I think they're doing themselves and their candidates a disservice.
Something interesting does happen occasionally when candidates do ask about byte-width (or equivalent less-common but still very important gotchas like pointer/word size, endianness, etc. in relevant problems): some people ask the question, solve the naïve form of the problem, and then offer some thoughts as to how they'd handle the broader multibyte case. But some other people act as if knowing that gotcha means they won't or shouldn't have to continue solving the problem. I've had candidates tell me that they "figured it out" and wanted to go on to the next challenge at that point, without writing a line of code. I've had candidates tell me flat out that writing non-Unicode aware string processing algorithms was unrealistic and a waste of time, and that they wanted a problem that was more real-world or suited to their level of skill. Those things will also get you a shout-out in the interview review session, but not the good kind.
a. You can't iterate a 'String' backwards. You need to know the length first. And that requires traversing the string forwards at least once.
b. Once you reach the end you are wasting the effort of revisiting the elements, since you visited them already once.
c. A better option is build a build a double linked list, as you are traversing the list forward.
d. Once you have the double linked list ready, you have pointers to both start and end, and you traverse the way you like.
e. An even better way would be to design a data structure that contains all this meta data at String creation itself.
Class CustomString {
char* headPointer;
char* tailPointer;
int length;
bool isPalindrome;
char* string;
/* Add your interview acrobatic things here */
}
Now even though the answer in your comment is correct, they could reject you for not coming up with the answers I gave from point a through e above.
Now imagine some one telling you that, on these grounds, you don't know a semicolon worth programming and are probably a liar.
I hope you understand what's going on here. Every body can be rejected if they don't cut through your cookie cutter.
That's not at all true in many languages. If a candidate asked "is this string's length known without an O(N) operation on the number of characters in it?" (or knew the answer for the default string constructs in the language they were using for the problem) I'd consider that a positive indicator. If they said what you just said, without consideration for the context, I'd consider that a negative.
This is not a case of someone expecting a given "cookie cutter" solution. Interviewers who do that are doing themselves and their candidates a disservice. This is a case where statements like "I know how strings work because I know how they work in $context" where $context is not what the interview expects you to work in will make a bad impression.
In an interview, there is an unspoken assumption that you won't be using third party libraries to implement algorithms, and certainly not a third party library that implements it in one function call. Using that as a red flag will yield a LOT of false positives.
Also, I have over 10 years experience in Java, have used Apache commons extensively, and had no idea that a string reversal method even existed. You can't use that knowledge to judge anything useful.
A fail is not a red flag. A senior candidate not asking clarifying questions does not disqualify them (what I would call a red flag) but it is brought up in the debrief as a potential gap. I don't expect them to state this could be implemented using a single call to Apache commons. I call those candidates out in the debrief as being aware of the library, as a bonus. But not saying it isn't a negative.