shoud we normalize user profile table with fields like interests,musics,videos,sports, etc? I've read in an article about social networking database schema and saw that they've used varchar for those columns that I mentioned in the question title. It's not normalized! Isn't it better to have a table for sports and then put the foreign keys in user's profile table? In this case we'll have much less redundancy? Please correct me if I'm wrong. Which approach is better have another tables for fav_sports,fav_videos,fav_music, etc or put them all in user's table?
The solution I would choose depends on a few things.  If the number of these columns is relatively low (and not subject of frequent changes) then I would go with the solution you suggested, ie. one table for each attribute and foreign keys on these.  This way you have to define a new table and add a column for every new attribute and modify your queries accordingly.

If this is not your case than EAV suggested by @Zachariha should be considered, but it's worth reading this answer before.  It is very easy to extend (just add a new row to a table) but can go very difficult to maintain - in my opinion mostly because it's hard to follow that who plays in which team.

The scenario you see in your current schema can be the result of either not normalizing data or denormalizing later in order to speed up queries.  Normally, I keep heavily denormalized tables separate from base tables to keep my data safe from violations of referential integrity.