Core Idea: Every 3 weeks, you have enough knowledge to either: 1. Participate in a hackathon (with something impressive to show) 2. Pass an internship technical interview (on that topic) 3. Build a portfolio project (deploy, demo, share)
Each sprint adds 1-2 deep skills while reviewing/reinforcing previous ones.
Total Timeline: 12 sprints = 36 weeks = 9 months
| Sprint | Weeks | Focus | Hackathon Project Idea | Interview Ready For |
|---|---|---|---|---|
| Sprint 1 | 1-3 | Agent basics + first tool use | Simple tool-calling bot | “What’s an agent?” |
| Sprint 2 | 4-6 | Multi-tool agents | Task assistant | “How would you build X agent?” |
| Sprint 3 | 7-9 | Agent reasoning + memory | Debate system | “Explain agent failures” |
| Sprint 4 | 10-12 | Production agents (logging, errors) | Customer service bot | “How do you make agents production-ready?” |
| Sprint 5 | 13-15 | Android basics + lifecycle | Simple counter app | “Explain Activity lifecycle” |
| Sprint 6 | 16-18 | Android data persistence | Notes app with Room | “How do you store data?” |
| Sprint 7 | 19-21 | Android networking | News app | “How do apps talk to APIs?” |
| Sprint 8 | 22-24 | Android MVVM + UI polish | Todo app | “What’s MVVM and why use it?” |
| Sprint 9 | 25-27 | AWS fundamentals + EC2 | Deploy a web server | “What’s AWS and when use which service?” |
| Sprint 10 | 28-30 | AWS databases + security | Deploy RDS instance | “How do you design secure architecture?” |
| Sprint 11 | 31-33 | Agents + Android integration | AI chatbot on Android | “How do you integrate AI into apps?” |
| Sprint 12 | 34-36 | Full-stack integration (Agents + Android + AWS) | Impressive capstone | “Walk me through your system” |
Hackathon Project: Simple multi-tool chatbot (e.g., calculator + weather bot) Interview Readiness: Explain what an agent is vs. a chatbot
Days 1-2: Learn Concepts - Read Anthropic’s agent docs (1 hour) - Watch 1 conceptual video on tool use (15 mins) - Key Questions to Answer: - What’s the difference between a chatbot and an agent? - What is “tool use” / “function calling”? - Why would I need an agent?
Days 3-5: First Code - Set up Python environment
(virtual env, install anthropic) - Run the Anthropic
quickstart example (get it working) - Understand each
line:
python response = client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=1024, tools=tools, # What is this? messages=messages # What goes here? )
- Don’t memorize—understand why
Days 6-7: First Mini-Project - Build simple calculator agent (add, subtract, multiply) - Test with: “What is 15 * 7?” - Debug: What if agent doesn’t use the tool? Why?
Deliverable: Working calculator agent + 1-page explanation of how it works
Days 1-3: Deep Dive into Tool Use - Read: Anthropic tool use docs in detail - Diagram: Draw the agent loop (Request → Think → Call Tool → Process → Respond) - Experiment: Change tool definitions, watch agent behavior change - Example: Remove a tool, try to use it anyway (agent refuses) - Example: Make tool description vague, watch agent struggle
Days 4-5: Add Multiple Tools
tools = [
{
"name": "calculator",
"description": "Basic math operations",
# ...
},
{
"name": "weather", # Fake, but realistic
"description": "Get weather for a city",
# ...
}
]Days 6-7: Error Handling - What if user asks something tools can’t do? - What if tool fails? - Add try/catch blocks, meaningful error messages
try:
result = get_weather("Manhattan")
except Exception as e:
result = f"Sorry, couldn't get weather: {e}"Deliverable: Multi-tool agent (calculator + weather) with error handling
Days 1-3: Build Hackathon Project
Project Idea: Personal Task Assistant
User: "Remind me to call mom at 3pm, then tell me the weather"
Agent:
- Parses: Two tasks (reminder + weather)
- Uses tools: reminder service + weather API
- Responds: "Set reminder ✓ | Weather: 72°F, sunny"Required Features: - ✓ At least 3 tools (reminder, weather, time/calculator) - ✓ Error handling - ✓ Clean output formatting - ✓ Works from command line
Days 4-5: Polish & Document - Add usage instructions - Create README with examples - Clean up code (comments, variable names) - Test thoroughly
Days 6-7: Demo Practice - Write a 2-minute demo script - Practice explaining: - “This is an agent because…” - “It uses tools to…” - “The tricky part was…”
Deliverable: Hackathon-ready project on GitHub
Interview Talking Point: > “I built a task assistant agent that uses multiple tools. Here’s what I learned: agents decide which tool to use based on understanding the request. The agent loop is: request → think → call tool → get result → decide if done or need another tool.”
Hackathon Project: Debate system (two agents arguing) Interview Readiness: Explain multi-agent coordination, when to use different tools
Days 1-2: Understand Context & Memory - Read:
How do agents remember previous interactions? - Experiment: Run same
agent twice, does it remember?
python # Message history is memory messages = [ {"role": "user", "content": "I like Python"}, {"role": "assistant", "content": "Great! Python is..."}, {"role": "user", "content": "Recommend a web framework"}, # Agent should remember you like Python ]
Days 3-5: Build Agent with Memory
# Simple conversation with memory
conversation_history = []
while True:
user_input = input("You: ")
conversation_history.append({"role": "user", "content": user_input})
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
messages=conversation_history, # Full history = memory
tools=tools
)
conversation_history.append({"role": "assistant", "content": response.content})Days 6-7: Context Optimization - Test: What happens with 100 turns of conversation? - Implement: Summarize old conversations - Challenge: Balance memory vs. performance
Deliverable: Agent that maintains conversation history + demonstrates memory effects
Days 1-3: Understand Tool Chaining - Concept: Agent
calls Tool A → gets result → calls Tool B → etc. - Example:
User: "Who's the CEO of OpenAI and how old are they?" Agent: - Tool 1: Search "CEO OpenAI" → "Sam Altman" - Tool 2: Search "Sam Altman age" → "38" - Respond: "Sam Altman, 38"
Days 4-5: Build Chained Agent - Create agent with: Wikipedia search + Calculator + Summary tool - Design scenarios that require chaining: - “How many countries are in the EU? Multiply by 2” - “Find an article about climate. Summarize it in 50 words”
Days 6-7: Optimize for Performance - Some chains are unnecessary (agent should learn) - Add reasoning: “Why is this agent calling this tool?”
Deliverable: Agent that chains multiple tools in logical order
Project: Two-Agent Debate
Topic: "Should AI be regulated?"
User asks question
↓
Agent Pro: Argues FOR regulation
Agent Con: Argues AGAINST regulation
Judge Agent: Evaluates both, decides winner
Output: Full debate transcript + winnerRequirements: - ✓ 3+ coordinated agents - ✓ Each agent has specific tools (Pro agent uses pro-regulation data, etc.) - ✓ Judge agent evaluates based on logic, evidence - ✓ Clean output formatting - ✓ GitHub repo with demo
Days 1-4: Build System - Create 3 agent functions (Pro, Con, Judge) - Each takes debate transcript, returns response - Orchestrate: Run Pro → Run Con → Run Judge
Days 5-6: Polish & Test - Test different topics - Make sure outputs are coherent - Add metadata (which agent is speaking, confidence scores)
Days 7: Demo & Document - Record a 2-minute demo - Write README explaining multi-agent architecture
Deliverable: Multi-agent debate system on GitHub + demo video
Interview Talking Point: > “I built a multi-agent system where agents debate each other. The key learning: coordinating agents is hard. You need clear protocols (who speaks when, how to pass info). I’d improve this by adding a moderator agent that enforces turn-taking.”
Hackathon Project: Production-ready customer service bot Interview Readiness: Discuss agent failures, evaluation, real-world challenges
Days 1-2: Learn Failure Modes - Read: Common agent failures - Hallucination: Agent invents tool results - Looping: Agent gets stuck calling same tool repeatedly - Misuse: Agent calls wrong tool for task - Confusion: Agent doesn’t understand when to stop
Days 3-5: Implement Detection
# Track what agent is doing
calls_made = []
max_iterations = 10
while iteration < max_iterations:
# Make call
tool_use = response # simplified
calls_made.append(tool_use)
# Detect: Is agent stuck?
if len(calls_made) >= 5 and calls_made[-1] == calls_made[-2]:
print("Warning: Agent looping!")
break
# Detect: Too many calls?
if len(calls_made) > max_iterations:
print("Warning: Agent won't stop!")
breakDays 6-7: Build Safeguards - Set max iterations (stop looping) - Add logging (debug what happened) - Graceful failures (“I couldn’t solve that”)
Deliverable: Agent with failure detection + logging
Days 1-3: Build Test Suite
test_cases = [
{
"input": "What's 5 + 3?",
"expected_tools": ["calculator"],
"success": lambda result: "8" in result
},
{
"input": "Tell me a joke",
"expected_tools": [], # No tools needed
"success": lambda result: "joke" in result.lower()
},
{
"input": "Who's the president?",
"expected_behavior": "refuse", # Agent should say it doesn't know
"success": lambda result: "don't know" in result.lower() or "not sure" in result.lower()
}
]Days 4-5: Run & Analyze - Run all test cases - Track: Pass rate, tool usage, response quality - Identify: Where does agent struggle?
Days 6-7: Improve - Adjust tool definitions - Refine system prompts - Re-test
Deliverable: Test suite + evaluation report (% pass rate, failure analysis)
Project: Smart Support Bot
Customer: "My order hasn't arrived and I want a refund"
Bot:
- Understands: Complaint + refund request
- Tools: Lookup order, check status, process refund, send email
- Handles: Not all problems (escalate to human)
- Logs: Everything for auditingRequirements: - ✓ Multiple realistic tools (order lookup, refund, email, escalation) - ✓ Production-quality logging - ✓ Error handling (graceful failures) - ✓ Test suite (15+ test cases) - ✓ Monitoring (tracks agent behavior)
Days 1-3: Implement - Design tools realistically - Implement agent loop with guards - Add comprehensive logging
Days 4-5: Test & Debug - Run test suite - Fix failures - Document edge cases
Days 6-7: Demo - Show real conversation examples - Highlight: “Here’s where agent fails gracefully” - Explain: “Here’s how I’d improve this”
Deliverable: Production-ready bot on GitHub + test results + demo
Interview Talking Point: > “I built a customer service bot that handles common cases but knows to escalate edge cases. Key learning: production agents need monitoring, logging, and failure handling. I implemented a test suite to verify behavior. The hardest part was deciding when to escalate vs. handle automatically—I’m using a confidence threshold.”
Hackathon Project: Choose your own adventure (routing agent or planning agent) Interview Readiness: Explain different agent architectures, pros/cons
Days 1-2: Understand Routing - Concept: Agent decides “this problem goes to expert A, that goes to expert B” - Example: Customer service routing (billing → billing expert, technical → tech expert)
Days 3-5: Build Router
def router_agent(customer_query):
# Router decides category
category = agent_classify(customer_query) # "billing", "technical", "general"
if category == "billing":
return billing_agent(customer_query)
elif category == "technical":
return technical_agent(customer_query)
else:
return general_agent(customer_query)Days 6-7: Optimize - What if multiple categories? (handle both) - What if unsure? (ask for clarification)
Deliverable: Working routing system with 3+ specialist agents
Days 1-3: Understand Planning - Concept: Agent creates plan first, then executes - Example: “Plan a trip to Japan” → creates itinerary → books flights → books hotels - Why: Keeps agent on track, easier to evaluate
Days 4-5: Build Planner
def planning_agent(goal):
# Step 1: Create plan
plan = agent_create_plan(goal)
# Outputs: ["Step 1: Search flights", "Step 2: Book flight", ...]
# Step 2: Execute plan
results = []
for step in plan:
result = execute_step(step)
results.append(result)
return resultsDays 6-7: Evaluate Plans - Test: Does plan make sense? - Test: Can agent execute it? - Test: What if plan is wrong? (agent should adapt)
Deliverable: Agent that plans before executing
Option A: Routing Agent - Master agent routes to specialists - Example: Health advisor (routes to doctor-bot, nutritionist-bot, fitness-bot)
Option B: Planning Agent - Agent plans complex task step-by-step - Example: Event planner (plans, books, coordinates)
Option C: Hybrid - Combine routing + planning - Example: Trip planner (routes travel decisions to flight expert, hotel expert, activities expert)
Weeks 10-12 Deliverable: - Working specialized agent on GitHub - Clear explanation of when to use this architecture - Demo showing it outperforms simpler agents
Interview Talking Point: > “I built a [routing/planning/hybrid] agent because [specific problem]. The advantage of this architecture is [X]. I evaluated it against [simpler baseline] and found [improvement]. For different problems, I’d use a different architecture—here’s how I’d decide.”
Hackathon Project: Simple app (counter, to-do list, or weather display) Interview Readiness: Explain Activity lifecycle, Android fundamentals
Days 1-2: Setup & Concepts - Download Android Studio, create emulator - Understand: Activities, Fragments, Intents - Watch: Android fundamentals video (~20 mins)
Days 3-5: Build First App - Create “Hello World” app
(understand structure) - Understand files: - Activity.kt
(the screen/logic) - activity_main.xml (the layout/UI) -
AndroidManifest.xml (app configuration)
Days 6-7: Build Counter App - Add button “Increment” - Display counter - Understand: onClick listeners, state management
Deliverable: Working counter app + understanding of Activity lifecycle
Days 1-2: Layout Systems - ConstraintLayout (modern, recommended) - Understand: How positioning works (constraints, weights)
Days 3-5: Build UI-Heavy App
<ConstraintLayout>
<Button android:id="@+id/btn_add" />
<EditText android:id="@+id/input_text" />
<TextView android:id="@+id/output" />
</ConstraintLayout>Days 6-7: Event Handling - Buttons, text input, click listeners - Update UI based on user actions
Deliverable: Polished to-do list UI
Project Ideas: - Weather display (fetch real data later) - Expense tracker (local storage) - Quiz app - Countdown timer
Requirements: - ✓ Working app in emulator - ✓ At least 2 screens (2 Activities) - ✓ User input + output - ✓ Polished UI (Material Design) - ✓ GitHub repo with APK file
Weeks 13-15 Deliverable: - Working app on GitHub - Demo video (~1 min)
Interview Talking Point: > “I built a [app name]. It has [features]. I learned that [Android concept] and [challenge]. Here’s how I solved it. If I had more time, I’d add [feature].”
Hackathon Project: Notes app with local storage Interview Readiness: Explain Android data storage options, Room ORM
Days 1-2: Understand Databases - What’s a database? (organized data storage) - What’s an ORM? (Object-Relational Mapping—turn objects into database rows)
Days 3-5: Build with Room
// Define entity (table)
@Entity(tableName = "notes")
data class Note(
@PrimaryKey val id: Int,
val title: String,
val content: String
)
// Define DAO (data access object)
@Dao
interface NoteDao {
@Query("SELECT * FROM notes")
fun getAllNotes(): LiveData<List<Note>>
@Insert
suspend fun insertNote(note: Note)
}
// Database class
@Database(entities = [Note::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
abstract fun noteDao(): NoteDao
}Days 6-7: Test & Understand - Insert notes - Query notes - Delete notes - Observe data changes with LiveData
Deliverable: Working notes database with CRUD operations
Project: Full Notes App
Features:
- Create note (input title, content)
- View all notes (list)
- Edit note
- Delete note (swipe gesture)
- Search notesRequirements: - ✓ Room database (full CRUD) - ✓ RecyclerView to display list - ✓ Proper UI/UX - ✓ Error handling - ✓ Clean code + comments
Weeks 16-18 Deliverable: - Polished notes app on GitHub - Demo video showing all features
Interview Talking Point: > “I built a notes app using Android’s Room ORM. Key learning: Room abstracts SQLite and makes it safe (prevents SQL injection). RecyclerView efficiently displays lists. I used LiveData to observe database changes and automatically update the UI. This taught me about Android’s reactive patterns.”
Hackathon Project: News app or weather app Interview Readiness: Explain networking, Retrofit, async programming
Days 1-2: Understand HTTP - HTTP methods: GET, POST, PUT, DELETE - Status codes: 200 (success), 404 (not found), 500 (error) - JSON format
Days 3-5: Learn Retrofit
// Define API service
interface NewsApiService {
@GET("v2/top-headlines")
suspend fun getHeadlines(
@Query("country") country: String,
@Query("apiKey") apiKey: String
): Response<NewsResponse>
}
// Create instance
val retrofit = Retrofit.Builder()
.baseUrl("https://newsapi.org/")
.addConverterFactory(GsonConverterFactory.create())
.build()
val service = retrofit.create(NewsApiService::class.java)Days 6-7: Make Requests - Fetch data from API - Handle responses - Handle errors
Deliverable: Simple app that fetches data from public API
Days 1-2: Understand Threading - Main thread: UI (can’t block) - Background threads: Network/database (can take time) - Why: If network call blocks main thread → UI freezes
Days 3-5: Use Coroutines
// Coroutine: Lightweight, readable async code
viewModelScope.launch { // UI thread
try {
val response = apiService.getHeadlines("us", API_KEY) // Network thread
headlines.value = response.body()?.articles // Back to UI thread
} catch (e: Exception) {
error.value = e.message
}
}Days 6-7: Handle Loading States - Show spinner while loading - Show error if request fails - Show data when success
Deliverable: App with proper loading/error UI
Project: News Reader
Features:
- Fetch latest news
- Display in list (RecyclerView)
- Click article → show details
- Favorite articles
- Pull-to-refreshOR: Weather App
Features:
- Enter city name
- Fetch weather
- Display temperature, conditions, forecast
- Show on mapRequirements: - ✓ Real API calls (NewsAPI.org, OpenWeatherMap, etc.) - ✓ Proper error handling - ✓ Loading indicators - ✓ Caching (optional: don’t fetch every time) - ✓ Clean UI
Weeks 19-21 Deliverable: - Working app on GitHub - Demo video
Interview Talking Point: > “I built a news app that fetches real data from an API using Retrofit. Key challenges: handling network errors gracefully, showing loading states, and parsing complex JSON. I learned about coroutines—they make async code readable without callbacks. I’d add caching to reduce API calls and improve offline support.”
Hackathon Project: Complete app using MVVM Interview Readiness: Explain app architecture, testability, best practices
Days 1-2: Understand MVC vs. MVP vs. MVVM - MVC: Model-View-Controller (activity does everything—messy) - MVP: Model-View-Presenter (separation but callbacks) - MVVM: Model-View-ViewModel (reactive, testable—best for Android)
Days 3-5: Restructure Existing App with MVVM
// ViewModel holds logic and state
class NewsViewModel : ViewModel() {
private val _headlines = MutableLiveData<List<Article>>()
val headlines: LiveData<List<Article>> = _headlines
fun loadHeadlines() {
viewModelScope.launch {
try {
val response = apiService.getHeadlines("us", API_KEY)
_headlines.value = response.body()?.articles
} catch (e: Exception) {
// Handle error
}
}
}
}
// Activity/Fragment just observes
class NewsFragment : Fragment() {
private val viewModel: NewsViewModel by viewModels()
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
viewModel.headlines.observe(viewLifecycleOwner) { articles ->
displayArticles(articles)
}
viewModel.loadHeadlines()
}
}Days 6-7: Understand Benefits - Testable (test ViewModel without UI) - Lifecycle-aware (survives rotation) - Clear separation (logic vs. UI)
Deliverable: Previous project refactored with MVVM
Days 1-2: Unit Testing - Test ViewModels - Mock dependencies (API, database)
Days 3-5: Write Tests
@Test
fun testLoadHeadlines() {
val viewModel = NewsViewModel(mockApiService)
viewModel.loadHeadlines()
assertEquals(2, viewModel.headlines.value?.size)
}
@Test
fun testHandleError() {
val viewModel = NewsViewModel(mockApiServiceThatFails)
viewModel.loadHeadlines()
assertNotNull(viewModel.error.value)
}Days 6-7: Code Review - Clean code (naming, comments, organization) - Documentation (how to run, deploy) - GitHub standards (good commits, README)
Deliverable: Test suite + improved codebase
Capstone: Build a “Real” App
Ideas: - Expense Tracker: Track spending, categorize, show reports - Habit Tracker: Log daily habits, show streak, push notifications - Todo + Notes + Calendar: Integrated productivity app - Movie/Game Database: Browse, save favorites, add reviews
Requirements: - ✓ MVVM architecture - ✓ Local storage (Room database) - ✓ Networking (fetch real data from API) - ✓ Unit tests (10+ tests) - ✓ Error handling - ✓ Professional UI (Material Design) - ✓ Fully documented (README, code comments)
Weeks 22-24 Deliverable: - Complete app on GitHub - Demo video (3-5 mins showing all features) - Test results - README with architecture diagram
Interview Talking Point: > “I built [app name] using MVVM architecture. Here’s how the layers interact: ViewModel fetches from Repository → Repository combines local (Room) and network (Retrofit) data → UI observes LiveData. I wrote tests for ViewModels. The tricky part was handling offline—I cache network responses locally so the app works without internet. I’d add [feature] for the next version.”
Hackathon Project: Deploy a web server or simple backend Interview Readiness: Explain AWS services, architecture decisions
Days 1-2: Concepts - What is cloud computing? (compute, storage, databases on demand) - AWS services overview (EC2, S3, RDS, Lambda, etc.) - Pricing model (pay for what you use)
Days 3-5: Hands-On - Create AWS account (use free tier) - Understand billing (monitor costs) - Launch EC2 instance - SSH into it - Run a command
Days 6-7: Understand Each Service | Service | Purpose | Example | |———|———|———| | EC2 | Virtual machines | Run a web server | | S3 | File storage | Store images, backups | | RDS | Databases | PostgreSQL, MySQL | | Lambda | Serverless functions | Run code on demand | | Route53 | Domain names | Point yourdomain.com to server |
Deliverable: Running EC2 instance + understanding of services
Days 1-2: VPC & Security Groups - VPC: Your isolated network - Security Groups: Firewalls - IAM: Who can do what
Days 3-5: Set Up Secure Infrastructure
EC2 Instance
├── Security Group (allow HTTP, HTTPS only)
├── IAM Role (EC2 can read S3)
└── Inside instance: run web serverDays 6-7: Test Security - Can you SSH? (yes) - Can you access port 8080? (no, not allowed) - Can EC2 read S3? (yes, via IAM role)
Deliverable: Secure web server running on EC2
Project: Simple REST API on AWS
Option A: Easy (Elastic Beanstalk)
# FastAPI app
from fastapi import FastAPI
app = FastAPI()
@app.get("/hello")
def hello():
return {"message": "Hello from AWS!"}
# Deploy to Elastic Beanstalk (handles scaling)
eb create myappOption B: Serverless (Lambda + API Gateway)
def lambda_handler(event, context):
return {
"statusCode": 200,
"body": json.dumps({"message": "Hello from Lambda!"})
}
# Deploy via API Gateway (no servers to manage)Requirements: - ✓ Running API endpoint - ✓ Responds to HTTP requests - ✓ Deployed on AWS (not your laptop) - ✓ Documentation (how to deploy, how to use)
Weeks 25-27 Deliverable: - Deployed API on AWS - Public URL you can share - Demo (call the API, show response)
Interview Talking Point: > “I deployed an API to AWS using [Elastic Beanstalk/Lambda]. I chose [this option] because [reason]. The infrastructure is: [describe]. I used security best practices like [IAM roles/security groups]. The main learning was [cloud concept].”
Hackathon Project: Full-stack app (frontend + backend + database on AWS) Interview Readiness: Explain multi-tier architecture, scaling, databases
Days 1-2: Understand RDS - Managed databases (AWS handles backups, updates, scaling) - PostgreSQL, MySQL, MariaDB, Oracle - When to use: Structured data, complex queries, ACID guarantees
Days 3-5: Set Up RDS - Create RDS PostgreSQL instance (free tier) - Connect from your laptop (psql) - Create table, insert data, query - Understand: Backups, snapshots, failover
Days 6-7: Connect from EC2 - Modify security group (allow EC2 → RDS traffic) - Run queries from EC2 - Monitor performance
Deliverable: Working RDS instance accessible from EC2
Days 1-2: CloudWatch - Monitor: CPU, memory, disk - Logs: See what your app is doing - Alerts: Notify if problem
Days 3-5: Auto-Scaling - Set up: “If CPU > 80%, launch more EC2 instances” - Load balancer: Distribute traffic - Understand: Cost implications
Days 6-7: Cost Optimization - Calculate: How much does your setup cost? - Optimize: Use spot instances, reserved capacity - Monitor: Use Cost Explorer
Deliverable: Monitored, auto-scaling infrastructure
Project: Todo App on AWS
Architecture:
Internet
↓
Load Balancer
↓
EC2 (auto-scaling)
├── API server (FastAPI/Django)
└── Connects to:
├── RDS PostgreSQL (todos)
├── S3 (user files)
└── CloudWatch (monitoring)Or: Serverless Todo App
Internet
↓
API Gateway
↓
Lambda (auto-scales to 0 when idle)
├── Reads/writes to: DynamoDB
└── Uploads files to: S3Requirements: - ✓ Working API - ✓ Database (RDS or DynamoDB) - ✓ Deployed on AWS - ✓ Monitoring setup - ✓ Documentation
Weeks 28-30 Deliverable: - Full-stack app running on AWS - Architecture diagram - Cost breakdown - Demo
Interview Talking Point: > “I built and deployed a full-stack todo app on AWS. Architecture: API on Lambda connected to DynamoDB. Why Lambda? Serverless means I pay only for requests I handle, auto-scales, no servers to manage. Tradeoffs: cold starts (slight latency first call), can’t use heavy libraries. RDS would be better for [specific scenario]. I’m comfortable choosing based on requirements now.”
Hackathon Project: AI Chatbot on Android Interview Readiness: Full-stack AI + mobile integration
Days 1-2: Design API - Endpoint:
POST /chat (send message, get agent response) - Request:
{"message": "Hello"} - Response:
{"reply": "Hi! How can I help?", "tools_used": ["weather"]}
Days 3-5: Implement & Deploy
# FastAPI backend
@app.post("/chat")
def chat(message: str):
response = agent_loop(message)
return {"reply": response}
# Deploy to AWS (Elastic Beanstalk or Lambda)Days 6-7: Test & Document - Test from curl/Postman - Document API (what endpoints exist, what parameters)
Deliverable: Working agent API deployed on AWS
Days 1-2: Design UI - Chat-like interface (messages list) - Input field at bottom - Show thinking/loading indicator
Days 3-5: Implement
// ViewModel
class ChatViewModel : ViewModel() {
val messages = MutableLiveData<List<ChatMessage>>()
fun sendMessage(text: String) {
viewModelScope.launch {
try {
val response = agentApi.chat(text) // Call your backend
addMessage(ChatMessage(text, response.reply))
} catch (e: Exception) {
showError(e.message)
}
}
}
}
// Activity
class ChatActivity : AppCompatActivity() {
private val viewModel: ChatViewModel by viewModels()
private fun setupUI() {
viewModel.messages.observe(this) { messages ->
displayMessages(messages)
}
sendButton.setOnClickListener {
val text = inputField.text.toString()
viewModel.sendMessage(text)
}
}
}Days 6-7: Polish - Handle loading state - Handle errors - Clean UI/UX
Deliverable: Android app connected to agent API
Project: Full AI Assistant on Android
Features: - Chat with AI agent - Show thinking process (which tools used, why) - Save conversation history - Different agent modes (task assistant, tutor, etc.) - Offline fallback (cache responses)
Requirements: - ✓ Android app (MVVM) - ✓ Connects to backend API - ✓ Agent running on backend - ✓ Beautiful chat UI - ✓ Error handling - ✓ Works at hackathon (deployed, accessible)
Weeks 31-33 Deliverable: - Android app on GitHub - Backend API on AWS - Demo video (using app to chat with agent)
Interview Talking Point: > “I built a full-stack AI assistant: Android frontend, agent backend on AWS. Architecture: App sends message to API → Agent runs (calls tools) → Response sent back → App displays. Tricky part: handling latency (show thinking spinner), connection errors, keeping conversation coherent. This is like a real product—front-end, back-end, AI, cloud deployment.”
Hackathon Project: Your own ambitious project Interview Readiness: Walk through complete system from scratch to production
Days 1-5: Plan Your Capstone
Choose one:
A. AI-Powered Expense Tracker
Features:
- Take photo of receipt → AI extracts info
- Save to cloud database
- Analyze spending patterns with agents
- Android app to browse
- Web dashboard for reportsB. Smart Todo/Calendar Assistant
Features:
- Agent understands natural language ("remind me tomorrow")
- Coordinates calendar, todos, reminders
- Android app + web interface
- Multi-user (store in cloud)C. Content Recommendation System
Features:
- Users upload content
- Agents categorize, tag, summarize
- Recommendations based on preferences
- Android app + website
- Multi-agent coordinationDay 6-7: Create Architecture Diagram - Frontend (Android, web) - Backend (APIs, agents) - Database (RDS/DynamoDB) - Storage (S3) - Deployment (AWS)
Deliverable: Detailed architecture plan + tech choices explained
Days 1-7: Build Capstone - Frontend (Android app) - Backend (Agent APIs) - Database (RDS or DynamoDB) - Deployment (AWS) - Tests (unit + integration)
Focus on: - ✓ Complete feature set - ✓ Production-quality code - ✓ Thorough testing - ✓ Good documentation
Deliverable: Working full-stack app
Days 1-3: Final Polish - Fix bugs - Optimize performance - Clean up code - Write comprehensive README
Days 4-5: Create Demo - 5-10 minute video - Show all features - Explain architecture - Discuss decisions
Days 6-7: Deploy & Share - Ensure everything works - Share links (GitHub, deployed app) - Post on LinkedIn/Twitter (celebrate!)
Final Deliverable: - GitHub repo (well-organized, documented, tested) - Deployed app (AWS) - Demo video - Blog post or article explaining project
Sprint 1 (Week 3): Can build AI chatbot with tools Sprint 2 (Week 6): Can build multi-agent system Sprint 3 (Week 9): Can build production-grade bot Sprint 4 (Week 12): Can build specialized agents Sprint 5 (Week 15): Can build Android app Sprint 6 (Week 18): Can build data-driven Android app Sprint 7 (Week 21): Can build networked Android app Sprint 8 (Week 24): Can build professional Android app Sprint 9 (Week 27): Can deploy backend to AWS Sprint 10 (Week 30): Can build full-stack on AWS Sprint 11 (Week 33): Can build AI + Mobile integration Sprint 12 (Week 36): Can build complete product
Sprint 1-4 (Agents): ~12 weeks @ 10-15 hrs/week = ~50-60 hrs Sprint 5-8 (Android): ~12 weeks @ 12-18 hrs/week = ~70-90 hrs Sprint 9-10 (AWS): ~6 weeks @ 10-15 hrs/week = ~30-40 hrs Sprint 11-12 (Integration): ~6 weeks @ 15-20 hrs/week = ~45-60 hrs
Total: ~195-250 hours over 9 months - At 10 hrs/week: ~20-25 weeks (5-6 months) - At 15 hrs/week: ~13-17 weeks (3-4 months) - At 20 hrs/week: ~10-12 weeks (2-3 months) [ambitious but doable]
Monday-Wednesday: Learn concepts (read docs, watch videos, take notes) Thursday-Friday: Code (implement what you learned) Saturday-Sunday: Project work (hackathon prep or capstone)
Adjust as needed for class schedule.
By the end of 36 weeks, you should:
Remember: - Depth > breadth (really understand, don’t skim) - Build > watch (actually code, not just tutorials) - Iterate > perfect (ship, then improve) - Share > hide (GitHub, demos, talk about what you learned)
You’ve got this. 9 months is enough time to go from “learning” to “impressive portfolio.” Keep shipping, stay curious, enjoy building.