How to Write an SOQ for an Information Technology Specialist Position

Most California Information Technology Specialist I job postings require a Statement of Qualifications (SOQ) — a supplemental document you submit with your application. It is not the same as the statewide ITS I examination on CalCareers: that exam is a Training and Experience (T&E) evaluation you take to establish eligibility for the classification. The SOQ is vacancy-specific; departments use it to assess fit and writing ability, and it may be scored like a written interview against the job’s desirable qualifications.

ITS I responses are often reviewed with a technical lens — hiring panels convened by the department often include subject matter experts who can judge whether your examples are specific and credible.

Under CalHR’s consolidated IT series, work is organized into six official domains (the position’s duty statement shows which domains apply to that job):

• Business Technology Management — IT governance, service management, partnership with programs, alignment to mission
• Client Services — end-user support, service delivery, training, customer-facing technical work
• Information Security Engineering — security architecture, incidents, access controls, risk and compliance
• Information Technology Project Management — planning, scheduling, budgeting, delivery methods (e.g., Agile, waterfall)
• Software Engineering — application development, programming, design, testing, deployment
• System Engineering — infrastructure, integration, platforms, and operations (including areas like networks, storage, and databases in practice)

The department designates which domain(s) apply to the vacancy on the duty statement — candidates tailor the SOQ to that posting and its desirable qualifications, not to a generic “track” you choose on your own.

ITS I SOQ prompts are written per vacancy and are often tool- or program-specific. You may see several questions covering technical depth, a flagship project, and communication or collaboration — always answer exactly what that posting asks.

There is no single statewide SOQ format for ITS I. Each posting sets limits in Special Requirements. Patterns you will often see:

• 12-point font (Arial, Helvetica, or similar)
• Page limit — frequently one to three pages for the entire SOQ; two pages is common, but some ads allow only one
• Single-spacing and one-inch margins — when the posting specifies them
• Numbered answers in the same order as the questions
• Your name and sometimes the title Statement of Qualifications on each page — if instructed

Always re-read the Special Requirements section of the CalCareers posting. Some departments require you to restate each question before answering; others forbid pasting from outside documents.

Within whatever page limit the posting allows, depth beats padding — a thin overview scores lower than the same length packed with specific tools, scope, and outcomes.

Technical alignment: Your strongest evidence should match the domains and desirable qualifications in the duty statement and the SOQ questions. Structure your answer as a narrative of relevant projects and skills (e.g., by project, skill area, or time). Include:

• Technologies, languages, frameworks, and tools you've used (be specific: "Python 3, Flask, PostgreSQL" not "programming and databases")
• Scale and complexity: team size, data volume, number of users, budget size, project duration
• The business or mission impact: what the system enabled, what problem it solved, what efficiency it created

A strong Software Engineering example might read: "Over seven years, I've designed and maintained web applications using Python, Django, and React serving 50,000+ users. At [Employer], I led a four-person team that rebuilt a legacy reporting system — migrating from a custom PHP codebase to a modern REST API, reducing report generation time from 45 minutes to under 90 seconds..."

Project-style questions: Use the STAR method:

1. Situation — project context, scope, technical environment
2. Task — your specific responsibility
3. Action — the technical approach, decisions made, tools used; be specific and detailed
4. Result — measurable outcome (performance gain, cost reduction, user adoption rate, on-time delivery)

Stakeholder or communication questions: Describe a specific situation where you translated technical concepts for a non-technical audience. Focus on your approach — how you simplified the information, what format you used (demo, diagram, written summary), and what happened next. Many ITS I hiring teams value bridging technical and business perspectives, but answer the prompt’s exact ask first.

Misaligning with the posting — leading with skills or buzzwords the duty statement doesn’t emphasize, or overstating depth in an area where you have little real project history. When reviewers have technical backgrounds, thin or generic coverage is easy to spot.

Listing tools without context — "I have experience with Python, Java, SQL, AWS, Docker, Kubernetes..." reads as a keyword list, not a demonstration of expertise. Every tool you name should appear in a project context with a measurable outcome.

Writing a resume instead of answering the prompts — the SOQ is not a chronological job history. Lead with capabilities and evidence tied to each question, not titles and dates.

Skipping the result — technical descriptions without outcomes (e.g., describing a system you built without saying what it achieved) score lower than descriptions tied to measurable impact.

Using "we" throughout — raters are scoring your individual contribution. Say "I developed," "I configured," "I led" — not "our team built."

Vague project scope — "I worked on a large-scale database project" tells the evaluator nothing. "I redesigned the indexing structure of a 2TB PostgreSQL database serving 400 concurrent users, reducing average query latency from 800ms to 120ms" is scoreable.

Exceeding the page limit — automatic disqualification at many agencies.