If you've just failed ten interviewees in a row, then either your sourcing is broken, or you're doing interviews wrong. Might be both, can't be neither.
Granted, I don't think it's all that hard a problem, and while I'm not at keys to check I think off the top of my head it should be solvable for constant strings in linear time - not like you're asking for sequence alignment or anything like that.
But if it demonstrates something relevant to the role and ten in a row can't hack it, then your pipeline's not finding you good candidates and that needs to be fixed.
And if it's not relevant - which is highly plausible, as who ever needs to or even should reimplement heavily optimized standard library functions, especially for as hairy a type as strings - then why even ask it in the first place?
edit, at keys: Yeah, it's simple to do this in linear time with constant strings (ie no backtracking):
const cases = [
{
subject:
"now is the time for all good men to come to the aid of their country",
searchFor: "n to come t",
expect: true,
},
{
subject:
"now is the time for all good men to come to the aid of their country",
searchFor: "time flies",
expect: false,
},
{
subject: "short skirt",
searchFor: "looooooooong jacket",
expect: false,
},
{
subject: "symbolized as ∆v and pronounced delta-vee",
searchFor: "∆v",
expect: true,
},
];
// TODO cases covering match at start and end, etc
function contains(subject, searchFor) {
let searchIdx = 0;
for (let i = 0; i < subject.length; i++) {
if (subject[i] === searchFor[searchIdx]) {
searchIdx += 1;
if (searchIdx + 1 === searchFor.length) {
return true;
}
continue;
}
// We found a mismatch between subject and search
// strings. Return to the first char of the search string;
// we'll have to try to find a new match
searchIdx = 0;
}
return false;
}
function assertEqual(expected, actual) {
if (expected !== actual) {
throw new Error("Assertion failed");
}
}
cases.forEach((testCase, i) => {
const { subject, searchFor, expect } = testCase;
try {
assertEqual(contains(subject, searchFor), expect);
console.log(`PASS: case ${i + 1}`);
} catch (e) {
console.error(`FAIL: case ${i + 1}`);
}
});
It's trivial in quadratic time too, of course, although I would expect a candidate for a senior role to be able at least to find the linear solution, if not to start there outright.
In entire fairness, I have to admit that we do use problems of similar complexity (both cognitive and algorithmic) for our first tech session, which I frequently administer. In my experience, people tend to handle stuff like that pretty well, even with considerably less experience than it sounds like your candidates have. But - and I think this is crucial - none of those problems involves operating on strings.
As another commenter here suggested, you definitely need to express this in terms of Array<number> or some similar contrived type that's obviously not as complicated as strings, because anyone who's been around for a while will certainly have been burned often enough by string complexity that they're not likely to assume they can treat it purely as an array of bytes iso8859-1 style. I certainly wouldn't assume that!
To be clear, I would ask if I could safely assume that for the purposes of the problem, or more likely I would look at the tests around the problem and see if any of them included obviously non-Latin-1 chars and thus cue me that they need special handling. (If I can't see the tests while I'm writing the code that's supposed to pass them, you'd better believe I will ask about that!)
I wouldn't necessarily ding a candidate for not asking, though. For one thing, this is all pretty basic info, and would certainly be available in "real life" - so if it isn't available in the interview, then the interview isn't a sufficiently accurate representation to produce a clean signal.
For another, and for the same reason, the perceived power differential between panelist and candidate has to be taken into account. You're not going to get a clean signal if you bring your ego into the session, or otherwise give the candidate cause to feel more intimidation than the context naturally inspires.
Some folks are more confident than others, sure - but it's a technical interview, and confidence isn't really of interest beyond the baseline of not seeing a candidate dissolve into a puddle of flop sweat. (And, in any case, if that does happen then it's at least as much my fault as anyone's, because if I'm not able to help people be comfortable enough to even function on my team or in my engineering org, then I'm not doing my job right!)
So yeah, granted, I haven't interviewed with you and I don't know any details beyond what you've chosen to describe, so take this advice for whatever you find it to be worth. But, especially in a language like Java which I gather makes it more necessary to account for utf8 weirdness in strings than the languages I more commonly work with, I definitely think you'll see a significant improvement with just that one simple change of not using strings where you really don't need to in the first place. That might not be the only thing that needs attention - I suspect your pipeline may need some love, too - but I'm fairly confident it's an excellent place to start.
(For what it's worth, my experience with tech interviews extends well beyond the candidate's role; I've been participating in them as a panelist for a good few years now, and lately, by request, have been doubling up my sessions as mentoring/shadowing opportunities for other engineers and EMs who want to improve their own panelist skills. Granted, I've approached this discussion largely from the candidate's perspective - but then too, I'd argue very firmly that if you're not considering how your interviews might go from the candidate's perspective, then that's something you need to work on, too.)