Internship Planner

• 

• 

• 

Inspiration

Finding an internship opportunity does not tell a student how to become ready for it.

For Indian undergraduates exploring internships abroad, the work is scattered across program pages, eligibility requirements, application documents, preparation resources, and university commitments. A student might discover an interesting research program and a company internship, but still struggle to answer:

• Which requirements actually apply to me?
• What information comes from an official source?
• What is missing or needs confirmation?
• Which foundations should I prepare?
• Which documents and external steps need an early start?
• Can I prepare for both opportunities without overwhelming my semester?
• What should I do this week?

An opportunity list answers only the first part of the problem. A generic study plan does not necessarily account for the selected programs, application dependencies, or an approaching exam week.

Internship Planner connects discovery to preparation. It brings together source-backed requirements, a limited sample of readiness evidence, and the student's available time to produce one coordinated plan.

What it does

Internship Planner is a working full-stack proof of concept for students exploring research and company internships abroad, with a preference for funded opportunities.

It guides students through a connected journey:

Interest exploration → editable preferences → live discovery → preliminary eligibility → readiness assessment → availability → preparation roadmap.

The result is not just a list of places to apply. It is a view of what the student needs to prepare, what remains uncertain, what can fit into their schedule, and what they can do next.

1. Explore interests without locking the student into a category

The journey begins with 12 short, app-authored work scenarios grounded in official descriptions.

Students can indicate interest, lack of interest, or uncertainty. The application uses those reactions to suggest work genres, related skills, and a Research/Company direction.

This is a preference-exploration exercise, not a personality test. The calculation is deterministic, and the student can change the resulting search preferences.

2. Discover opportunities beyond a fixed catalog

Students can customize topics, roles, locations, Research and Company tracks, remote preferences, funding preferences, citizenship, visa-support needs, preferred organizations, and keywords.

The server builds a bounded search plan from those preferences, searches public sources, reads candidate pages, and produces opportunity cards as results become available.

Students can continue with “Search more,” rather than being limited to a predefined list.

Saving, hiding, filtering, and selecting are separate actions. A student can bookmark an opportunity without making it a preparation target, and changing a display filter does not silently remove selected targets.

3. Understand what the sources support

Opportunity cards retain source references and supporting evidence.

The system distinguishes an official organizational source from a readable but unverified third-party source. A valid quote alone does not establish that a page belongs to the organization.

Extracted claims are checked against retrieved text. Unsupported facts are dropped or disclosed as gaps, and conflicting application-cycle information can prevent sources from being merged.

This matters because students should be able to distinguish “the source states this” from “the application does not know.”

Funding remains a preference, not a guarantee. Unknown funding or visa information is not turned into a positive claim.

4. Check preliminary eligibility

For selected targets, the application reads sources more deeply and compares supported eligibility conditions with the student's self-reported academic profile.

Depending on the captured requirements, this can include nationality, study year, degree, academic results, or other source-specific conditions.

The application distinguishes:

• Meeting the extracted criteria.
• Failing a supported criterion.
• Needing further confirmation.

Meeting extracted criteria does not mean every official condition has been captured.

The application also avoids inventing conversions between grading systems. If a grade scale is unclear or incompatible, the result remains unresolved.

5. Assess a limited sample of relevant foundations

A short readiness interview contains 6–8 questions with predefined rubric criteria.

Students can answer, skip questions, review their responses, and explicitly consent before their answer text is sent for assessment.

The assessment distinguishes demonstrated, partial, missing, and unassessed evidence. A skipped question remains “Not assessed”; it is not treated as demonstrated inability.

Coverage is shown separately from the result. A positive result describes the conceptual foundations that were tested—not complete professional readiness or specialist mastery.

6. Plan around university commitments

The student enters weekly preparation hours, exam weeks, a preparation buffer, timezone, and personal target dates where needed.

These inputs constrain the roadmap. They are not just notes attached to an otherwise unrestricted plan.

The application does not import a university calendar or infer availability from a timetable image. Students supply the planning constraints directly.

7. Get one shared preparation roadmap

The roadmap combines compatible preparation work while preserving program-specific requirements.

For example:

• Compatible core CV preparation can appear once.
• Program-specific CV checks remain separate.
• Different essays or statements remain separate.
• Recommendation requests include follow-up and estimated waiting periods.
• A required host or professor acceptance can become a dependency.
• Captured skill requirements can lead to relevant preparation or evidence-review tasks.

Research and Company views use the same allocation ledger. Selecting both tracks does not give the student two copies of their available hours.

Exam weeks have zero preparation capacity. Tasks that cannot fit are surfaced as risks rather than silently overbooked.

The overview identifies one feasible next step for the current week when one exists. Completing or reopening tasks updates the remaining plan.

An example journey

Consider an illustrative student exploring both a research internship and a company internship while preparing for university exams.

They first explore their interests, adjust their search preferences, and select two opportunities from live results.

Internship Planner prepares the selected sources, checks supported eligibility conditions, and identifies information requiring confirmation. The student then completes the short readiness interview and enters their weekly preparation hours and exam weeks.

The resulting plan can combine compatible preparation, keep target-specific documents separate, and account for dependencies that require waiting on another person.

Both targets must fit within the same available time. If the work cannot fit before a target date, the application makes that risk visible.

The student does not leave with only “learn these skills” or “apply before the deadline.” They leave with a sequence of preparation tasks and a feasible next action.

The recorded demonstration uses an illustrative persona and prepared answers. It is not evidence from a student outcome study.

How it was built

The application uses React and TypeScript for the frontend, with an Express backend and shared TypeScript planning logic.

TinyFish supports public-source discovery and reading. For supported applicant-tracking platforms, the application can also read structured public posting data directly.

Groq supports structured extraction, limited conceptual-question supplementation, and assessment against predefined rubrics.

The architecture deliberately separates AI interpretation from application decisions.

AI interprets; application logic checks and plans

AI helps interpret varied source material and written answers.

Deterministic logic handles:

• Interest-direction calculation.
• Preference ranking.
• Supported eligibility rules.
• Readiness aggregation.
• Task construction and scheduling.
• Capacity limits and dependencies.

The final roadmap is not free-form prose generated by an LLM.

Evidence is validated after extraction

A response is not trusted merely because it is valid JSON.

Local validation checks whether quoted evidence appears in retrieved text, whether the opportunity identity is supported, and whether facts appear to belong to the same program and application cycle.

When extraction is partially usable, the system can retain valid units while rejecting unsupported ones.

Scheduling uses a task graph

The scheduler builds a 26-week planning horizon from prepared opportunity facts, eligibility state, readiness evidence, availability, and completion history.

It accounts for shared tasks, program-specific tasks, dependencies, exam weeks, a prorated current week, and previously recorded completed hours.

Shared tasks use the earliest relevant target date of the opportunities they serve.

Official deadlines and personal targets remain distinct. When no usable official deadline exists, the application can assign a clearly labeled, editable personal target rather than invent an official date.

Personal progress stays browser-local

Personal progress is stored in the browser, while provider credentials remain on the server.

Readiness answer text is sent for assessment only after explicit consent. The application does not store academic profiles or raw interview answers on disk.

This is not a claim that assessment happens entirely on-device: external providers are involved, and no provider retention or deletion guarantee has been established.

How the Devpost Learn Skill Pack supported the build

The project includes scope.md, prd.md, spec.md, and a completed implementation checklist.

The planning work defined the user journey and its boundaries: live discovery, source preparation, preliminary eligibility, limited readiness assessment, and capacity-aware planning.

It also kept features such as automatic applications, admission predictions, timetable-image interpretation, and cross-device accounts outside the proof-of-concept scope.

The useful result of that boundary is a connected workflow rather than a collection of unrelated features.

Challenges

Keeping uncertainty visible

Missing funding information, incomplete eligibility conditions, an unknown deadline, and an unassessed skill are different problems.

Treating all of them as confident answers would make the interface simpler but the plan less trustworthy. The application needed distinct states and next steps for each.

Connecting source material to useful tasks

Internship pages vary in structure and detail. Some provide clear document requirements but little information about specialist skills.

The planner therefore has to work with the evidence available. When a source does not support a detailed skill-preparation plan, the application can surface source-review or application-administration tasks rather than fabricate requirements.

Sharing preparation without duplicating time

Some work is reusable across targets, while other work is program-specific.

The scheduler needed to combine compatible tasks without collapsing distinct requirements—and allocate everything against one time budget across both tracks.

Handling partial model failures

Structured model output can contain useful information alongside invalid values.

The extraction pipeline uses local validation and smaller-unit recovery where possible so that one malformed item does not automatically discard every usable fact from a page.

Preserving assessment integrity

The server retains the trusted question pack and rubric rather than accepting authoritative grading criteria from the browser.

Assessment results are associated with the submitted answers. Editing answers invalidates the previous assessment instead of silently carrying old results forward.

Accomplishments

The proof of concept completes a recorded, real-provider journey from interest exploration and discovery to a shared preparation roadmap.

The demonstration includes:

• A live search.
• One Research target and one Company target.
• Academic-profile entry and source preparation.
• A readiness assessment.
• Weekly availability and an exam week.
• Both track timelines.
• Task completion.

At the last recorded verification, 176 tests passed, along with type checking, data validation, and the production frontend build.

The real-provider recording captured no browser page errors during that run. That supports the demonstrated journey, not a guarantee that every future provider request will succeed.

What we learned

The central lesson was that trustworthy planning requires more than plausible recommendations.

A useful system needs to distinguish:

• A source-supported fact from an interpretation.
• A preference match from a selection probability.
• Meeting extracted criteria from complete eligibility.
• A skipped answer from a failed assessment.
• A personal target from an official deadline.
• Work that fits from work that is at risk.

Another lesson was that deterministic planning and AI interpretation serve different purposes. AI can help interpret messy information, while explicit scheduling rules make capacity, dependencies, and trade-offs easier to inspect and test.

Finally, completing the whole journey exposed issues that isolated screens would not: whether selected targets survive filtering, whether changed answers invalidate old results, and whether both tracks really share one budget.

Current limitations

• Bounded discovery cannot find every relevant internship or capture every requirement.
• Not every displayed opportunity is fully funded.
• Eligibility checks are preliminary and limited to supported extracted conditions.
• The readiness interview samples conceptual foundations, not overall employability or practical mastery.
• Effort estimates, waiting periods, and availability distribution are application assumptions.
• Live operations depend on source accessibility, provider availability, and remaining budgets.
• Progress is browser-local, with no accounts or cross-device synchronization.
• The backend is a single-process proof of concept, not production-scale infrastructure.

What's next

The next priority is student testing: whether users understand the evidence and uncertainty labels, whether the tasks are useful, and whether the resulting workload is manageable alongside university.

Further work would focus on improving requirement coverage, evaluating assessment usefulness, and refining scheduling estimates using that feedback.

The goal remains focused: help students move from discovering an opportunity to knowing what they can realistically do next.

Built With

• express.js
• groq
• node.js
• playwright
• pnpm
• react
• tinyfish
• typescript
• vite
• vitest
• zod