Building query for search engine
There are some bugs related to parameter handling:


Splitting by ", ": In #build_where, you split the skill parameter by ", ".  However, you example has just "skills"=&gt;"3,8" — with no space after the comma.  Splitting will therefore fail.
SQL injection vulnerability: Parts of the value of the skills parameter end up in the SQL query's WHERE clause, but you never validated, escaped, or parameterized the query.  You use the city, state, and country parameters with similar carelessness, interpolating values directly into an ORDER BY clause.  If a user tries to specify St. John's as the city, the query will break due to the apostrophe being treated as a quotation mark.  A malicious user can exploit that to do nasty things to your database.






I also suspect that


Job.select(:id).joins(:skills)



is the wrong thing to do.  That produces an INNER JOIN.  Any job that has no special required skills will therefore not appear in the join result.  I'm guessing that a LEFT OUTER JOIN would be more appropriate.



As for the skills filter itself, the WHERE clause you want in SQL is

WHERE "skills"."id" IN (3, 8)


(Writing 'skills'.'id' results in much brokenness.  To quote identifiers in PostgreSQL, use double-quotes.  Single quotes are used to quote literal strings, not identifiers.)

I would therefore write it as

def restrict_skills(search_jobs, skills_filters)
  # Check for non-empty string consisting only of digits, commas, and spaces
  if skills_filters.match(/\A[0-9, ]+\Z/)
     search_jobs.where(%Q{"skills"."id" IN (#{skills_filters})})
  end
end


Usually, I recommend parameterizing queries.  Escaping is my second choice.  Validating is normally my third choice.  However, here I've used validation instead of parameterizing and escaping because validation is easy: just check that the skills parameter consists of just digits, commas, and spaces.  It also happens that the SQL IN clause expects comma-delimited integers here.

I've also changed the helper method to manipulate the query-building object rather than to return a fragment of SQL.