Java Web Development – When Are Scripts Inside HTML Not Considered Bad Practice

Many people won't like this idea, but I am advocating this wherever I can: regardless of the programming language and environment, if they don't have any experience and if there are maintenance tasks which come up from real world bug reports of customers of yours, try to make sure they get assigned to that kind of task at least for 30-40% (+) of their time. "Here's the bug report, have a look at it, solve it. If you don't know what it's all about, communicate with experienced colleagues, google it, whatever". Real work on real problems, no toys, at least: not only toys. Make sure, too, that someone with lots of experience has a look at what they were doing before it gets released and shipped to the customer, of course. Make sure the new colleague gets honest feedback on what he did from colleagues and customers. Choose these tasks carefully in order to not overburden them, but keep in mind that some day you want them to do their work independently.

Doing bug fixing is learning on the job which lets them work on code which get's actually executed and has some relevance (otherwise there would be no bug reports) and will show them in many examples how to not do it.

The focus is automatically put on pain points. They'll start learning those details which are actually causing trouble. It also puts real responsibility onto their shoulders right from the beginning, which (while maintenance as such is not really attractive) can be rather motivating if they get it done to the satisfaction of the customer/end user. Going through what they did will be taken more seriously by your seniors cause they know the impact if things go wrong, and that way it will also simplify integration into the team, cause it will make them talk to each other automatically, as well.

The point is not to set them productive from the first moment (as it might look like). The point is to make sure that they know they are supposed to do something valuable right from the first moment, and to put a focus on what matters most without the need to actually create a list.

I do have some years of experience working every now and then with people coming directly from college into their new developer job, and the worst results I got to see was usually when someone without at least some experience in maintenance was asked to do new application development. Just make sure they always have someone they can ask for support if they feel lost.

Nested loops are fine as long as they describe the correct algorithm.

Nested loops have performance considerations (see @Travis-Pesetto's answer), but sometimes it's exactly the correct algorithm, e.g. when you need to access every value in a matrix.

Labeling loops in Java allows to prematurely break out of several nested loops when other ways to do this would be cumbersome. E.g. some game might have a piece of code like this:

Player chosen_one = null;
...
outer: // this is a label
for (Player player : party.getPlayers()) {
  for (Cell cell : player.getVisibleMapCells()) {
    for (Item artefact : cell.getItemsOnTheFloor())
      if (artefact == HOLY_GRAIL) {
        chosen_one = player;
        break outer; // everyone stop looking, we found it
      }
  }
}

While code like the example above may sometimes be the optimal way to express a certain algorithm, it is usually better to break this code into smaller functions, and probably use return instead of break. So a break with a label is a faint code smell; pay extra attention when you see it.