4 ms·

Parent here. > What was the goal of the question? This is the introductory question before solving concurrency problems, because it’s much easier to understan

Parent here. > What was the goal of the question? 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.

BossingAround 5y ago
In essence, you write: 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.
marcobehler 5y ago
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.

BossingAround 5y ago

In essence, you write: 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.

marcobehler 5y ago

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.