Is the following repository pattern properly applied? Is this repository code written according to best practices? The Last Section I included it in the repository as well.

class HR_Repository&lt;T&gt; : IRepository&lt;T&gt; where T : class
{
    private readonly  LoginDataContext dataContext;
    public HR_Repository(LoginDataContext dataContext)
    {
    this.dataContext = dataContext;
    }


    public void Commit()
    {
        dataContext.SubmitChanges();
    }

    public IList&lt;T&gt; FindAll()
    {
        var table = this.LookupTableFor(typeof(T));
        return table.Cast&lt;T&gt;().ToList();
    }

    public IQueryable&lt;T&gt; Find()
    {
        var table = this.LookupTableFor(typeof(T));
        return table.Cast&lt;T&gt;();
    }

    public void Add(T item)
    {
        var table = this.LookupTableFor(typeof(T));
        table.InsertOnSubmit(item);
    }   

    public void Delete(T item)
    {
        var table = this.LookupTableFor(typeof(T));
        table.DeleteOnSubmit(item);
    }

    private ITable LookupTableFor(Type entityType)
    {
        return dataContext.GetTable(entityType);
    }
}


public static class UserQueries
{
    public static Employee ByUserName(this IQueryable&lt;Employee&gt; employees, string username)
    {
        return employees.Where(u =&gt; u.User_Name == username).FirstOrDefault();
    }
}
I don't like the underscore in the class name, HR_Repository. It's a generic name for a generic class, which is good, but seeing that it implements IRepository&lt;T&gt; I would expect something like this:
public class EmployeeRepository : IRepository&lt;Employee&gt;

I like that you're initializing your private readonly LoginDataContext in the constructor, from a constructor argument.
private readonly  LoginDataContext dataContext;
public HR_Repository(LoginDataContext dataContext)
{
    this.dataContext = dataContext;
}

I like it because this implementation of IRepository&lt;T&gt; has a dependency on the LoginDataContext - by passing it into the constructor, you're doing constructor injection and that's awesome. Ideally the dependency would be an abstraction (abstract class or interface), which makes it easier to inject as a mock or fake implementation when you're writing unit tests. Even if you never write these tests, the fact that your code would be testable is a very good thing.
I don't like that your static helper provides extension methods to IQueryable&lt;Employee&gt;, it's not clear how/where this code is being used, the benefits aren't immediately apparent.

As for the pattern itself, it looks like a hybrid Unit-of-Work / Repository implementation, because of the Commit method. But your implementation exposes ITable and IQueryable, which leaks out the ORM into the calling code.
If you consider the client as, say, a controller class (assuming MVC), the controller would have a dependency on the unit-of-work, which has a dependency on the data context and lets you work with one or more repositories, which all share the data context of the unit-of-work:

(I skipped UML classes, hope this doesn't look too weird)


Disclaimer
I'm biased. I'm not a fan of unit-of-work/repository pattern, at least not with Entity Framework. I think Entity Framework's DbContext is a unit-of-work, and the IDbSet&lt;TEntity&gt; properties it exposes are repositories - I think wrapping this in another level of abstraction has very little benefits and adds a considerable amount of complexity to the code.
Instead, I simply wrap DbContext with an interface:
public interface IUnitOfWork
{
    void SaveChanges();
    IDbSet&lt;TEntity&gt; Set&lt;TEntity&gt;();
}

public class MyContext : DbContext, IUnitOfWork
{
    IDbSet&lt;MyEntity&gt; MyEntities { get; set; }
    // ...
}

Then I usually have a &quot;service&quot; class that takes an IUnitOfWork dependency; I write closely related queries inside that class, but the &quot;service&quot; only returns materialized results, it doesn't expose IQueryable&lt;T&gt;, even less so ITable. A controller will take a factory that can instantiate such a &quot;service&quot;, wrapping its instance in a using block to ensure proper disposal.