How to Write an SOQ for an Information Technology Specialist Position

A Statement of Qualifications (SOQ) is a scored written exam required by most California Information Technology Specialist I postings. Unlike entry-level administrative SOQs, the ITS I SOQ is technically evaluated — reviewers are subject matter experts who can assess the credibility and depth of your technical claims.

Most ITS I SOQs have a domain-selection structure. You'll typically be asked to describe your experience within one of six IT specialty tracks:

• Software Engineering — application development, programming languages, software design
• IT Project Management — project planning, scheduling, budget oversight, methodology (Agile, waterfall)
• Database Administration — database design, administration, performance tuning, SQL
• Network Engineering — LAN/WAN infrastructure, routing, switching, security architecture
• Systems Analysis — requirements gathering, business process analysis, system design and integration
• Data Management — data governance, data architecture, analytics, business intelligence

The posting will tell you which domains are relevant for the specific vacancy. Choose the domain that best matches both the role and your deepest experience — evaluators can tell when someone is writing outside their area of expertise.

Some postings have 2–3 prompts in addition to the domain prompt: typically a specific project example and a stakeholder communication question.

Most ITS I job postings specify:

• 12-point font (Arial or similar)
• Single-spaced within responses
• Maximum 3 pages (longer than most administrative SOQs — use the space)
• 1-inch margins on all sides
• Responses numbered to correspond to the prompt numbering in the posting
• Your name and position title in a header

Always re-read the "Special Requirements" section of the CalCareers posting. ITS I format requirements are set by individual departments and can vary — some allow only 2 pages, and some specify that you must restate each prompt before answering it.

Unlike entry-level SOQs, the ITS I allows 3 pages because the domain documentation genuinely requires space. Use it — a brief, surface-level domain overview will score lower than a thorough one with specific projects and metrics.

Domain prompt: This is your primary evidence of expertise. Structure it as a narrative of your most relevant projects and skills in the domain, organized logically (e.g., by project, by skill area, or chronologically). 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 did the system enable, what problem did it solve, what efficiency did it create

A strong domain overview for Software Engineering 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 example prompt: 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 communication prompt: Describe a specific situation where you translated technical concepts for a non-technical audience. Focus on your communication approach — how you simplified the information, what format you used (demo, diagram, written summary), and what the outcome was. Panels for ITS I positions value the ability to bridge technical and business teams.

Choosing the wrong domain — writing about a domain where your experience is shallow because it sounds more impressive. Evaluators are technical experts; they will probe your depth and find the gaps.

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 domain prompt is not asking for your employment history. It's asking you to demonstrate expertise. Lead with capabilities and evidence, not job 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 a measurable business 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.