IT Helpdesk Specialist — The Potomac School · McLean, VA
I'm Jacob Goldstein, a computer science graduate who troubleshoots complete systems: Linux and Windows, DNS and SSL, Apache, AWS, networks, and the hardware underneath. My background combines systems and infrastructure internships, academic robotics and ROS, and a personal habit of building things with my hands — and I chose hands-on IT work on purpose, not as a fallback.
Local, evidence-first diagnostics for AWS SAM and GitHub Actions failures. It reads the logs, templates, and CloudFormation evidence instead of guessing. 96 documented diagnostics, on PyPI and the GitHub Marketplace. Nine other contributors have joined since launch.
Uncertainty-aware evidence tooling for historical Cyrillic and Polish civil registers, built to keep readings, alternatives, provenance, and review state visible.
Read researcher overview ↗
The part of computing I love is the systems side. At Pitt's Visual Media Workshop I supported a research team's infrastructure — Linux, Apache configuration, DNS changes, SSL transfer, SFTP and WordPress migrations, GPU workstations — and planned the moves so the team kept working through them. The summer before, I deployed and supported AWS services and troubleshot issues alongside other teams.
My experience is deliberately mixed: infrastructure internships, academic robotics and ROS from my degree, and personal hands-on projects — PCs I've built myself, a home lab and network I use as a testing ground. The common thread is troubleshooting a complete system: hardware, network, OS, software, and the person using it.
I'm building a career in hands-on IT support and infrastructure — work where the fix matters to someone standing next to you, and where methodical troubleshooting and clear documentation compound into deeper systems responsibility over time.
University of Pittsburgh — Visual Media Workshop
Pricing Empowered
Local, evidence-first diagnostics for AWS SAM and GitHub Actions deployment failures — the tool I wished for while running SAM deployments at my internship. Works from the real logs and templates, and every diagnosis cites the evidence it was drawn from.
Provisioned local clusters with Kind and Bash; scripted lifecycle management to monitor pod networking and service discovery; ran Docker workloads under deliberate CPU/RAM constraints — and documented the setup steps and failure points for repeatable troubleshooting.
Open-source fall-detection prototype running in real time from a single RGB camera. Applied state-machine logic to filter inference noise and reduce false-positive triggers; documented setup and testing for reproducible deployment on the device.
Open benchmark corpus for handwritten-text recognition on 19th-century Jewish vital records from Pułtusk and Serock (Polish and Russian-Cyrillic). Grew out of tracing my own family. Evaluation reports per-page error distributions and name-level accuracy — because a mangled surname becomes someone's wrong ancestor. Backed by a blind multi-reader transcription pipeline with human-verified gold records.
Local-first email triage pipeline: read-only Gmail ingestion, offline LLM summarization with per-message caching, a desktop dashboard, and a one-command verify harness. Built spec-driven — each change ships with its acceptance tests, and a skipped test is never reported as a pass.
Fine-tuned Stable Diffusion v1.5 on a 6,737-image dataset and presented GPU workload performance findings to the Pitt research cohort.
Studied robotics with ROS (Robot Operating System) as part of my degree — hands-on exposure to full physical systems, where debugging means isolating layers across sensors, software, and hardware. The same discipline I use in IT troubleshooting.
I build and upgrade my own machines — component selection, assembly, troubleshooting, OS setup — and run a home lab and network that serve as the testing ground for my Linux and Kubernetes work. Personal projects, not professional trade work; the comfort with tools and the careful hands are real either way.
Troubleshooting only counts if you can explain it afterward. Three real problems, written the way I'd write the ticket.
A research team's web presence — WordPress Multisite, SFTP-served projects, custom DNS, SSL — had to move, and the team had to keep working through the move.
Validated hardware, SSL and DNS paths, and deployment targets before each move rather than after; migrated in stages; chased down the permissions and deployment issues each stage surfaced.
No unplanned downtime across the migrations, and a written handoff so the next person didn't need me in the room.
Unplanned downtime gets scheduled earlier than anyone thinks — by whoever skipped validation.
My local email-triage pipeline pegged the CPU on every polling cycle, far past what fresh mail volume could explain.
Two compounding causes: summaries were recomputed for messages that hadn't changed, and the 2.5 GB local model was reloaded from disk every cycle instead of living across them.
Cache summaries by message_id; fix the model lifecycle so it loads once. Each fix shipped as a written spec with acceptance tests, then verified by a one-command harness before it counted as done.
Measure before optimizing — the expensive thing is rarely the thing you assumed.
AWS SAM deployments through GitHub Actions fail with errors that name the symptom but not the cause — and the cause is spread across templates, build logs, and CloudFormation events nobody reads under pressure.
Built a local diagnostic tool that reads the actual logs and templates and refuses to guess: every diagnosis it offers cites the evidence it was drawn from.
An answer without evidence is a hypothesis. Tickets close faster when the diagnosis shows its work.
IT troubleshooting, user support, hardware troubleshooting, ticket and technical documentation, escalation, Windows fundamentals, customer support.
Linux, DNS, SSL/TLS, networking fundamentals, Apache, WordPress, SFTP, permissions, NVIDIA GPU workstations.
AWS (Lambda, S3, SAM, CloudFormation), Docker, Kubernetes fundamentals, Bash, Python, SQL, Git, GitHub Actions, CI/CD, REST APIs.
University of Pittsburgh — Class of 2025
Secondary field: Applied Mathematics & Statistical Computing.
Coursework included robotics and ROS — academic experience.
George Mason University — Cyber Security concentration
Part-time; start term not yet set.
This page is served by an nginx instance I administer on AWS Lightsail — not a website builder. TLS is Let's Encrypt with auto-renewal across apex and www. External monitoring by UptimeRobot — the uptime history is public.
Content ships over SSH through a scripted deploy that takes a timestamped backup before every
replacement, sets ownership and permissions explicitly, and has a written rollback plan.
Config changes never skip nginx -t.
fail2ban jails on SSH and HTTP auth. The private area rides Basic Auth over HTTPS only, with noindex and no-store headers and the credential hash kept outside the web root.
The whole setup — layout, deploy procedure, auth notes, rollback — lives in a deployment runbook written so someone who isn't me could operate it. That's the standard I bring to any system I touch.
Analytics here are first-party and cookieless — nothing leaves this server. This is a small production system. It's maintained the way I'd maintain yours.
Now: IT Helpdesk Specialist at The Potomac School. Always glad to talk shop — systems, infrastructure, or the printer that won't print.
Loading current summary
Aggregate nginx security-log summary. Probe counts are requests intercepted by explicit hardening rules or suspicious-query guards — not ordinary visitors or IP addresses.