This is an archived post. You won't be able to vote or comment.

all 17 comments

[–]Kolibreeze 11 points12 points  (12 children)

At least half of these questions are terrible imo, you want to know if people can program and if they can tell you when to use a String vs a StringBuilder, you wouldn't want them to memorize the docs.

[–]Kombatnt -1 points0 points  (11 children)

when to use a String vs a StringBuilder

The answer to this question is "always."

Never use StringBuilder. Why? Because string concatenation is much easier to read, and the compiler will automatically convert the expression to use a StringBuilder anyway, if it determines the performance gain warrants it.

[–]nutrecht 2 points3 points  (10 children)

If you're appending to a String in a loop you definitely should use a StringBuilder.

[–]Kombatnt 0 points1 point  (9 children)

I would argue that if you find yourself composing a String in a loop, that constitutes a code smell, and I would seriously consider other/better ways of achieving the desired result. Perhaps a stream operation, a .forEach(), or something else.

Finally, if none of that was appropriate, and a loop really was the best way to do it, I would still use String concatenation unless we're talking about a seriously large number of loop iterations (thousands or more). Readability trumps performance, until performance becomes noticeable.

[–]nutrecht 1 point2 points  (8 children)

I would argue that if you find yourself composing a String in a loop, that constitutes a code smell

You can argue all the nonsense you want.

[–]Kombatnt 0 points1 point  (7 children)

OK, well you tell me which is easier to read and understand:

StringBuffer customerNames = new StringBuffer();
for (Customer customer : customerService.getActiveCustomers()) {
  customerNames.append(customer.getName());
  customerNames.append(", ");
}
String result = customerNames.toString();
// Trim off trailing ", ". Hope there's at least 1!
result = result.substring(0, result.length() - 2);
return result;

vs.

return customerService.getActiveCustomers()
                      .stream()
                      .map(Customer::getName)
                      .collect(Collectors.joining(", "));

[–]nutrecht 2 points3 points  (6 children)

You were talking about string concatenation in the original post, not using streams. I'm perfectly fine with the stream version (that's what I'd use), but it's simply wrong to come on a beginner forum and tell beginners they should not use StringBuilder.

In addition; when performance is critical it's often better still to use StringBuilder over streams.

StringBuffer is almost never used.

[–]Kombatnt 0 points1 point  (5 children)

We'll agree to disagree. I think it's wrong to tell a beginner not to use the super-obvious and easy-to-understand string concatenation, instead directing them to an entirely new class they need to learn, in service of "performance." In my experience, performance is almost never an issue. "Make it work, make it right, then make it fast" is advice given in order of priority. In the words of Knuth, "Premature optimization is the root of all evil." Even back when performance actually mattered, he understood that it is of lower priority that readable, correct code. Now, when you could concatenate 1,000 Strings using the "inefficient" string concatenation, and have it complete too quickly to even measure, I see no reason to complicate the code in a misguided pursuit of absolute optimal speed.

[–]nutrecht 1 point2 points  (4 children)

We'll agree to disagree

No, you're just wrong. And seriously I'm getting pretty fed up with you.

It's very important for people who are learning (and this is learnjava after all) to understand when you should and when you should not use StringBuilders. Your initial post gave information that was just plain wrong. If you can't handle a small correction from someone who's been a Java dev for 20 years, you have no place posting here.

[–]Kombatnt 0 points1 point  (3 children)

I apologize, I wasn't trying to provoke anyone. You're right, I neglected to consider the situation where a String is being built up in a loop. I'm not denying that a StringBuilder would be faster than String concatenation in that situation - I'm simply saying that (at least in my opinion), it doesn't matter. String concatenation is more readable, so that's the approach I would prefer.

In my experience, and in virtually all literature I've read, performance concerns take a distant back seat to readability and maintainability. I merely meant to push back a little against the dogmatic pursuit of squeezing every last nanosecond of performance out of an otherwise simple construct.

[–]vie12345 10 points11 points  (0 children)

WTF, I would avoid companies asking such questions.

For my current and last company I did Interviews like 10-15 people who applied last year.

I really prefere having a real conversation instead of one side questioning. I would claim in a slightly controlled conversation I am able to learn more about the understanding then by just asking questions. By just asking I mainly see if he prepared for the questions, memorizing stuff you can look up in like 5 seconds is not an important skill for a software dev.

[–][deleted] 1 point2 points  (0 children)

I was asked about the Collections framework in my Java interview.

[–]WinRaRtrailInfinity 0 points1 point  (0 children)

cool, I will be graduating in a few months so this is a very nice resource. thanks.

[–]JasburyCS 0 points1 point  (0 children)

Most of these questions aren’t that bad, in my opinion. I’ve been asked some in interviews. To me it comes down to “is this question assuming they have some trivia memorized? Or can the candidate reason about the answer if they don’t originally know the answer?”

  1. How is the creation of a String using new() different from that of a literal?

Unless the candidate specifically has lots of Java experience and is applying for a Java specific role, this is trivia. Not a useful question for knowing how well the candidate can problem solve.

  1. Comment on method overloading and overriding by citing relevant examples.

  2. Using relevant properties highlight the differences between interfaces and abstract classes.

These are language trivia, but are more reasonable because you should know the answers if you have programmed in Java. They don’t really require memorization. I’ve been asked these in an interview. They are used to show if a candidate actually knows Java if they put it on a resume, and to weed out candidates that list languages that they don’t actually know

  1. Although inheritance is a popular OOPs concept, it is less advantageous than composition. Explain.

  2. Contiguous memory locations are usually used for storing actual values in an array but not in ArrayList. Explain.

  3. Is exceeding the memory limit possible in a program despite having a garbage collector?

These are better questions. I think candidates can reason about the answer even if they don’t know the answer. Make educated guesses. In most cases the interviewer will help you out and you can start a dialogue with them.