What was the goal of the question? Why did you want the person to implement a contains method? Did you really want to verify they understood String implementation in Java?
And if the candidate was able to do this in 6 minutes, what would you have thought? "Great, let's hire"?
In my humble opinion, the question is a waste of time either way. You'll get much further trying to probe what the candidate does know rather than randomly creating an exercise that you think they "should be able to do if woken up in the middle of the night". People forget how stressful interviews are and how easy it is to assume shared context.
The fact that your employee was able to do the test might be indicative of the fact that you share context with the employee that you did not share with the candidate, thus confirming your bias.
Multi-lingual support seems reallyreally hard, especially in six minutes. I would think most people would need to look at technical (i.e., unicode) and linguistic references to get it right.
Should does the ligature f l match itself, or the ASCII constituents 'f' and 'l'? How about combining vs. pre-composed characters? Some Chinese characters show up in other languages (Japanese, Korean) and are sometimes split between Hong Kong/Taiwan/Mainland language tags too. In fact, there's a mess of work devoted to this ("Unihan" https://www.unicode.org/versions/Unicode13.0.0/ch18.pdf). Having figured out what you can do, you then need to decide what you ought to do. Not being a Chinese-speaker, I have no idea which options would seem natural....
In fact, having written this all out, there's no way someone "solved" it from scratch in six minutes. It would be a great discussion question though....
for (int i = 0 to text.length() - substring.length()) {
boolean found = true;
for (int j = 0 to substring.length()) {
if (text.charAt(i) != substring.charAt(j)) {
found = false; break;
}
if (found) return true;
}
We’re not taking rocket science here. This code already properly handles surrogates and Chinese characters. The question about characters that can be written in two different ways should only be raised as a second level, once the first implementation is done.
This is the introductory question before solving concurrency problems, because it’s much easier to understand what a thread does when you’ve coded the body yourself.
> Why did you want the person to implement a contains method?
The job is CRUD + integrating with Confluence + parsing search queries from the user, so finding “<XML” in a page and answering “Yes! This is totally xml, I’m positive!” is a gross simplification of realistic tasks in the real job (and in fact in most webapps), with characters instead of XML or JSON.
I have the feeling that you think this question is entirely abstract, but I both tailored the exercise because he touted being good at improving app performance on his resume (including using JProfiler) and I took care of using a realistic on-the-job example.
> Did you really want to verify they understood String implementation in Java?
Well, what consumer product can you work on if you trip into all UTF-8 traps? Telling customers “Just write English because we can’t be bothered to learn the easy thing in Java that handles UTF-8 properly” is… is acceptable unless he also fails the fuzzbizz test. And once UTF8 is mastered, it’s good for life! I wouldn’t mind teaching him if he didn’t fail the rest, but as a senior you should really know the difference between .getBytes() and .codePointAt(i).
> If the candidate was able to do it in 6 minutes, what would you have thought? “Great, let’s hire”?
The 4 other questions were classic gross concurrency errors, tailored because he touted it in his resume and I wanted him to shine. A senior should be able to guess them blindfolded as soon as I tell them “There are concurrency problems”, without even looking at the code ;) Volatile, atomic, ArrayList non-synchronized, 200 threads for a connection pool of 10, a DB accepting 7 cnx (note the prime numbers make it easy to spot which multiple is causing the issue), and strings of 10MB each with Xmx=100m, if he finds any 3 of the 12 problems, and 2 more with help, I’d hire him. If he ditched the code and postes tasks into an ExecutorService (as they teach in the Java certification level 1), I’d hire immediately.
1) We want to test concurrency but start with implementing String#contains.
2) You have to know how to implement String#contains because you might use contains in our environment (not really, but theoretically, so you better know how to implement it).
3) You must absolutely avoid basic UTF-8 traps because users use UTF-8.
Neither of the above tells me what would you gain if the candidate nailed the question. It just tells me that:
- Your team might or might not use contains to verify something is XML (I truly hope not).
- Your team uses UTF-8 strings (which is one piece of the shared context that the candidate probably does not have).
- You tested candidate abilities of performing under pressure rather than testing their knowledge or skill.
- You are trying to hire the exactly same senior developer as if you promoted someone on your team with your codebase.
You come to the interview full with assumptions and biases about what a senior candidate absolutely must know instead of seeking what they bring to the table and why they call themselves senior. Let me tell you there are lvl 4 and 5 Java candidates that have never touched UTF-8.
Finally, and let me blow your mind here, there are senior developers that haven't really used String#contains in the last X years of their career either.
I don't know what was the quality of the candidate, but I feel, from my limited PoV and lacking all the info, that your interview process is deeply flawed.
Honest question: I'd really love to know what UTF-8 traps people fall into all the time when working on a consumer product with Java - especially given that Java basically stores all Strings in UTF-16 (well, starting with Java9+ there's some "optimizations" made, but still). I literally can count those issues on one hand in over a decade of working on such (multilingual) products.
I also completely fail to see what a CRUD app (i.e. java + db) + shooting REST requests to confluence has to do with your concurrency questions, as in interview != job fit, but that might have to do with some missing context.
> The fact that your employee was able to do the test might be indicative of the fact that you share context with the employee that you did not share with the candidate, thus confirming your bias.
This! When giving interviews last I really worried if the questions I asked where just indicative of my own Dunning-Kruger effect.
i.e. Do I only ask questions I already know the answer to and not questions I don't know the answer to?
If I do then am I just filtering for people with the same background and knowledge and missing out on people with other skills I don't know, because they're in my blind spot, I need yet?
> i.e. Do I only ask questions I already know the answer to and not questions I don't know the answer to?
I've been advocating for a "coding interview" where both the interviewer _and_ interviewee draw some random question from leetcode or other problem bank, and try to work at it together.
This would show collaboration skills, and you can tell pretty easily how helpful the candidate is with his/her contributions, and whether you find there is an impedance mismatch somewhere.
It probably also maps more closely to the kinds of interactions you'd have after the person's been hired.
I think it would also help calibrate: if you can't figure it out, is it fair to expect the candidate to figure it out? Maybe it's just a hard problem!
And if the candidate was able to do this in 6 minutes, what would you have thought? "Great, let's hire"?
In my humble opinion, the question is a waste of time either way. You'll get much further trying to probe what the candidate does know rather than randomly creating an exercise that you think they "should be able to do if woken up in the middle of the night". People forget how stressful interviews are and how easy it is to assume shared context.
The fact that your employee was able to do the test might be indicative of the fact that you share context with the employee that you did not share with the candidate, thus confirming your bias.