What are some common and useful fields for a users table in a database

I suggest that you use typical normalization standards. One user per row.

• User ID (incrementing bigint)
• User Common Name (to be displayed on the site)
• User Email Address
• Password Salt (Unique for every user, inserted when the account is created)
• Password (Hashed with the salt - MD5 or SHA1, your preference)
• Date Account Was Created

The rest is up to you given your business rules.

Your usernames are to be unique. Good, they should be. But now you seem to think that Username would make a good primary key. Not necessarily. One important characteristic of a PK is stability. Unless you wish to implement a "one you've chosen a username you're stuck with it forever" policy (and that is a decidedly user-unfriendly policy), someone may want to change their username. Doing so when that username is scattered all over the database is going to be difficult.

I am not a fan of design rules that demand a surrogate key for every table. But typically 50% or more of tables should have surrogate keys. This is one of them.

And I certainly hope that when you say the login table will contain the password, you do mean the hash of the password, don't you?

@ypercube speaks for all of us about the "for each question, there will be separate table" idea. Not good.

Now as for the user's code. For that you have choices. You don't mention the target DBMS (if you even have one at this point) but some handle text or clob fields better than others. The question of handling actual disk files is one you will have to research yourself. Will those files reside in a file server, within a version control system, just a dedicated folder on some disk somewhere? In any case, what are the OS-based and/or network access privileges that will be needed? You get the idea. There are a lot of questions unrelated to databases that must be answered.

Not to say that one is superior to the other, but unless you or someone on your team has done this before, you may want to start with storing the code in the database. That will probably get you started faster and you can move to system files (if you determine it to be the better option) more or less at your leisure.