WOH William Osei-Hwere Software engineering · Systems · Automation

Personal record 00 About William

Computer science student. Software developer.

I create.
I explore.
I improve.

I’m William Osei-Hwere, a Dakota State University student specializing in software engineering and cybersecurity. I build useful software, automate everyday work, and make complex systems easier to use.

JavaScript / Node.js / C++ / Python / SQL

Explore projects ↓Résumé ↗Get in touch ↗

DSU · Class of 2027 Recent IT intern at TRMF

01

Drag to meet both sides of me, or choose a view below.

Identity record / live cross-section Professional side
WORKING PROFILE 📍USA

Software developer · Systems thinker

I make complex tools easier to trust.

From internal tools to full-stack apps, I connect reliable systems with thoughtful interfaces.

SystemsM365 · Entra · Windows · IIS
SoftwareJavaScript · Node · C++ · SQL
FocusUsability · reliability · scale
Build the experienceUnderstand the machinery
Life outside the work Professional practice

Field records 01–03 Selected projects

Selected work.
Open for inspection.

Useful tools, from company operations to route-finding algorithms. Scan the essentials, then open a record to explore how it works.

CASE 01Company calendar and resource platform
Production internal platform

Production internal platform

Clearer bookings. Faster decisions.

I rebuilt the company calendar’s busiest views so employees could scan room bookings, vehicle availability, and events without losing details in crowded grids.

Built
Redesigned week views; new day and holiday views
Stack
JavaScript · Node.js · Exchange / Microsoft 365
Reach
Six calendar areas in an environment supporting 900+ users
Explore the redesignBefore / after · architecture · outcomes

Visual evidence

See what changed.

Choose an area and compare the original with the redesign. Names and emails are blurred.

AREA
VERSION
Original LSC weekly calendar view ORIGINAL / LSC WEEK
Original LSC week view

Events were positioned mainly by time. When many bookings overlapped, cards became narrow, titles were clipped, and employees could not quickly see the requester or enough booking context.

P / 01

Six calendars. One place to act.

Room, vehicle, and event calendars cover LSC, RRH, GES, Vehicles, Schafer, and Training & Development. Employees can switch between month, week, day, agenda, and holiday views.

Know what is bookedRooms and vehicles appear alongside their status and booking window.
Know what is happeningCompany events are grouped by place, date, and operational context.
Know where to actAvailable vehicles can open the booking form with the vehicle already selected.
E / 01

Familiar branding. More useful views.

Crowded time grids hid booking details. I redesigned each area’s week view, added a day view, and introduced company holidays through 2027. Existing month and agenda views remained available.

PreservedCompany branding · existing data · familiar navigation · six operational areasRebuiltWeek layouts for LSC, RRH, GES, Vehicles, Schafer, and Training & DevelopmentAddedDay view · holiday view · requester details · availability · booking actions · hover information
A / 01

From Exchange data to readable event cards.

A Node service normalizes Exchange events, filters dates and mailboxes, and handles time zones. The API supplies requester, time, purpose, and availability fields for readable week and day cards.

Exchange calendars→Node service→Calendar API→Event-based views
GET /api/calendar?start=&end=&mbox=
status = past | happening-now | upcoming | available
booking link = Microsoft Form + preselected vehicle
sort(today) = happening now → upcoming → earlier
O / 01

Availability becomes a clear next action.

Green identifies availability, blue identifies future bookings, orange identifies events happening now, grey identifies past events, and a red treatment marks the current day. Current events automatically appear ahead of future and past items. Requester and booking information is visible where useful, and clicking an available vehicle opens a shorter booking path with the vehicle already selected.

900+users in the supported company environment
6calendar areas redesigned for their own information needs
5ways to inspect time: month, week, day, agenda, holiday
1 clickfrom an available vehicle to a preselected booking form
CASE 02Medora exploration guide
Code complete · awaiting final content

Full-stack exploration app

A town to explore. A reason to look closer.

I designed and built a full-stack exploration guide for Medora. Players discover locations, complete challenges, earn XP, and keep a personal journal.

Role
Concept · UX · database · full-stack development
Stack
HTML · CSS · JavaScript · Node.js · Express · SQLite
Result
Code complete and presented; awaiting final company content
Explore the experienceInteractive preview · product · development story
9:41● ● ●

YOU ARE HERE

Von Hoffman House

INVESTIGATE · 1,000 XP

What detail tells you how this home changed over time?

2 of 3 discoveries complete
TRANSACTION TRACE / ANSWER SUBMISSION
  1. 01Session verifiedrequireAuth
  2. 02Location resolvedroute_stops
  3. 03Challenge loadedstop_challenges
  4. 04Answer recordeduser progress
  5. 05XP committedprofile update
  6. 06Journal createdhistory preserved
PRODUCT MAP / 01

Discover. Complete. Remember.

Built for guests, employees, and seasonal workers, the guide connects location discovery, personal progress, recommendations, and a journal.

01
Profile

Character, XP, completed locations and challenges, personal stats, and leaderboard position.

02
Hunt

Medora locations with Observe, Investigate, and Experience challenges.

03
Recommendations

Places and activities to help players decide what to explore next.

04
Journal

Completed challenges, timestamps, locations, answers, XP, and Did You Know facts.

CHALLENGE LADDER / 02

Deeper exploration earns more XP.

XP accumulates across independent locations. The more a person observes, investigates, and experiences, the more progress they earn and the farther they can move on the leaderboard.

LEVEL 01ObserveQuick discovery

Something a player can notice in seconds or within a few minutes. It introduces the location and asks them to look with purpose.

Lower XP
LEVEL 02InvestigateFocused exploration

The player must search, read, compare, or spend several minutes looking around to find the answer.

Higher XP
LEVEL 03ExperienceParticipate in the place

The player must actually engage with what the location offers. These challenges take the most time and intentionally earn the greatest XP.

Highest XP
THE SIMPLE RULEMore time and deeper participation → more XP → stronger leaderboard progress.
PLAYER RECORD / 03

A personal record for every player.

Authentication happens behind the interface. Once signed in, every answer and completion belongs to the correct user and remains available when they return.

PLAYER / WOH-024
W
Chosen character

Each user selects a character that becomes part of their personal profile and experience.

AUTHENTICATIONIdentifies the returning player
→
PROFILEXP, character, locations, challenges
→
PROGRESSAnswers and completions by user
→
JOURNALPermanent record of discoveries
CONTINUITY PLAN / 04

Built for the next administrator.

Locations, questions, rewards, and recommendations live in the database. Administrators can update content without changing application code.

DATABASE-CONTROLLED CONTENT
  • Locations and display order
  • Questions, answers, and categories
  • XP rewards and automatic totals
  • Users, characters, and progress
  • Recommended places and activities
  • Did You Know facts and journal content
OPERATOR CHEAT SHEETNO CODE CHANGE REQUIRED
-- Add or update content
UPDATE stop_challenges
SET xp_reward = 1500
WHERE difficulty = 'experience';

-- Result
Database change → API response → web app

Ready-to-use SQL instructions let a future administrator copy the correct statement into the database application. The updated location, question, reward, recommendation, or order then appears in the web app without requiring knowledge of the underlying code.

ITERATION RECORD / 05

From a fixed route to free exploration.

The final product kept the playful motivation of the original scavenger hunt while removing the restrictions that made the early version harder to expand and less flexible for players.

EARLIER MODEL
Routes, letters, and character powers
  • Three predefined routes
  • Locations completed in a required order
  • One question and one earned letter per stop
  • Letters combined into a final word
  • Characters planned to have task-solving powers
  • A simpler points-per-question model
≈ 5 MAJOR ITERATIONS→
CURRENT MODEL
Free-roam locations and independent progress
  • Start anywhere and visit places in any order
  • Every location works independently
  • Multiple questions and activities per location
  • Observe, Investigate, and Experience categories
  • Characters personalize the profile rather than changing difficulty
  • XP accumulates by completed activity and location
CURRENT STATECode complete. Presented to the company.

Next: approve locations and questions, decide XP incentives, enter the final content, and launch.

READY FOR CONTENT
CASE 03Flight Tracker and Finder
Advanced Data Structures · C++

Advanced Data Structures · course project

One network. More ways to find a route.

I built a C++ command-line engine that turns airport and flight files into a searchable graph. It finds routes by fare, distance, connections, time, and required stops.

View source on GitHub ↗
Built
16 search operations in approximately one month
Stack
C++ · BFS · Dijkstra · time-aware search
Scale
100+ airports; 100,000+ original course flight records
Explore the route engineInteractive graph · 16 searches · source code
ILLUSTRATIVE ROUTE REQUEST / USER VIEWLOWEST TOTAL FARE
BISBismarck
DENDenver
MSPMinneapolis
ORDChicago
ATLAtlanta
DFWDallas
JFKNew York
Conceptual example — not captured program output
REQUESTMinimum total cost
EXAMPLE ROUTEBIS → DEN → ORD → JFK
EDGE WEIGHTFare in dollars
ENGINEDijkstra with fare weights
Q / 01

Choose the question. Inspect the search.

Explore the original 16-operation menu. Each request shows its inputs, output, and underlying search strategy.

Airport and direct-flight lookup
Path and optimization
Reachability limits
Required stop and time

All 16 operations from the original command-line menu are represented here.

E / 01

One graph, multiple definitions of “best.”

Every flight is directional. A route from airport A to airport B does not automatically create a route back from B to A. The request determines how the graph is traversed and what each connection means.

BFS
Queue-based traversal

Used to discover a valid multi-stop path and to explore which destinations remain reachable under flight-count or fare limits.

PATHS / REACHABILITY
DIJKSTRA
Variable edge weights

The same shortest-path routine can treat each connection as fare, miles, or a unit weight of one flight, depending on the selected menu operation.

FARE / MILES / CONNECTIONS
TIME-AWARE
Constrained route search

Separate routines account for departure times, arrival times, elapsed hours, and a required middle airport. Required-stop requests run in two stages: source to M, then M to destination.

TIME / REQUIRED STOP
USER CHOICEMenu operation→SEARCH PRIORITYPath · hops · fare · miles · time→RETURNMatching flights or best route

The algorithms operated behind the interface; users selected the travel question they wanted answered rather than selecting an algorithm by name.

D / 01

The data structure made every route addressable.

Airport codes were mapped to indexes for fast lookup. The route matrix then used an origin index, destination index, and flight-option index to preserve every available directed flight between two airports.

FAST LOOKUPairportIndex["BIS"] → 12airportIndex["DEN"] → 46

An unordered map converts a human-readable airport code into the index used by the graph.

→
3D FLIGHT STORAGEflights[origin][destination][option]
12460...n

The first two dimensions identify the route. The third stores each separate flight option available on that route.

→
FLIGHT RECORD
  • Origin and destination
  • Departure, arrival, and duration
  • Fare and miles
  • Flight ID and airline
Classes and structs

Grouped related airport and flight fields into records the algorithms could pass through consistently.

Directed connections

Each stored flight represented movement from one specific origin to one specific destination.

Multiple flight options

The third dimension retained more than one possible flight between the same pair of airports.

Indexed access

The unordered map avoided repeatedly scanning the airport dataset to locate a code.

C / 01

The difficult part was making the entire system agree.

This was my first time working with a dataset this large and my first time combining graph traversal, weighted optimization, schedule constraints, and 16 different requests in one application. The challenge was not limited to one isolated bug.

01Parse

Read two large datasets while keeping airport and flight records consistent.

→
02Index

Resolve airport codes quickly enough to support repeated interactive requests.

→
03Model

Represent directed routes and multiple flight options without losing their details.

→
04Search

Choose the correct traversal or weighted strategy for each user request.

→
05Constrain

Combine stops, times, fares, hours, distances, and destination requirements.

“The whole thing was hard to do.” That difficulty is what made it the first project that showed me I could work through real data complexity rather than only small classroom examples.
S / 01

The complete project is now available on GitHub.

The public repository contains the original C++ implementation, supporting data files, and instructions for compiling and running the 16-operation command-line application locally.

PUBLIC REPOSITORY github.com/FwDubbb/flighttracker

Review the graph structure, route-search algorithms, airport lookup system, and constrained flight operations used throughout the project.

g++ -std=c++11 11weird.cpp -o flighttracker ./flighttracker place.a1 quizn.air2
View source and run locally ↗
PROJECT CONTENTS
  • Complete C++ source code
  • Airport and flight data files
  • Sixteen command-line operations
  • BFS, Dijkstra, and constrained graph searches
  • Local compilation and usage instructions

The route map above is an interactive explanation, not a claim that the original program used a graphical interface. The 100,000+ scale refers to the original course dataset; smaller public sample files can be included for reproducible demonstrations.

100+ airports 100,000+ original course records 16 menu operations 2 core graph algorithms 1 directed network
02 / EXPERIENCE RECORD

Places and practice Work history

Experience that
shapes the work.

Full record · PDF Open my résumé Dates, roles, responsibilities, and outcomes
MAY – AUG 2026
THEODORE ROOSEVELT MEDORA FOUNDATION · MEDORA, ND

IT Intern

Built internal tools and automation while supporting IT across approximately 30 outlets and venues. Managed access for 90+ full-time employees and 300 seasonal workers.

Microsoft 365 Zapier SharePoint Web development User management IT support
JUL 2024 – PRESENT
DAKOTA STATE UNIVERSITY · RESIDENCE LIFE · MADISON, SD

Resident Assistant

Helped lead a community of 40+ students through conflict resolution, programming, and everyday support.

Leadership Conflict resolution Community building Event planning
MAY – JUL 2025
E-CRIMEBUREAU · GHANA

IT and Cybersecurity Intern

Automated security reporting in Python, reducing case documentation time by 25%. Improved the LMS for 200+ users and supported digital forensics investigations.

Python Cybersecurity TCP/IP analysis Digital forensics LMS design
FALL 2023
JOBS NATION INC.

Technology Research and Risk Intern

Researched emerging technologies and risk. Built Python scripts that improved market-research data collection efficiency by 30%.

Python Technology research Risk assessment Market analysis

Education / next chapter

Dakota State University

B.S. Computer Science · Software Engineering & Cyber Security

Expected June 2027 · Honors List · GPA 3.86 / 4.0

Coursework & campus leadership

Technical foundation

Advanced Data Structures, Software Security, Web Development, Networking, Discrete Math, Calculus II, Statistics, Parallel Computing, Operating Systems, and Object Oriented Design.

Beyond the classroom

  • Teaching Assistant: tutored 40+ students in programming and algorithms.
  • Black Students Union Vice President: helped grow membership by 70%.
  • Student Activities Board: organized 10+ campus events.
  • DSU CRU: worship, cell, and Bible study group leader.
03 / TOOLKIT

Skills / applied in the work

The tools behind
the experience.

Software engineering, reliable systems, and interfaces that help people get things done.

More technologies & coursework projects

Additional tools: C, C#, Java, x86 Assembly, ReactJS, Linux, Git, Docker, AWS (basic), packet analysis, and vulnerability assessment.

  • Interactive Shopping System: C++ shopping flow with dynamic discounts and real-time cart updates.
  • Assembly optimization: binary search in x86 Assembly with a 30% execution speedup.
  • Data structures analysis: file-based C++ key-value storage comparing hashing, Trie, and Red-Black Tree structures.
  • This portfolio: custom interactive design; 500+ unique visitors since launch, as recorded in my résumé.

04 / Next step Contact

Let’s build
something useful.

Have a software role, a project, or an idea to explore? I’m interested in development, automation, and systems that make everyday work easier.

Email William ↗ LinkedIn ↗