Skip to content

full_stack.md

Latest commit

 

History

History
82 lines (53 loc) · 4.1 KB

full_stack.md

File metadata and controls

82 lines (53 loc) · 4.1 KB

Take-Home Project: Ministry Events API & Dashboard

Overview

Build a small full-stack web application that allows a church staff member to manage and display ministry events. This project is designed to reflect the kind of work you'd actually do in this role. This project is intentionally scoped so it should not require more than about 6–8 hours of work. Please focus on clarity and good structure rather than completeness or polish.

The Scenario

Church of the Highlands runs dozens of events each week across multiple campuses. You've been asked to build a simple internal tool that lets staff create and manage events, exposes that data via a REST API, and displays it in a clean public-facing dashboard.

Requirements

1. Back-End API (Required)

Build a RESTful API using a back-end framework of your choice (we currently use NodeJS with AWS SAM, but feel free to use what you’re comfortable with) with the following endpoints:

  • GET /api/events — return a list of events
  • GET /api/events/{id} — return a single event
  • POST /api/events — create a new event
  • PUT /api/events/{id} — update an event
  • DELETE /api/events/{id} — delete an event

Each event should have at minimum: a title, description, campus location, category (e.g., Worship, Young Adults, Kids), start date/time, and published status.

2. Data Layer (Required)

  • Use a database (We been using PostgreSQL with Drizzle ORM lately, but use whatever you want.)

3. Front-End Dashboard (Required)

Build a simple UI (We typically use NextJS, but again, feel free to choose something else if you'd like) that has two views:

Public View — a clean, readable list of events that:

  • Only displays published events

Admin View — a simple management page (no auth required, a direct link or route is fine) that:

  • Displays all events regardless of published status
  • Allows toggling an event between published and unpublished
  • Has a form for creating new events
  • Allows editing or deleting existing events

Focus on desktop usability. This doesn't need to be pixel-perfect, but it should be clean and usable. Think functional over flashy.

4. Documentation (Required)

Include a README.md that covers:

  • How to set up and run the project locally
  • Any environment variables needed ⠀

Bonus (Optional)

These are not expected, but welcomed if you want to go further:

  • Add pagination to the events list
  • Include a seed file that populates the database with a variety of realistic sample events.
  • Add token-based authentication to protect the admin endpoints
  • Write unit or feature tests for at least two API endpoints
  • Include an Entity Relationship Diagram in the README that shows how the tables are laid out and connected.
  • Make it flashy. Modern, clean designs, animations, toasts on save or delete, looks good on mobile, etc.
  • Allows filtering by campus or category
  • Integrate with a third-party API of your choice. Here are some potential options: https://github.com/public-apis/public-apis

Evaluation Criteria

You'll be evaluated on these things, roughly in order of importance: Code quality — Is it readable, consistent, and organized? Would another developer be able to pick it up easily? You can assume that we’ll ask you to walk through and/or explain any part of your code during the review process. Architecture — Does the structure make sense? Are concerns separated appropriately? Does it feel like it could grow? API design — Are the endpoints logical and RESTful? Is error handling present? Database design — Are the migrations clean? Does the schema make sense for the problem? Documentation — Could someone set this up without asking you questions? UI judgment — Does the front end feel like it makes sense, even if simple?

Submission

Please submit a link to a GitHub repository (public or shared with the hiring team). Make sure the repo does not contain any real API keys or credentials.

The goal isn't perfection — it's to see how you think, how you build, and how you communicate about your work. Build something you'd be comfortable putting your name on.