It certainly depends on what you're trying to do. Any checklist you get here will be very general and may not address your specific concerns. That said, here's some general things I look for when reviewing jobs:
1) General organization of job. Is the job ugly? Are components randomly thrown around? The job will work no matter how it is placed on the canvas, but well organized jobs are easier to understand and maintain.
2) Contextualized variables. Are all database connections stored in the repository as context variables? Hard-coded connection variables are a maintenance nightmare. All machine-specific variables (external tools, files locations, etc...) should also be contextualized.
3)Comments, formatting and naming conventions in custom code. If there are no comments describing what is being done the job gets rejected. Code *might* be self-documenting to a good programmer, but for the sake of those that come after you take the extra time to make sure.
4) If this job is a part of a larger project, does it follow convention? To make your maintenance easier, similar jobs should do things in a similar way. Logging, external control structure and other "this goes in every job" stuff should be checked. If you've enforced a naming convention (you should!) the review is when you put the hammer down and make sure everything is right.