C950 Data Structures and Algorithms II, catalog number ICSC 3100, is the four-CU advanced algorithms course in the WGU School of Technology. It analyses and implements high-performance data structures including graphs, hashing, self-adjusting structures, set representations and dynamic programming. Four competency units is a heavy package by WGU standards, and it is heavy for a reason: this course asks you to write working code and to justify the design choices behind it, and the justification is usually where students lose time.
The code is necessary and the reasoning is what is scored
Students arrive expecting a programming course and find something closer to an engineering argument with code attached. Producing a working program is the entry requirement, not the achievement. The assessed skill is choosing a data structure and an algorithm deliberately, knowing what each choice costs in time and space, and being able to defend the choice against the alternatives you did not take.
That is why complexity analysis carries so much weight here. Saying that a hash table gives constant-time lookup on average is a start; explaining what happens as the load factor rises, what collision resolution strategy you chose and why, and what the worst case looks like, is the analysis. Students who can implement a structure but cannot describe its behaviour as the input grows are exactly the students this course is designed to develop, and the rubric aspects are usually written to detect the gap.
There is a practical dimension too. Four competency units usually indicates a course with a substantial build in it, and a build has a failure mode that reading does not: you can spend three days on a defect that teaches you nothing about the material being assessed. Version control from the first commit, small testable increments, and a working skeleton before any optimisation are not stylistic preferences here. They are what keeps an implementation course from consuming a term.
The structures named in the catalog scope for ICSC 3100 each carry their own reasoning. Graphs turn on representation, since adjacency lists and matrices trade memory against lookup speed, and traversal choice determines what you can compute. Self-adjusting structures reorganise themselves in response to access patterns, so their value is amortised rather than per operation. Dynamic programming is a way of avoiding recomputation, and the intellectual work is identifying overlapping subproblems and the optimal substructure that makes the technique valid at all.
Turning the scored aspects into a work plan
WGU keeps scoring detail inside your Course of Study rather than in the public catalog, so open it before you write any code. School of Technology courses may be measured by a submitted performance assessment, by a proctored objective assessment, or by both, and a course with an implementation component usually has deliverables beyond the program itself.
Every scored aspect is judged independently against a three-point scale, and a score of 2 in each aspect passes the task. Nothing averages, which in a programming course has a specific consequence: a program that runs correctly can still return because the written justification for a data structure choice was one sentence long. Treat the documentation as scored work, because it is.
The word budget, worked. Suppose eight scored aspects, several of them written rather than code, and directions asking for about 2,400 words of accompanying documentation. Reserve 180 for an overview and 150 for a close, leaving 2,070 across eight aspects, roughly 260 words each. Then rebalance: the complexity analysis and the data structure justification deserve 400 each, taken from the descriptive sections that merely explain what the program does. Reviewers can read what it does; what they cannot see is why you built it that way.
Write the justification while you are choosing, not afterwards. Retrospective reasoning tends to describe what you built rather than the alternatives you weighed, and the comparison is what the aspect is asking for.
A structure that fits an algorithms deliverable
Task directions govern where they set out a required format. Where they leave room, this arrangement puts the reasoning where a reviewer looks for it.
| Section | What belongs in it | How it gets scored |
|---|---|---|
| Problem and constraints | What the program must do, with input sizes and any time or space limits | Frames every later justification; unstated constraints make choices unjustifiable |
| Structure selection | The data structure chosen, with at least one alternative considered and rejected for a stated reason | Scored directly and thinly answered in most drafts |
| Algorithm selection | The approach chosen and why it suits the problem shape | Scored for reasoning about the problem rather than for naming a technique |
| Complexity analysis | Time and space behaviour, best, average and worst case, with the reasoning shown | The highest-value written section in the whole deliverable |
| Implementation | Code that runs, is readable, and is commented where the reasoning is not obvious | Scored for correctness and for whether it matches the design described |
| Verification | Test cases including edge cases, with results | Scored where testing is named; a program with no evidence of testing looks untested |
| Scalability discussion | What happens as input grows, and where the design would break | Scored for engineering judgement rather than optimism |
Comment the reasoning rather than the syntax. A comment explaining that a particular structure was chosen because lookups dominate the workload is worth twenty comments restating what a line of code already says plainly.
Evidence craft in a computing deliverable
Evidence in this course is the analysis and the test results, and both fail in recognisable ways.
- Derive complexity rather than quoting it. Showing how the operation count grows with input size is the analysis; naming a bound from memory is recall.
- State assumptions about the input. Average-case claims for hashing depend on distribution assumptions and those should be visible.
- Test edge cases and show them: empty input, a single element, duplicates, and the largest size you were asked to handle.
- Report actual behaviour where you measure it, and be honest when measured timing disagrees with the theoretical expectation, which it often does at small sizes.
- Cite any external source, algorithm reference or library you relied on, and never present borrowed code as your own. Academic integrity rules apply to code exactly as they do to prose.
- Keep documentation in your own words; WGU runs submissions through a similarity check and standard algorithm descriptions are heavily reproduced.
The strongest deliverables name the condition under which the design would be wrong. Saying that the chosen structure suits a read-heavy workload and would be a poor choice if insertions dominated shows that the decision was a decision, which is exactly what a justification aspect is testing.
What separates Competent from a return
Work is recorded as Competent or Not Competent, with no letter grades and no ordinary grade point average. Because aspects are scored independently, a working program can still return, and usually does so for the written analysis rather than for the code.
- Every scored aspect has its own labelled section using the rubric's own wording.
- Every structure and algorithm choice names a rejected alternative and the reason.
- Every complexity claim is derived rather than asserted.
- Every edge case is tested and the results are shown.
- Every piece of borrowed code or logic is attributed.
- The code that ships matches the design the documentation describes.
Performance assessment work can be revised and resubmitted with no grade penalty, so a return is a documentation task more often than a rebuild. The cost is calendar, and terms run six months at a flat rate, so a four-CU course that stalls in revision is the most expensive stall available on a technology plan.
Our boundary on this course is plain. We explain algorithms, review your design reasoning, help you structure the analysis and check your complexity arguments. Where a proctored objective assessment applies it remains yours to sit, we prepare you for it, and we never ask for portal credentials.
Six mistakes students make in C950
- Treating the program as the deliverable. Written justification and analysis are scored aspects, and they are where returns cluster.
- Quoting complexity instead of deriving it. A bound with no reasoning behind it cannot be awarded.
- Choosing a structure by familiarity. The rubric wants a decision with alternatives weighed against the workload, not a default.
- Testing only the happy path. Empty input, single elements and duplicates are where implementations actually break.
- Writing documentation last. Retrospective reasoning describes what exists rather than what was chosen and why.
- Leaving borrowed logic unattributed. Integrity rules apply to code, and unattributed algorithms are a serious problem rather than a technicality.
How support works on this course
Send your Course of Study for C950 with the rubric and task directions. What comes back is a design review that tests whether your structure and algorithm choices are defensible for the workload described, complexity analysis written as derivation rather than assertion, a test plan covering the edge cases reviewers look for, and an aspect-mapped documentation structure that puts words where the scoring is.
Four competency units is a real block of a term. Getting the reasoning right before the implementation is finished is what keeps this course from consuming the two courses behind it.
Questions students ask about C950
Is C950 the same course as ICSC 3100?
What does C950 cover beyond the first algorithms course?
Can you write my program for me?
Program runs, documentation coming back?
Send your Course of Study and rubric. You get a design review, derived complexity analysis, an edge-case test plan, and an aspect-mapped documentation structure.
Where C950 sits in WGU's programs
The July 2026 catalog places this code in 3 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.