Helix Systems' headcount report groups senior leadership positions — anyone whose title carries a Manager or Director designation.
Write a query to return the ID and name of every employee whose title contains Manager or Director somewhere in the string, with capitalization respected.
Assumptions:
- The
employeestable has one row per employee with anid, aname, and atitle. - A qualifying employee has a
titlethat contains the exact-cased substringManageror the exact-cased substringDirectoranywhere in the string.
Output:
- One row per qualifying employee, with columns
idandname.
Schema · hr 4 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
id,
name
FROM
employees
WHERE
title SIMILAR TO '%(Manager|Director)%'The shape
SIMILAR TO is implicitly anchored at both ends, so the pattern has to describe the entire string. The two % wildcards around (Manager|Director) undo that anchoring at the head and tail, leaving the alternation to match the part of the title that has to be exact. The parentheses are what bind the | to the alternation, so %(Manager|Director)% reads as "anything, then either Manager or Director, then anything."
Clause by clause
SELECT id, namereturns the employee ID and name for the leadership headcount.FROM employeesreads the employee roster.WHERE title SIMILAR TO '%(Manager|Director)%'keeps rows whose title containsManagerorDirectorsomewhere. The leading%allows any prefix, the trailing%allows any suffix, and the parenthesized alternation in the middle is the load-bearing part of the pattern.
Why this and not LIKE '%Manager%' OR LIKE '%Director%'
The LIKE-with-OR spelling returns the same rows and is, on a two-element alternation, just as readable. SIMILAR TO exists for the case where you want one predicate carrying the alternation and the % wildcards together. The POSIX regex form title ~ 'Manager|Director' does the same job with a more familiar syntax and no anchoring quirks. SIMILAR TO sits in an awkward middle ground; this problem uses it to make its anchoring behavior visible.
The trap
SIMILAR TO 'Manager|Director' (no surrounding wildcards) returns zero rows for every realistic title in the table. The pattern is anchored end-to-end, so it matches only titles that are exactly the string Manager or exactly the string Director. A title like Marketing Manager does not match because it has extra characters before Manager that the implicit anchors do not allow. The % wildcards are what lift those anchors. This silent anchoring is what makes SIMILAR TO easy to misread, and it is why most analysts skip it for the POSIX regex operators, where the default is the unanchored behavior most filters want.
You practiced SIMILAR TO '%(a|b)%' — alternation inside a string-anchored pattern; surrounding % wildcards lift the implicit end-to-end anchoring SIMILAR TO would otherwise apply.
