Question: I am looking for best practices that big organizations follow for code check-in and validations. 

Currently we follow these steps,
- Developer writes code
- Developer do some initial tests
- Code is awaiting validation now
- Technical lead reviews the code (possible bugs, see if coding convention is followed etc)
- Once approved by technical lead, the code goes in QA state
- Once QA approves the code is checked in into the trunk.

We are now moving to a new project and I was looking for some best practices that would ease the process. We have custom made software that maintains the code status.

Thanks,
Ali

Answer: 
It seems like bad practice to me that there are no check-ins until the code is production ready. I would have a production branch and only cut over to it when the code has gone through all of those steps. my version of your process would be something like this:

* Developer writes code, checks it in.
* Does initial testing, checks in fixes
* Code gets reviewed, suggested changes (if any) are checked in.
* Reviewed by QA, any changes/fixes here are checked in.
* Code is cut over to the main branch, ready to go run free in the wild.

In your example, it sounds like a check in would only be made once every few days, where checking in is something you should be doing multiple times a day.
The code should always be in source control. The new code can be committed to a branch, reviews, changes, improvements are done there.

QA can be build from the branch.

AFter final approval, merge to trunk.