09 — study Or Assessment Conversion

Thirteen months of Java, ending in nothing, is a failure.

This file is the answer to the question: what does August 2027 actually look like? If the plan finishes and you are still doing the same work at the same place for the same money with the same team, then all that discipline built no leverage. That is the failure state you must not accept.

The plan needs an exit — an internal move at Zoho, a switch to another Indian product company, a role change from applied ML to backend, a promotion, or at minimum a public reputation shift so recruiters begin surfacing to you rather than the other way around. This file is how you make one of those happen.

Start reading this file at M10, not M13. The conversion has an eight-week runway.

Choose Your Track By M8

There are two realistic tracks. Pick one by the end of Month 8 (roughly Feb 2027). Do not pick both. Do not delay the choice past M8.

Track A — Internal move at Zoho

You stay at Zoho and move to a Java-heavy team. Advantages: no study loop, no notice period, no salary risk. Zoho is a large enough company that a lateral move within it is a real career change without any of the external friction.

Track B — External switch

You leave Zoho for another company. Advantages: bigger salary jump, cleaner reset, new codebase, possibly a title bump. Disadvantages: full study loop, notice period drama, culture-fit uncertainty.

Both are legitimate. The choice is about your appetite for risk in July-August 2027, and about how good the internal options at Zoho look after Phase 12.

Track A — Internal Move At Zoho

Who to talk to

By M10, you should know the answers to these questions. Start finding them now, at M1 — casually, over coffee, not as “I have a plan.”

  • Which teams at Zoho work on Java backend at scale? (Not just “uses Java” — uses Java for real backend work.) Common areas: Zoho CRM backend, Catalyst platform, Zoho Mail infrastructure, Zoho Analytics, Zoho Creator runtime.

  • Who are the principal / senior architects in those teams? Names, faces, LinkedIn profiles.

  • Which of them are approachable? Ask around. Every large engineering org has “the ones who mentor” and “the ones who don’t.” You want the first list.

  • Are any of them in Chennai? Do you share a cafeteria? Do you share a floor?

The internal move script

Internal moves in Indian product companies are relationship-first, not resume-first. Nobody moves teams because they filled out a form. They move because someone in the new team wants them.

So the sequence is:

  1. M1-M6: casually build the relationships. Coffee chats. Join their Slack channels. Comment on their internal wiki posts. Attend their brown-bag talks. You are not asking for anything. You are just present.

  2. M7-M9: start showing your Java work. Not “I am on a 13-month plan.” Just: “I’ve been getting more into JVM internals lately, wrote a benchmark on virtual threads over the weekend, curious if this maps to anything you’ve seen.” Send them your blog posts. Ask if you can shadow a code review.

  3. M10-M11: name the interest directly. “I’d like to move to a Java-heavier role. Is there a way I could contribute to your team — even a 10% loan, or an internal transfer.” One conversation, not five.

  4. M12-M13: formalize. Talk to your current manager. Talk to HR. Move.

This works. But only if steps 1-2 actually happen. If you skip to step 3 without the relationship, the answer will be “we don’t have any open roles right now.” With the relationship, the answer is “let me see what I can do.”

Internal move materials

  • Updated internal profile with the Java work highlighted.

  • Portfolio link (GitHub, blog).

  • A one-page document titled “What I bring to a Java backend team” — skills, projects, interests, gaps. Honest. This document is how a manager decides to fight for you across teams.

Track B — External Switch

The Indian Java + ML positioning

You have a rare combination: Java + applied ML. There are many Java engineers. There are many ML engineers. There are relatively few of both. Frame yourself accordingly.

Positioning options, ranked by rarity and value:

  1. ML platform engineer / MLOps — build the infra that ML models run on. Java + Python. Distributed systems. Feature stores. Model serving. Well-paid, high-demand. Companies: Flipkart, Swiggy, Zomato, Razorpay, Meesho, plus GCC branches of Google, Microsoft, Amazon.

  2. Backend engineer at ML-heavy company — the general backend that supports an ML product. Companies: Fractal, Tiger Analytics, Postman, Zeta, Cred.

  3. Java backend at product company — lots of options here. Zoho itself (external track means switching within the industry), Freshworks, Postman, Chargebee, Razorpay, PhonePe, InMobi.

Avoid: pure services companies (TCS, Infosys, Wipro) unless you are doing this for a specific pay or role reason. The Java work at those places is often maintenance of client codebases, not the growth-stage building you have been training for.

LinkedIn strategy for Track B

Start in M10, not M13. Recruiter algorithms need time to see you as active.

  • Headline: something like “Java backend + Applied ML | JVM internals, distributed systems | building at Zoho”. Specific, not generic.

  • About: three short paragraphs. What you build. What you’re getting into (Java at scale, JVM performance). Something human.

  • Featured: pin your best 3 blog posts, your capstone repo, and your resume PDF.

  • Posts: one per sprint from M10 onward. See 05_teach_to_learn.md for what to write.

  • Connections: connect to 30-50 people per month in the target companies. Include a one-line note (“Hi, saw your post on X, would love to connect”). Not spammy. Just human.

  • Recruiters: turn on “Open to Work” (recruiter-only visible) from M11.

Resume

One page. Two pages if you must. Rewrite it at the end of every phase from Phase 07 onward:

  • After Phase 07 (M8): first draft with new Java projects.

  • After Phase 09 (M10): add Spring/data work.

  • After Phase 11 (M12): add distributed systems capstone.

  • After Phase 12 (M13): final polish.

Each version should include one measurable outcome per bullet. “Built a REST API” is not a bullet. “Built a REST API serving 500 rps with p99 latency under 80ms, backed by Postgres and Redis, containerized and deployed to a single-node k8s cluster” is a bullet.

Salt for reality: nobody will read all your bullets. They will skim. Front-load the most impressive one.

Portfolio

GitHub profile README should be a real front page, not the default. Include:

  • Two-line “what I do” summary.

  • Pinned repositories, 6 max, arranged in order of impressiveness.

  • Links to blog, LinkedIn, resume.

  • Currently reading / working on section (updated quarterly).

Each pinned repo needs:

  • A real README with screenshots or output samples.

  • Working setup instructions (someone will clone it — recruiters do this).

  • A WRITEUP.md explaining what you learned and what you would do differently.

Mock studies — M10 To M13

One mock study per week from Month 10 through Month 13. That is roughly 16 mocks. This is the single most impactful part of the conversion phase, and the one most people skip because it is uncomfortable.

Where to do mocks

  • Pramp (pramp.com) — free peer-to-peer. Quality varies, but the practice is real. Do 6-8 of your mocks here.

  • studying.io — paid, higher quality, real engineers from FAANG-adjacent companies. Do 2-4 mocks here if budget allows. Recording feature is invaluable.

  • Friends in industry — the highest-value mocks. Ask 2-3 senior engineers you know (Zoho or otherwise) for one mock each. Buy them coffee. This is worth more than any paid platform.

  • Reverse recruiter first rounds — when recruiters reach out with roles you’re not sure about, take the first-round call as a mock. Low stakes, real practice.

Mock structure

One mock per week:

  • Week 1-4 (M10): DSA-focused. Rehearse the muscle.

  • Week 5-8 (M11): Java-specific + system design intro.

  • Week 9-12 (M12): system design + JVM/concurrency depth.

  • Week 13-16 (M13): full loops. Mixed rounds. Real study simulation.

After each mock, write a retro. What went well, what fumbled, what you’d say differently. This is the highest-quality lab notebook entry you will ever produce.

Salary Negotiation — Indian Market

When the offer comes, you will negotiate. Do not skip this because it feels awkward. The offer is a first draft. It is designed to be counter-offered.

Numbers to benchmark against

Before any negotiation, know your market rate. Sources, in order of reliability:

  • levels.fyi — has an India section. Most reliable for tech companies. Filter by role and years of experience.

  • AmbitionBox — India-specific, larger sample size, less curated. Good for services and mid-size product companies.

  • Glassdoor — useful for target companies specifically.

  • Blind (teamblind.com) — anonymous forum. India-specific threads exist. Take specific numbers with a grain of salt but the ranges are directional.

  • Your network — 3-4 friends in similar roles at similar companies, asked in confidence. The most accurate signal.

Build a spreadsheet before the offer comes. Rows: companies. Columns: base, RSU/equity, joining bonus, total comp year 1, total comp year 2. Know your minimum acceptable, target, and stretch numbers for each.

Rules

  1. Never accept the first offer. Even a token counter is expected. Not countering signals you don’t know your worth.

  2. Get the offer in writing before discussing salary. Verbal is not binding.

  3. Base salary is the number that compounds. RSUs are nice but they vest and vary. Push base up first. Bonuses second. Equity third.

  4. Have competing offers if possible. Even one competing offer changes the negotiation entirely. Try to run parallel processes so offers land within 2-3 weeks of each other.

  5. Do not bluff. If you say “I have another offer at X,” you should have it, or should be willing to produce it. Recruiters know your bluff rate.

  6. Ask for one week to decide. Not one day. Not one month. One week is normal.

  7. Use email for the actual numbers. “Thank you for the offer. Based on my research and other conversations, I was hoping for a base closer to X. Can we discuss?” Written, so nothing is lost.

Zoho internal-move negotiation

Internal moves have less salary lift than external switches, typically. If you do Track A, expect a 10-25% bump at most, sometimes bundled with a title change. If your Track A move comes with a smaller bump than a real external offer, use that as leverage — politely.

But also: the value of an internal move is not only salary. It is the trajectory. A move to a Java architect track at Zoho, even at 15% more base, may be worth more over 5 years than a Track B jump to a bigger salary in a role you don’t grow into.

The M13 Conversion Timeline

A week-by-week view of the last three months so nothing sneaks up:

Month 11 (May-Jun 2027):

  • W1: Track chosen. Track A or Track B.

  • W2: Resume v1 done. LinkedIn refresh done.

  • W3: First mock study.

  • W4: First LinkedIn post in the conversion cadence.

Month 12 (Jun-Jul 2027):

  • W1-W2: Capstone project finishing. Blog post about it.

  • W3-W4: Recruiter outreach begins (Track B). Manager conversation begins (Track A).

Month 13 (Jul-Aug 2027):

  • W1-W2: study rounds active. Mock studies weekly.

  • W3: Offer conversations. Negotiation.

  • W4: Decision. Signed. Retro post.

The Retro Post

At the very end — whether you took Track A, Track B, or extended the plan — write one final long-form post. Title something like “13 Months of Java: What I Learned, What I Got Wrong.” Publish it on your blog, cross-post to Medium and LinkedIn.

That post is the capstone of the plan. It closes the loop. It is also the thing that will resurface in Google searches for years and pay dividends long after the specific job change is behind you.

Make it honest. Include the valley. Include the failure modes you triggered. Include the compressed and extended timelines. The honest version is the one that will help the next person on this journey — and it is the one that will impress the strong hiring managers.

Previous: 08_health_burnout.md Back to: README.md