No Job 6 Months After Engineering. What Do You Actually Do Now?
Six months after your final semester exam, your placement status has gone from "looking" to "still looking" to a subject your family avoids mentioning at dinner. You have sent 200 applications. You have received either silence or automated rejection emails. Your friends who got placed through campus drives are posting LinkedIn updates about their first appraisal cycle while you are still refreshing Naukri for new listings. This article is not going to tell you to "keep applying" or "stay positive." It is going to tell you exactly what to do in the next 90 days to make yourself hirable — whether or not you have a campus placement pipeline.
The core problem with the "keep applying" advice is that it assumes your application profile is competitive and needs only volume. If you have applied to 200 jobs and received zero callbacks, your application profile is not competitive. Sending it to 200 more companies will produce the same result. The fix is not more applications. The fix is a better application — which means building evidence of technical competence that shows up in the first 30 seconds of a recruiter's scan of your resume.
Month 1: Delete Your Generic Resume. Build One Deployed Project.
The first month is not about looking for jobs. It is about building the one thing that will make recruiters look at you. A custom, deployed application — not a clone, not a tutorial follow-along — that solves an actual problem and is accessible at a live URL. This project becomes the centerpiece of your portfolio. Every subsequent application links to it. Every interview conversation references it. Every "what have you built?" question has a concrete answer.
Week 1: Choose and scaffold. Pick a project that is small in scope but complete in execution. Examples: a placement tracker for your college batch, a course review aggregator, an expense splitter for roommates. Avoid: e-commerce clones, social media clones, todo apps, weather apps. Scaffold the project with proper directory structure. Initialize Git. Write the first README draft with a project description. Week 2: Build the core feature. Implement the primary user flow end-to-end — frontend, backend, database. Focus on making one thing work completely rather than three things partially. Add authentication. Add error handling. Add input validation. Week 3: Deploy. Provision a free-tier VPS (Oracle Cloud or AWS). Configure Nginx as a reverse proxy. Set up PM2 for process management. Buy a ₹99 domain and point it to your VPS. Add SSL with Let's Encrypt. Week 4: Document and add to resume. Write a production-quality README: architecture diagram (Mermaid), API documentation, local setup instructions, live URL at the top. Replace your generic resume with one built around this project. Add a link to it in every application you send from now on.
Month 2: Open Source — The Validation Signal
Your deployed project proves you can build. An open source contribution proves that external developers reviewed your code and accepted it. This is the closest thing a fresher can get to a "reference check" without having worked anywhere. The strategy is simple and specific: find a popular open source library or framework you have used in your project. Filter its GitHub issues for the "good first issue" or "help wanted" tag. Pick one that is a documentation fix, a small bug fix, or a test coverage improvement — not a feature request. Fork the repo. Fix it. Open a PR. Follow the project's contribution guidelines exactly. If your PR gets merged, list it in your resume under "Open Source Contributions." If your PR gets review comments, address them politely — this is an even stronger signal because it proves you can receive and act on code review.
OPEN SOURCE CONTRIBUTIONS: WHAT TO DO AND HOW IT READS
| WHAT TO CONTRIBUTE | WHERE TO FIND IT | HOW TO LIST IT ON YOUR RESUME |
|---|---|---|
| Documentation fix (typo, missing example, unclear explanation) | GitHub issues with "documentation" or "good first issue" tags on popular repos | "Fixed documentation error in [Library Name] — merged PR #[number]." |
| Small bug fix (edge case, incorrect error message) | Issues tagged "bug" + "good first issue" on libraries you have used | "Resolved edge case bug in [Library] causing incorrect error handling — merged PR #[number]." |
| Test coverage (add tests for uncovered function) | Repos with low test coverage and open "test" issues | "Added unit tests for [function/module] in [Library] — merged PR #[number]." |
| Translation (localization strings) | Projects with i18n support and missing translations | "Contributed [Language] translations for [Library] — merged PR #[number]." |
Month 3: Targeted Cold Outreach to Startups
By month 3, you have a deployed project, a merged open source PR, and a resume that actually shows evidence of competence. Now you stop applying through job portals — where generic applications go to die — and start reaching out directly to hiring managers and founders at startups. The hit rate on cold outreach is low (5-10% response rate is good). But the conversion rate on responses is high because the people who reply are already interested enough to read your message.
Subject line: "[Target Role] candidate — Deployed [Project Name] at [Live URL]" — This is specific. It shows you built something. It includes a URL they can click. It does not say "fresher seeking opportunity" or any other generic phrase. Body: "Hi [Name], I recently built [project name], a [one-line description of what it does]. It is deployed at [URL]. My GitHub is [link]. I see that [Company Name] is hiring for [role]. I would love to apply — is there a specific person I should send my resume to, or would you prefer I submit through the portal? Thanks for your time." What this email does: It wastes zero words. It proves you can ship code (the deployed link). It asks a specific, low-effort question ("who should I send this to?") instead of a vague one ("can you help me find a job?"). It respects the recipient's time by being 4 sentences long. What to attach: Nothing. Do not attach a PDF resume to a cold email — it triggers spam filters and adds friction. Put the links in the body of the email. If they respond, then share your resume.
WHAT SERVICE COMPANIES ACTUALLY TEST — 2026
| COMPANY | APTITUDE ROUND | CODING ROUND | INTERVIEW FOCUS | MINIMUM CGPA |
|---|---|---|---|---|
| TCS | Numerical ability, logical reasoning, verbal | 1-2 coding questions (easy-medium DSA) | Programming basics, OOPs, DBMS, communication | 6.0 |
| Infosys | Quantitative, logical, verbal | 2 coding questions (Python/Java) | DS, algorithms, project explanation | 6.0 |
| Wipro | Aptitude + essay writing | 1 coding question | Technical + HR combined | 6.0 |
| Cognizant | Quantitative, logical, verbal | Automata (coding + debugging) | Technical basics, communication, flexibility | 6.0 |
If you have been unemployed for 6+ months and the financial pressure is mounting, the question is not "should I take a non-tech job?" — it is "which non-tech job causes the least career damage?" Acceptable: A non-tech job that leaves you 2-3 hours/day + weekends for portfolio building. Examples: remote data entry, evening BPO, content writing. The job pays bills while you build on the side. Dangerous: A non-tech job that consumes your mental energy completely. Examples: 12-hour shifts, field sales, restaurant work. These pay bills but leave you with zero capacity to build portfolio projects. You will still be doing them 3 years from now. Better than both: A paid internship in any technical adjacent field — QA, technical support, IT helpdesk. It pays less but keeps you in the tech ecosystem and builds resume-relevant experience. The bottom line: If you must take a non-tech job, treat it as strictly temporary — 6 months maximum — and set a hard deadline for when you will have a deployed portfolio ready to start applying for developer roles. The longer you stay, the harder the return becomes.