How does real-world coding differ from school coding?
I think the biggest difference is: In school you get straightforward, well-defined problems. In the real world, you get messy problems with lots of special cases and exceptions.
For example, I recently had to work on a program where the warehouse people would scan items in the warehouse while taking inventory, and then we'd match this against what the system thought should be in the warehouse to give a discrepancy report. In a school problem, I'm sure you would scan some sort of stock number and that would be the end of it. But in real life, we have four different types of identifying number that we had to scan. Then we had to figure out which of the four types it was by studying the format. Like, one type of ID number always ends with a hyphen, 3 digits, another hyphen, and 3 more digits. Another type of ID has no hyphens and always includes at least one alpha character. A third type is all digits. Etc. Oh, except for the first type, when the number is too long to fit on the label they leave out the second hyphen. Etc. So as we scanned each item, we had to count the number of hyphens, see if it included any digits, etc. to try to guess which type of ID it was.
In another problem I worked on recently, we had a transaction type code that identified whether a transaction was a basic sale record, a discount of some kind, or various other special cases. Straightforward enough, you might see that in a school problem. Except one of the codes had two completely different meanings, and the only way to tell which it was was to look at its position on the sales receipt and see if it was listed before or after delivery charges.
I assume that school problems tend to be neat because the point is to make sure that the student understands how to use a SQL JOIN or a Java ArrayList or whatever, and not to slog through a long list of confusing requirements that the teacher would have to make up just to make the problem difficult. That's fine. But in real life, problems aren't invented to test your knowledge of a language feature but to meet some business requirement. And in real life, those requirements often include having to deal with inconsistent inputs coming from many sources, coping with bad design decisions made by somebody who quit five years ago, etc.
What you need to know to get a job
In real life, knowing how to solve real-life programming problems doesn't necessarily help you get a job. What helps you get a job, especially that first job, is being able to say that you know X and Y and Z. Like if you're looking for a Java programming job, you want to be able to say that you know servlets and Swing and Struts and Hibernate and as many such frameworks and tools as you can. Play with them enough that if you are quizzed on them you can give coherent answers. Read "Design Patterns" and make sure you thoroughly understand at least several of the patterns described. Questions about this book came up a lot the last time I was going on interviews. Know the difference between "waterfall development", "agile development", and "test-driven development". Basically, look at want ads and see what they say they want you to know, and pick at least a few of those things and learn enough about them that you can check those boxes.
This may or may not help when you're actually on the job. But you have to get the job first.
