(1) Could you be more specific about the distinct differences in your projects?
So the projects in no particular order that I had under my belt going into my last semester of University:
"Soft" Operating System (written in Java. It is a watered down OS. Implemented a crude compiler, 3 users, and memory, no disk, memory would be stored and written out to files.)
Network API for a class to use to implement Battleship as part of a project. (Written in Java. Send and receive string text basically. This was part of a Honors Project at my school.)
Worked on Statistical Research paper for a undergraduate conference, sadly no useful results fruited from this labor, but gave me a great time using R and Excel for analytical purposes.
Worked on a FAA report during my time at Garmin International that analyzed the flight path of plane flying a RF-leg. (Fixed radius path). More pure statistics on this one.
Data generation for statistically analyzing Flight guidance systems using C and R. (again at Garmin).
Jay Jacks Business Solution. (Java, and essentially a cash register system for certain parts that we would get the data from a oracle DB set up by our professor).
Tasker (Parallel Programming using Ada. Learned Ada one on one with a professor and ultimately did the producer consumer problem).
Shark (Java, Game that I helped create randomly generated names, text, and other on screen displays at a certain rate with all calculations being done so that the game had a 60% chance of you winning in the long run. I was thinking about creating a 'rubberband' feel to it, so if you were losing the game you would be more likely to get 'good' text and actions, but ran out of time at the hackathon with my team.)
(2) What kinds of things should I practice for whiteboard interviews? Should I just go through Cracking the Coding Interview book, or do you have any other recommendation?
I have never read Cracking the coding interview. I actually have never read any interview how to book. My first internship was doing visual basic on the back-end of spreadsheets at a Executive Development Firm. There they coach CTOs, CEOs, VPs, etc. how to be better people. So I had twice in my life been there as a guinea pig so that they can train the new PhD student that they hired on since my internship there. This has helped me tremendously on how I approach interviews. In my opinion and from my coaching, it is all within the micro things. Look sharp, have a million dollar smile (practice, sounds dorky, but seriously it helps), smell good, but not too good. Practice sitting up record yourself talking through a question. A great way to improve yourself is recording yourself. It feels, sorry to use the word again, dorky, but it is extremely good way to showing you truthfully what you have done. Even better if you have a friend/professor who wouldn't mind watching it once you feel you did it 100% correct to point out a obvious flaw to them but not obvious to you that is excellent. Furthermore, take all advice you like and sit on it, digest it, and then maybe use it. Like building software there is no magic bullet for interviewing. All companies are different. All recruiters with the same company are different. You may just get the turd end of the stick sometimes. That's okay. Don't Panic, No Stupid, and Keep Walking (my rules of life).
As for practice whiteboard interviewing. Find a whiteboard and just practice writing a solution on the board no talking. Once you feel your hand writing in clean enough and you figure out the feeling of doing a solution go back and now figure out how to talk through it. The hardest part is finding that balance between talking a solution and also writing the solution down. Do simple problems at first like: "Implement a function that takes in a Linked list and a node and add it to the end of a linked list." (Now this could actually be a trick question and where you can strut your stuff. In a case like this I always ask what type of linked list is it? Singlely Linked? Doubly, Circular, etc. Always make sure you know the whole problem before diving in, even if you have to say something like "Just wanting to make sure my solution is what you are looking for: I am assuming a, b, and c. Are those assumptions correct?)