When people first sit down to build a job board, they almost always start with the same mental model: "I need a User and a Job. The user posts the job, and another user applies for it." It seems intuitive. It's clean. It's also exactly how you end up with a database schema that breaks the moment a real client asks for a basic feature.

Here is why that's wrong. Imagine you've built your board and "TechCorp" signs up. They have one account, and they post ten jobs. Everything is great. Then, TechCorp grows. Now they have three different recruiters—Sarah, Mike, and Jen—who all need to manage those jobs, respond to applicants, and edit descriptions. If your Job simply belongs_to :user, you're stuck. You either have to share a single password among three people (a security nightmare) or you have to manually duplicate every job post for every recruiter. It's a mess.

Stop treating the Poster as the Company

To fix this, we have to decouple the Identity (the person logging in) from the Entity (the organization paying for the listing). In a professional Ruby on Rails application, I wouldn't associate a job with a user; I'd associate it with a Company.

By introducing a Company model, you create a pivot point. Now, a Company has many Users (the recruiters) and many Jobs. Your schema should look more like this:

# The Company is the "owner" of the listing
class Company < ApplicationRecord
  has_many :users
  has_many :jobs
end

# The User is just the person with the login credentials
class User < ApplicationRecord
  belongs_to :company, optional: true # Optional because candidates aren't in companies
  has_many :job_applications
end

# The Job belongs to the organization, not the individual
class Job < ApplicationRecord
  belongs_to :company
  has_many :job_applications
end

I've found that this approach saves me countless hours of refactoring. It allows you to handle "Company Profiles" (logos, website URLs, descriptions) separately from the user's personal email and password. If Sarah leaves TechCorp, you just delete her User record, and the Jobs remain safely attached to the Company.

Shifting from "Applying" to "Application Tracking"

Another spot where learners often trip up is the application process. They try to put a user_id directly on the Job model to track who applied. But a job isn't "owned" by the candidate; it's a relationship between a candidate and a posting.

You need a join model—a JobApplication. This is where the real business logic lives. It's not just a link; it's where you store the candidate's cover letter, the date they applied, and most importantly, the status of the application (e.g., "pending", "interviewing", "rejected").

class JobApplication < ApplicationRecord
  belongs_to :user # The Candidate
  belongs_to :job
  
  validates :user_id, uniqueness: { scope: :job_id, message: "You have already applied for this position" }
end

Note that validation above. It's a small detail, but it prevents the "double-click" bug where a candidate accidentally applies to the same role five times in three seconds. I've seen it happen in production more times than I care to admit.

When you build the controller for this, keep your concerns separate. Your JobsController should handle searching and viewing, while a dedicated ApplicationsController should handle the act of applying. Don't try to cram the "Apply" logic into the JobsController#update action. It'll make your code rigid and difficult to test.

📋 Practical Task

Build the Company-Recruiter Authorization Logic

Now that we've decoupled the User from the Company, you need to ensure that recruiters can only edit jobs belonging to their own organization. If Sarah from TechCorp tries to edit a job posted by MegaCorp, your app should stop her.

Your Task:

• Create a JobApplication model with associations to User and Job.
• In the JobsController, implement a before_action called ensure_company_member.
• This method should check if the current User's company_id matches the company_id of the Job being edited.
• If they don't match, redirect the user to the root path with an alert saying "You are not authorized to manage this listing."