Infosys Fresher Experience: First 90 Days on a Project

The Mysore training is talked about extensively. The placement process is documented in detail. But the experience of actually being on a project at Infosys for the first time, after training ends and the real work begins, is something most guides skip entirely. It is also the period that determines more about a fresher’s first two years at Infosys than any other single phase.

Infosys Fresher First 90 Days on Project

The first 90 days on a project at Infosys are genuinely different from anything that came before: different from college, different from the placement process, different even from Mysore training. The work is real, the clients are real, the consequences of mistakes are real, and the learning curve is steeper than most freshers anticipate. At the same time, the support structures are also real, the learning opportunities are enormous, and the experience of contributing to actual systems used by actual businesses is one of the most professionally formative things that happens in a technology career.

This guide covers the first 90 days in genuine detail. Not a polished corporate narrative about how exciting the first project is, but an honest account of what happens: the confusion of the first week, how to read a codebase you have never seen before, how to communicate with your team lead and the client, how assessments and performance work, what good first-90-days performance actually looks like versus what most freshers deliver, and the specific habits and practices that separate strong first-year performers from average ones.

The Transition From Mysore to Project: What Changes
The Project Allocation Process
Week 1: Orientation and the Onboarding Fog
Understanding Your Project: Codebase, Architecture, and Context
Your First Task: What to Expect and How to Handle It
Working With Your Team Lead and Manager
Client Communication: What It Looks Like as a Fresher
Agile and Project Management: How Work Is Organized
Common Mistakes Freshers Make in the First 90 Days
What Strong First-Year Performance Actually Looks Like
Managing Remote Work and Hybrid Arrangements
The First Appraisal: What It Evaluates and How to Prepare
Building Relationships That Matter in the First 90 Days
Technical Growth During the First Project
Frequently Asked Questions

The Transition From Mysore to Project: What Changes

Mysore training and project work are fundamentally different experiences, and the transition between them catches many freshers off guard.

The Structure Changes:

Mysore has a fixed daily schedule: classes from 8 or 9 AM to 5 or 6 PM, assessments on defined days, a clear curriculum to follow, and a visible endpoint. Every day is similar in structure.

Project work has no such predictability. Some days are spent in back-to-back meetings. Some are spent coding uninterrupted for six hours. Some involve debugging a production issue with urgency. The variety is not just in content but in the nature of the day itself.

The Accountability Changes:

In Mysore, the primary accountability is to your own learning outcomes and the assessment scores. Failing an assessment is significant but the consequence is academic.

On a project, accountability extends to the team and ultimately to the client. A bug you introduce may affect production. A commitment you make to complete a task by Friday has consequences if not met. The shift from personal accountability to team accountability is real and requires adjustment.

The Learning Mode Changes:

Mysore learning is structured and delivered: material is presented, concepts are explained, exercises are provided. You follow a curriculum.

Project learning is unstructured and emergent: you learn what you need to learn to complete the current task. No one hands you a syllabus. You discover what you do not know by encountering tasks you cannot complete without that knowledge.

This mode of learning is more demanding cognitively (you must identify your own knowledge gaps) but also more efficient (you learn exactly what is relevant to what you are working on).

The Social Context Changes:

Mysore builds camaraderie through the shared intense experience of training and assessment. The cohort of 200 to 500 people who went through training together has a special bond from that shared pressure.

The project team is smaller, more diverse in experience level (you may be the only SE-level person on a team of SSEs and TAs), and more professionally complex. The relationships are more instrumental and also more durable: the team lead who mentors you in your first project has more impact on your career than any Mysore contact.

The Project Allocation Process

Understanding how you get allocated to a project removes the anxiety of uncertainty and helps you prepare appropriately for whatever assignment arrives.

The Timeline:

After Mysore training and stream allocation, the project deployment process begins. The timeline varies significantly: some freshers are deployed within two to four weeks of completing training. Others wait one to two months in a holding state, sometimes called the “bench,” before deployment. The bench period is not a negative signal; it reflects the timing of project openings relative to the batch’s completion of training.

What Determines Your Allocation:

Project deployment is a matching process between:

The skill set and stream you demonstrated in Mysore training (Java development, testing, data analytics, etc.)
The open requirements in Infosys’s project portfolio at the time of your deployment
Your geographic preference (noted during training, honored to the extent possible but not guaranteed)
In some cases, your performance in specific technical assessments that align with particular project requirements

The deployment decision is primarily business-driven, not preference-driven. A Java developer may be deployed on a banking application, a manufacturing system, or a retail platform. The industry of the client is not typically negotiable at the fresher stage.

The Bench Experience:

If you are on the bench after Mysore, the typical experience is:

Continuing self-study through Lex and Infosys training platforms
Participating in online certification preparation (sponsored by Infosys or self-directed)
Receiving a regular salary (the bench period is paid time at Infosys)
Periodic check-ins with the Resourcing Management Group (RMG) representative assigned to your unit

The bench period is an opportunity to strengthen the skills most in demand in the stream you were allocated to. Java developers on the bench should use the time to deepen their Spring Boot and REST API skills. Data stream freshers should practice SQL and data processing. This preparation directly improves the quality of the first project contribution.

Receiving the Deployment Email:

The project deployment notification typically comes through Infosys email from the RMG team. It specifies: the project name (often a codename or client-code name), the technology stack, the reporting location (office or work from home), the team lead’s name and contact, and the date to report.

Read the deployment email carefully, respond to confirm by the specified date, and immediately reach out to the team lead to introduce yourself and understand any pre-deployment preparation they recommend.

Week 1: Orientation and the Onboarding Fog

The first week on a project at Infosys is confusing in a specific way: there is a lot of new information, most of it in unfamiliar context, and the expected output from you is low enough that it is tempting to drift through the week without actively engaging. The freshers who perform strongly in their first quarter typically attack this first week rather than surviving it.

The Practical Setup:

The first day involves administrative setup: getting physical or VPN access to the project’s systems, receiving project-specific accounts, being added to email distribution lists and team communication channels (Slack, Microsoft Teams, or Infosys’s internal collaboration tools), and meeting the team members.

This setup process is typically fragmented across multiple days because different access requests are approved by different systems with different SLAs. Accept that the first two to three days will involve a lot of waiting for access approvals and use this time productively.

The Team Introduction:

Your team lead will introduce you to the team, either in a team meeting or one-on-one with each member. Pay attention to the roles: who is the module lead for the component you will be working on, who is the testing lead, who handles client communication, who manages the release process. Understanding the team structure and who is responsible for what prevents misdirected questions and helps you find the right person for each type of guidance.

The Project Context Dump:

In the first week, you will receive a large amount of context about the project: the client’s business, what the application does, the current project phase, the team’s current sprint or project stage, and what the immediate priorities are. This information comes in an informal stream through meetings, documents, email threads, and conversations.

The mistake most freshers make is passive reception of this context. The correct approach is active organization: after each meeting or document review, write down in your own words what you understood. Bring a physical notebook or a dedicated digital note-taking setup for this purpose.

Questions You Should Answer in Week 1:

By the end of the first week, you should have answers to the following questions:

What does this application do, in one sentence, from the client’s business perspective?
What technology stack is it built on?
Where is the codebase? (Repository URL and access)
How do I set up the local development environment?
What is the development workflow? (How do I create a feature branch, run tests, submit a pull request?)
What is the current sprint goal or immediate project priority?
Who do I go to for technical questions?
Who do I go to for process questions (task assignment, time logging, etc.)?
What does a typical working day look like for the team?

Do not leave these questions unanswered because you were afraid to ask. Asking these basic orientation questions in week one is appropriate. Asking them in week six reveals a lack of engagement with the onboarding process.

The Documentation Review:

Most mature projects maintain documentation: architecture diagrams, database schemas, API specifications, runbooks, and test plans. Ask your team lead where this documentation lives and spend time reading it in the first week. Even if you do not fully understand it yet, the exposure creates context that makes subsequent technical conversations significantly more comprehensible.

Understanding Your Project: Codebase, Architecture, and Context

Reading a codebase that you did not write is a professional skill that is rarely taught explicitly and that most freshers underestimate the difficulty of. The approach matters enormously.

Start With the Entry Points:

Every application has entry points: the main class in a Java application, the routes file in a web application, the data sources in an analytics pipeline. These entry points are the doors through which you understand how the application is organized.

Ask your team lead where the main entry points are. Do not start by randomly opening files; start by understanding the outermost layer of the application and work inward.

Follow a Request:

One of the most effective ways to understand a web application’s architecture is to trace a single HTTP request from when it arrives at the server to when the response is returned. Ask a team member “if a user submits an order, what path does that request take through the application?” and then read each class and method in that path in sequence.

This trace gives you: the controller layer, the service layer, the repository layer, the database interaction, and any external API calls or event publishing. From this single trace, you understand the application’s primary architecture pattern.

The Database Schema:

Understanding the database schema is as important as understanding the code. In most IT services projects, the database schema has accumulated over several years and contains the history of the business rules the application enforces. Asking for an entity-relationship diagram or generating one from the database directly gives you a map of the domain model that the code is built around.

Run Everything Locally First:

Before you touch any code in a non-local environment, get the application running on your local machine. This means: checking out the repository, running the setup script or following the README, starting the application, and seeing it respond to a test request. This baseline of “it works on my machine” is essential before making any changes.

Many freshers skip this step because it seems tedious or because they are eager to start on their first task. The consequence is that when their first code change does not work, they cannot tell whether the problem is in their change or in the base application setup. Always establish the working baseline first.

Use the Version Control History as Documentation:

The Git commit history of a project is a form of documentation. Reading recent commits reveals: what was recently changed, why (from commit messages), and who made the changes. Reading the commits associated with a file you are trying to understand shows how that file has evolved and what business rule changes it reflects.

Ask your team lead for a walkthrough of the repository structure and the current major feature branches. This 30-minute conversation provides orientation that would take days to acquire independently.

Your First Task: What to Expect and How to Handle It

The first task assigned to a fresher at Infosys is almost never the most technically demanding thing the team is working on. This is intentional. Your team lead does not know your actual technical proficiency yet; the Mysore assessment scores provide an indication but not a guarantee. The first task serves as a calibration.

Typical First Tasks:

Bug fixes with clear reproduction steps: “When the user inputs a date in the format DD/MM/YYYY instead of MM/DD/YYYY, the application throws a NullPointerException. Fix this.” This task requires reading code, understanding the relevant component, making a targeted change, testing the fix, and submitting the change for review.

Minor feature additions: “Add a search filter by department to the employee list page.” This requires understanding how existing filters work, implementing the new filter with the same pattern, adding tests, and getting it reviewed.

Documentation updates: “The API documentation is outdated and does not reflect the new endpoint signatures. Update it.” This requires reading the code to understand the current API behavior, updating the documentation accurately, and getting a review.

These tasks have several things in common: they are small enough to be completable in one to three days, they require understanding the codebase to complete correctly, they produce visible output that can be reviewed, and they provide the team lead with a data point about how you work.

The Right Approach to the First Task:

Before writing any code:

Read the task description carefully.
Reproduce the bug or understand the feature specification completely before touching code.
Identify which parts of the codebase are relevant.
Read those parts carefully.
Form a hypothesis about what change will address the task.
Confirm your understanding with the team lead before implementing: “I believe the issue is in the DateParser class’s parse() method at line 47. I plan to add a null check before the parsing operation. Does this sound correct to you?”

This confirmation step, which takes five minutes, prevents the scenario where you spend two days implementing the wrong solution.

After Writing the Code:

Test your change thoroughly: the specific case that was broken should now work, the adjacent cases (similar but not identical inputs) should still work correctly, and the edge cases (empty input, maximum length input, null input) should be handled gracefully.

Write tests for your change if the project has a testing framework: unit tests for the specific function changed, integration tests if the change affects system behavior end-to-end.

Document the change in the commit message: “Fix NullPointerException in DateParser when month/day format is used. Added null check before parsing operation and added validation for expected date format.”

Submit the code for review through the team’s pull request or code review process, not by sending a file or saying “I fixed it, please merge.”

Handling Code Review Feedback:

The code review process is where the real learning from the first task happens. Your first pull request will likely receive feedback: “use a try-catch instead of a null check here,” “add a comment explaining why this format check is needed,” “this variable name is not descriptive enough.”

Receive this feedback without defensiveness. The reviewer is not criticizing you as a person; they are improving the code. Address every piece of feedback, ask clarifying questions if any comment is unclear, and thank the reviewer for their time. A positive first code review interaction establishes a collaborative dynamic that benefits the entire working relationship.

Working With Your Team Lead and Manager

The relationship with the team lead is the single most important professional relationship in the first 90 days. Understanding how to build and maintain it well has a direct impact on the first appraisal, the quality of the tasks assigned, the guidance available, and ultimately the career trajectory.

What the Team Lead Is Responsible For:

The team lead is responsible for: assigning work to the team, ensuring quality standards are met in the team’s deliverables, providing technical guidance, managing escalations within the team, conducting or participating in code reviews, and representing the team in broader project discussions.

For freshers specifically, the team lead is also the person who writes the first performance review and who has the most influence on the appraisal rating.

What the Team Lead Needs From You:

Predictability: when you commit to completing a task by a certain date, the team lead plans around that commitment. Communicating proactively when you are behind (not at the deadline but before it) is more valuable than perfect delivery.

Transparency about blockers: if you are stuck on something for more than two to three hours, communicate it rather than continuing to struggle silently. “I have been trying to understand how the authentication middleware works for the past few hours and I am not making progress. Can you point me to the relevant files or documentation?” is an appropriate communication.

Minimal supervision required: the team lead is managing multiple people and delivering to the project. A fresher who requires constant check-ins and follow-ups creates a management overhead that leads to frustration. A fresher who is self-directed, communicates status proactively, and asks targeted questions is a relief.

The Check-in Rhythm:

Establish a regular check-in with your team lead: a brief daily or every-other-day touchpoint where you report current status, upcoming deliverables, and any blockers. Many agile teams have a daily standup that serves this function. If your team does not, create this rhythm informally.

The check-in should not exceed 10 to 15 minutes. It is about alignment, not discussion. Detailed technical discussions happen separately when there is a specific topic.

The Manager (DM or Senior TL):

Above the team lead is the manager, typically a Delivery Manager or Senior Technology Lead at Infosys. The manager’s direct interaction with freshers is less frequent than the team lead’s but still significant.

The manager is typically present in project status meetings, in performance discussions, and occasionally in technical design discussions. The fresher’s goal in interactions with the manager is to be visible in a positive way: making insightful comments in meetings (not talking for the sake of talking, but contributing genuinely), being prepared when asked about the status of your tasks, and demonstrating that you understand the project’s context beyond your own narrow work area.

What a Team Lead Means When They Say “Take Ownership”:

The phrase “take ownership” is used frequently in IT services contexts and means something specific. It does not mean “be available at all hours.” It means: understand your task completely, solve problems that arise without waiting to be told what to do, communicate about your work proactively, and treat the quality of your deliverable as a personal responsibility rather than a checkbox to be completed and handed over.

A fresher who takes ownership of a task ensures the code they submit is genuinely tested, the documentation is updated, the edge cases are handled, and the change request is fully closed rather than partially done and waiting for someone else to notice the incomplete pieces.

Client Communication: What It Looks Like as a Fresher

The client is often a mysterious presence in the first 90 days: referred to frequently, involved in important decisions, but not directly visible to the newest team members. Understanding the client interaction model at the fresher level prevents surprises and prepares you for the client-facing roles that come later.

The Client in IT Services:

In IT services, the client is the organization that has contracted Infosys to build, maintain, or transform a technology system. The client has its own employees who interact with the Infosys team: business analysts who define requirements, project managers who track delivery, technical architects who review design decisions, and sometimes business users who test the software.

The Infosys side typically mirrors this structure: there are Infosys business analysts, Infosys project managers, and Infosys technical leads. The fresher SE is typically on the delivery execution side of this model.

Direct Client Interaction as a Fresher:

In the first 90 days, most freshers have limited direct client interaction. Work flows through the team lead, who receives requirements, clarifies ambiguities with the client, and assigns tasks to the team. The fresher’s work output is reviewed by the team lead or senior team members before it goes to the client for review.

This indirect model protects the client relationship from the potential quality variability of very new team members, and it protects the fresher from client interaction complexity before they understand the project well enough to participate effectively.

However, some Infosys projects do involve direct client interaction for freshers, particularly in Agile delivery models where the entire team participates in sprint reviews with the client. If your project does this, preparation is important.

What to Do When You Are in a Client Meeting:

Before the meeting: review the agenda if one was sent. Know the status of anything you are responsible for.

During the meeting: listen more than you speak in the first few months. When you do speak, make sure you are saying something accurate and relevant, not filling silence. If you do not know the answer to a question that is directed to you, say so clearly: “I will need to check on that and get back to you by [specific time],” then actually follow through.

After the meeting: take any action items assigned to you and complete them before the committed deadline. Follow up on any “I will check and get back to you” commitments within the promised time.

The most common fresher mistake in client meetings is agreeing to timelines or scopes without consulting the team lead first. Never commit to a delivery date or scope to the client without confirming with the team lead that the commitment is feasible.

Written Client Communication:

Professional written communication to clients follows specific conventions: formal tone, specific subject lines, complete information (context for what you are asking about, not just the question), and a clear call to action. The Infosys business communication training at Mysore covers these conventions. Apply them in actual client emails from the first interaction.

When in doubt about whether to send an email or what to say, draft it and show it to the team lead for review before sending. This is not a sign of incompetence; it is professional judgment about the importance of getting client communication right.

Agile and Project Management: How Work Is Organized

Most Infosys projects use Agile methodology, typically Scrum. Understanding how Agile works in practice (not just the theoretical model from Mysore training) helps freshers participate effectively from day one.

The Sprint Cycle:

A sprint is a fixed-duration work cycle, typically two weeks, during which the team commits to completing a defined set of tasks. The sprint cycle includes:

Sprint Planning: the team selects tasks from the product backlog for the upcoming sprint. The team lead and more senior team members typically drive this. As a fresher, your role is to understand the tasks assigned to you and raise questions about anything unclear.

Daily Standup: a brief 15-minute meeting where each team member reports what they did yesterday, what they plan to do today, and any blockers. Keep this concise. “Yesterday I completed the DateParser bug fix and submitted the PR. Today I will start on the customer filter feature. No blockers currently.” is the right format.

Sprint Execution: the two-week period of actual development work. This is where most of the fresher’s time is spent.

Sprint Review (Demo): at the end of the sprint, the completed work is demonstrated to stakeholders including the client. As a fresher, you may be asked to demonstrate work you completed.

Sprint Retrospective: the team discusses what went well and what could be improved. Freshers are expected to participate genuinely, not just agree with everything that senior team members say.

JIRA or Equivalent Tracking:

Almost every Infosys project uses JIRA (or a similar tool like Azure DevOps or ServiceNow) for task tracking. Each task (user story, bug, task) is a ticket in the system. Your work is tracked through: the ticket assigned to you, the status updates you make as you progress, the time logged against the ticket, and the comments and code review links attached to it.

Discipline in JIRA updates is a professional responsibility. Update your tickets when you start work, when you make progress, when you encounter blockers, and when you complete. A team lead who looks at JIRA and sees all tickets in “In Progress” for two weeks without updates does not know what the team is actually doing.

Estimating Your Work:

Sprint planning involves story point estimation or hour estimates for each task. As a fresher, your estimates will initially be inaccurate because you do not have calibration for how long things take in this codebase. This is expected and normal.

The discipline to build: when you are given a task, form your own estimate before asking for help with estimation. “I think this will take two days, but I am not sure about the database migration step. If that is straightforward, two days. If it involves complex data transformation, possibly three days.” This kind of reasoned estimate, even if off, shows engagement with the problem and builds estimation skill over time.

Handling Scope Creep in Your Task:

Sometimes a task assigned to you expands as you work on it: fixing the bug reveals three other related bugs, or implementing the feature requires a database schema change that was not anticipated. When this happens:

Do not silently absorb the expanded scope and delay your committed delivery without communicating. Communicate the discovery to the team lead immediately: “The bug fix also revealed two related issues in the same component. Should I fix all three in this ticket or create separate tickets for the other two?”

This kind of proactive communication demonstrates awareness of project management realities and prevents the surprise of a task taking three times as long as committed.

Common Mistakes Freshers Make in the First 90 Days

This section documents the specific mistakes that are consistently made by freshers in their first project at Infosys, along with the specific corrections.

Mistake 1: Waiting to Be Told What to Do

Many freshers treat the project like training: they wait for tasks to be assigned and do not seek out the next thing to work on when a task is complete. This passive orientation is the single most common indicator of a below-average first appraisal.

The correction: when you complete a task, do not wait to be given the next one. Look at the sprint board for unassigned tasks in your skill area, identify one you could take on, and ask the team lead: “I finished the DateParser fix. I see there is a filter feature ticket unassigned in the sprint. Should I pick that up?”

Mistake 2: Not Asking for Help When Genuinely Stuck

The opposite of Mistake 1 is struggling silently for hours or days on a problem that a five-minute conversation with the team lead would resolve. Many freshers are afraid of appearing incompetent by asking for help. This fear produces worse outcomes than asking.

The correct mental model: asking for help on a genuinely difficult or unfamiliar problem is not a sign of incompetence. It is a sign of professional judgment about when individual effort has hit diminishing returns and collaborative input would be more efficient. The rule of thumb: if you have spent more than two to three hours on the same blocker without progress, it is time to ask.

Mistake 3: Not Reading the Error Message

This sounds trivial but is one of the most common technical mistakes: encountering an error and immediately asking the team lead or searching Google without first reading the error message carefully. Error messages in Java, SQL, and most modern frameworks are specific and informative. Reading the complete error message and stack trace before escalating or searching often reveals the answer directly.

Mistake 4: Not Writing Tests

Freshers often skip writing tests for their code, either because they were not explicitly asked or because they are not sure how the test framework works in the project. This creates technical debt and signals to reviewers that the code is not fully owned by the developer.

In the first week, ask about the project’s testing framework and conventions. Review the existing test files to understand the pattern. Include at least a basic unit test in every substantive code change you submit.

Mistake 5: Over-Engineering the First Solution

The first task assigned is not an opportunity to showcase the most sophisticated solution you can design. It is an opportunity to demonstrate that you can solve the stated problem correctly, reliably, and with clean code. Many freshers over-engineer their first contributions: introducing unnecessary abstractions, refactoring unrelated code, or implementing a more complex solution than the problem requires.

Scope the solution to the problem. If refactoring an adjacent method would improve the code but was not part of the task, note it in the code review comment rather than including it in the change: “Out of scope for this PR, but I noticed the validateDate method in line 112 could be simplified. I can raise a separate ticket for that.”

Mistake 6: Treating Process as Optional

The project has a defined process for code changes: create a branch from the correct base, follow naming conventions, run specific tests before submitting, use the designated code review tool, and get two reviewers before merging. Freshers sometimes bypass parts of this process when they are in a hurry or when it seems unnecessarily complex for a small change.

Process bypassing creates problems for others: review is missed, tests are not run, deployments break. Treat the process as mandatory regardless of the size of the change.

Mistake 7: Being Invisible in Meetings

In daily standups and team meetings, freshers sometimes say as little as possible to avoid drawing attention to themselves. This becomes a problem when no one knows what you are working on or how you are progressing. The standup is not an opportunity to be invisible; it is a professional communication obligation.

The correct approach: prepare your standup update before the meeting. Thirty seconds of thought produces a clear, specific update. “Yesterday I completed the filter feature tests and submitted for review. Today I will start the export functionality. No blockers.” This is professional, visible, and complete.

Mistake 8: Not Following Up on Action Items

In meetings, action items are assigned: “Can you check on the database migration script and get back to us by Thursday?” Many freshers agree to these action items and then forget them or deprioritize them. Missing an action item in a client-visible project damages the team’s credibility with the client.

Keep a running list of all action items you commit to, with deadlines. Check this list daily. Complete every item by the committed deadline or communicate proactively if the deadline needs to change.

What Strong First-Year Performance Actually Looks Like

Most guides describe what freshers should do without describing what the output of doing those things correctly actually looks like to the people evaluating you. This section provides that picture.

By the End of Month 1:

A strong performer at the end of month one has: fully set up the local development environment and can build and run the application independently, completed one to two bug fixes or minor feature additions that have been merged into the main codebase, understands the primary data model of the application, and has a clear mental map of the team structure and their own role within it.

An average performer at the end of month one has: spent significant time on environment setup that is still not complete, is still asking basic questions about the application that could have been answered by reading the documentation, and has not yet submitted any code for review.

By the End of Month 2:

A strong performer at month two has: consistently completed assigned tasks within the agreed timeline, received positive code review feedback (or has acted on feedback promptly and without defensiveness), contributed meaningfully to sprint planning by asking clarifying questions and providing reasonable task estimates, and taken initiative on at least one thing beyond the assigned tasks (identified a documentation gap and filled it, or raised a testing gap that the team was not aware of).

An average performer at month two is still primarily in reactive mode: waiting for tasks, completing them with quality issues that require multiple rounds of review, and not yet demonstrating any independent initiative.

By the End of Month 3:

A strong performer at month three is a reliable team contributor: tasks assigned to them get completed on time, at quality, with appropriate tests and documentation. They require minimal supervision. They actively participate in team discussions. The team lead would say, if asked, that the fresher is contributing genuinely to the team’s delivery velocity, not just learning.

This is the state that justifies a strong appraisal rating and sets up the first promotion timeline at the 18 to 24-month mark rather than later.

The Specific Behaviors That Drive Strong Ratings:

Consistency: deliver what you commit to, every time. One missed deadline is understandable; a pattern of missed deadlines is a rating killer.

Quality ownership: code you submit should work correctly. Not nearly correctly. Not “it mostly works.” The job is done when it is fully done.

Communication transparency: the team lead should never be surprised by the status of your tasks. Either the task is on track (and you communicate this in standup) or it is at risk (and you communicate this immediately when the risk appears).

Learning velocity: each new task should be completed faster than the previous equivalent task. The team lead observes whether the fresher is building skill and knowledge, not just executing each task from scratch.

Professional maturity: handling code review feedback without defensiveness, speaking honestly about blockers rather than hiding them, and acknowledging mistakes when they happen rather than assigning blame elsewhere.

Managing Remote Work and Hybrid Arrangements

Many Infosys projects operate in hybrid or fully remote modes, which creates a specific set of challenges for freshers who have never worked professionally before.

The Home Office Discipline Problem:

The Mysore campus provides structure: fixed hours, physical presence, visible peers and instructors. Remote work at home provides none of these structural cues. For freshers who have limited experience with self-directed work, the transition to remote work can lead to: inconsistent working hours, difficulty concentrating in a home environment, reduced visibility to the team, and delayed responses to communications.

The specific habits that make remote work effective:

Fixed working hours: work the same hours every day, as close to the team’s standard hours as possible. This is not about surveillance; it is about availability and rhythm.

A dedicated workspace: even if it is just a desk in a corner of a room, having a specific place that is “work” psychologically helps the transition between personal and professional modes.

Communication overcommunication: in a physical office, your presence communicates availability and activity. In remote work, you must substitute deliberate communication for this passive presence signal. Update JIRA tickets more frequently, respond to messages promptly, and send a brief daily status note to your team lead if the project does not have a standup format.

Video in meetings: keeping video on during team and client meetings signals engagement and builds the human connection that text-only remote communication lacks.

The New Joiner in a Remote Team:

Starting a new job remotely is harder than starting in person because the informal interactions (conversations at the coffee machine, seeing a colleague stuck and offering to help, overhearing a discussion that is relevant to your work) do not happen naturally. Remote freshers must create these interactions deliberately.

Schedule brief one-on-one video calls with each team member in the first week to introduce yourself and understand their role. Ask if you can pair with a senior team member for a session while they work on something related to your area. These deliberate informal connections substitute for what would happen organically in a physical office.

Managing Time Zones in Global Teams:

Many Infosys projects involve both onsite (at the client location, typically in the US, UK, Europe, or Australia) and offshore (India) team members. The overlap window between India Standard Time (IST) and US timezones may be as small as two to three hours. Understanding when decisions are made, when the critical meetings occur, and when responses to client queries are expected helps freshers structure their day appropriately.

In projects with US clients, the morning in India (9 AM to 12 PM IST) often corresponds to the end of the US business day, when urgent client queries arrive. The late afternoon (5 PM to 7 PM IST) may correspond to the start of the US business day. Freshers on such projects need to align their peak availability with these overlap windows.

The First Appraisal: What It Evaluates and How to Prepare

The first formal performance appraisal at Infosys typically happens at the six-month mark (mid-year review) and the twelve-month mark (annual review). Understanding what it evaluates and how it is conducted prevents the surprise that many freshers experience when they receive lower ratings than they expected.

The Appraisal Dimensions:

Infosys’s performance appraisal evaluates multiple dimensions. The specific framework used may have been updated, but the consistent themes across Infosys appraisals include:

Technical/functional skills: the quality of your technical work, as evidenced by code review outcomes, defect rates, and peer feedback.

Delivery: whether tasks are completed on time and at quality, sprint commitments are met, and deliverables meet requirements.

Communication: quality of professional communication with team members and in client-facing contexts.

Attitude and initiative: whether the employee goes beyond assigned tasks, identifies and addresses issues proactively, and demonstrates a growth orientation.

Learning and development: certifications completed, new skills developed, and engagement with Infosys’s learning platforms (Lex, InfyTQ).

The Bell Curve and Forced Distribution:

Infosys, like most large companies, uses a performance rating distribution that limits the proportion of employees who can receive the highest rating. This forced distribution means that receiving the highest rating requires demonstrating clearly exceptional performance, not just good performance. The majority of employees at all levels receive the middle bands.

For freshers, this means: aiming for the top band is reasonable if you have genuinely exceptional performance evidence. But being in the second band from the top is a strong outcome for a first appraisal, reflecting that you have met and slightly exceeded expectations.

The Self-Assessment:

The appraisal process typically includes a self-assessment where the employee rates their own performance and provides evidence. Most freshers either undersell themselves (listing tasks without stating their impact) or overclaim (describing work as exceptional without specific evidence).

Effective self-assessment: for each dimension, state what you did, provide specific evidence of the quality of what you did, and state the impact on the project. “I delivered all six tasks assigned to me in the first two sprints within committed timelines. The filter feature I built was specifically mentioned by the client as one of the most useful additions in the sprint review. I completed the AWS Cloud Practitioner certification in month three without any leave time dedicated to preparation.”

This format (what + evidence + impact) is more compelling than vague statements and more credible than overclaiming.

Preparing for the Appraisal Discussion:

Before the formal appraisal meeting with the manager or team lead, review your own work for the period: which tasks did you complete, which ones had quality issues, what did you learn, what certifications or training did you complete, and where do you want to grow in the next period?

The appraisal discussion is also the right time to ask for specific development feedback: “What is the one area where you think I have the most room to grow in the next six months?” A manager who sees this question as maturity evidence will be more favorably disposed toward a strong rating than one who is asked only about the rating itself.

Building Relationships That Matter in the First 90 Days

Careers in IT services are built on relationships as much as on technical skills. The relationships formed in the first 90 days have long-term implications.

The Team Lead: The Most Important Relationship

The team lead’s perception of you is the primary input into the first appraisal, the quality of tasks you receive, and any future opportunity they flag for you. Build this relationship through: consistent delivery, transparent communication, and genuine engagement with the feedback they provide.

Avoid: trying to be impressive through words rather than work. The team lead has seen many freshers who talk confidently and deliver poorly. The ones who earn genuine respect are those who deliver consistently and communicate honestly when they are struggling.

The Senior SSE or TA Who Works Closest to You

In most Infosys teams, there is a senior team member (SSE or TA level) who serves as the day-to-day technical mentor for freshers. This person reviews your code, answers your technical questions, and provides the most direct technical guidance.

Build this relationship through: engaged learning from their feedback, following their technical advice without debating it unnecessarily (you do not yet have the experience to override their judgment), and gradually demonstrating that you are learning from each interaction.

Peer Freshers

If there are other freshers in your batch who are deployed on the same or adjacent projects, these peers are a support network. Share what you are learning about the project, help each other debug problems, and study for certifications together.

Avoid a competitive dynamic with peer freshers. IT services is a long game; the peer who helps you today is the colleague who refers you for a position five years from now.

The Project Manager or Delivery Manager

The PM or DM is responsible for the overall project delivery. They interact with freshers primarily through project status meetings and the appraisal process. Being positively visible to the DM means: making insightful comments in team meetings occasionally, being specifically mentioned positively by the team lead, and demonstrating awareness of the project’s business context beyond your own technical work.

Being negatively visible to the DM means: being cited in escalation discussions, having your tasks repeatedly delayed, or creating client-visible quality issues.

The goal is to be a positive presence that the DM is aware of, not an invisible contributor who never attracts any attention.

Technical Growth During the First Project

The first project is where the technical foundation from Mysore training meets the reality of professional software engineering. The gap between these two is where most of the first year’s learning happens.

The Most Common Technical Learning Moments:

Working with a large, messy codebase for the first time: Mysore training uses clean, purpose-built example code. Real project codebases are years old, contain patches on top of patches, and have inconsistent conventions across different modules written by different teams. Learning to work with this reality without being paralyzed by it is a key first-year skill.

Understanding production constraints: code that works in testing may fail in production because of: different data volumes, concurrent users, network conditions, or environmental differences. Understanding why production is different from local development, and how to diagnose production issues, develops rapidly through first-hand experience.

The debugging discipline: debugging a production issue under time pressure, with limited access to the production environment, is very different from debugging a Mysore exercise with full access to the code and the ability to print anything. Learning to use logging effectively, read stack traces from production systems, and reproduce issues in lower environments is a first-year survival skill.

Certifications During the First Project:

Infosys encourages and in some cases requires freshers to complete specific certifications during their first year. The most common are cloud certifications (AWS or Azure) and technology-specific certifications relevant to the project stack.

The best approach to certifications during the first project: treat them as parallel activity that complements the project work rather than as separate preparation campaigns. Study for the AWS certification in the evenings while working on the project during the day. The cloud knowledge developed for the certification directly applies to the cloud-related work on the project.

What to Learn on Your Own Initiative:

Beyond the assigned tasks and the project’s immediate technology stack, freshers who perform best invest in self-directed learning in adjacent areas:

If you are working in Java Spring Boot: learn Docker and container deployment. The project will eventually need to be containerized, and understanding this from the basics puts you ahead of the curve.

If you are working in data engineering: learn the SQL optimization techniques that are not covered in basic SQL education. Query plans, index usage, and join optimization are skills that differentiate average data engineers from strong ones.

If you are working in testing: learn test automation frameworks beyond what the project currently uses. ISTQB Foundation Level certification is achievable during the first project and provides formal recognition of testing knowledge.

Frequently Asked Questions

1. How long is the bench period between Mysore training and the first project?

The bench period varies significantly. Some freshers are deployed within two to four weeks of completing training. Others wait two to three months. The bench period depends on open requirements in Infosys’s project portfolio at the time. It is paid time and should be used productively for continued technical skill development.

2. Can I request a specific project or technology domain for my first deployment?

You can express preferences during the stream allocation process at Mysore and during the deployment discussion with the RMG team. Preferences are considered but not guaranteed; project deployment is primarily driven by business demand. Geographic preferences (city of deployment) are weighted more heavily than technology or domain preferences.

3. What happens if I am not performing well in my first project?

If performance issues are identified early, the typical Infosys response is: informal feedback from the team lead, a Performance Improvement Plan (PIP) if issues persist, and potentially redeployment to a different project if the fit with the current one is genuinely poor. Freshers who are struggling should communicate proactively with the team lead rather than hoping the situation improves without intervention.

4. Is it normal to feel lost in the first few weeks of a project?

Completely normal. The combination of a new codebase, new team, new processes, and new technology context creates genuine cognitive overload. Most experienced engineers also feel this when starting a new project. The resolution is consistent daily learning rather than expecting immediate competence.

5. How do I handle a team lead who is not helpful or who is too busy to answer questions?

If the team lead is consistently unavailable for guidance, identify another senior team member (SSE or TA) who can serve as a day-to-day technical resource. Also, explore the project documentation more thoroughly and use resources like the existing codebase (reading how existing features were implemented is often the best guide to implementing new ones). If the situation is genuinely impacting your ability to contribute, raise it with the project manager.

6. What should I do if the first project is not technically challenging enough?

A less challenging first project is not inherently a problem. Use the additional mental bandwidth to: go deeper into the technology being used, proactively identify improvements to the codebase and raise them as tickets, complete certifications, and build skills in adjacent areas. A stronger technical foundation built in a less demanding environment is excellent preparation for more demanding subsequent projects.

7. How quickly should I be completing tasks independently versus asking for help?

By month two, you should be able to complete straightforward bug fixes and minor feature additions without assistance, asking questions only when genuinely uncertain about an architectural decision or a new technology. By month three, you should be completing medium-complexity tasks (multi-day feature implementations) independently with only high-level guidance.

8. Are there opportunities to change projects during the first year?

Internal project changes within the first year are generally not standard, except when a project ends or a specific business need creates an opening. Expressing interest in a different domain or technology after a year of service is more appropriate timing, and the internal job posting system is the formal channel for this.

9. What do the most successful Infosys freshers do differently from average freshers?

They are proactive rather than reactive, they communicate transparently rather than hiding problems, they take quality seriously rather than treating code review as an obstacle, and they invest in learning outside of assigned tasks. These are behaviors, not natural traits, and any fresher can adopt them deliberately.

10. What happens during the probation period and how does it end?

The probation period at Infosys is typically six months from joining. During this period, employment is conditional on satisfactory performance. At the end of the probation period, the manager confirms employment based on the performance assessment. A successful end of probation is not an event; it is the outcome of performing well throughout the six-month period.

11. Should I tell my team lead about my career goals in the first 90 days?

Yes, but with calibrated timing. In the first month, focus entirely on demonstrating reliable delivery before raising career aspiration discussions. By month two or three, a brief conversation with the team lead about your longer-term interests (data engineering, cloud architecture, etc.) is appropriate and helps the team lead factor your interests into project opportunities.

12. How does the first project experience affect the appraisal?

The first project is the primary input into the first appraisal. The team lead’s assessment of your delivery quality, communication, initiative, and technical growth over the six-month period is the main determinant of the appraisal rating. There is no standardized test; the appraisal is entirely based on observed work performance.

13. What if I have a conflict with a team member in the first 90 days?

Professional conflicts in the first 90 days are best handled through direct, professional conversation with the involved person before escalating. If a team member is providing incorrect technical guidance that you believe is wrong, raise your concern factually: “I understood from the documentation that the correct approach is X. I want to make sure I am understanding correctly.” If the conflict is behavioral rather than technical, involve the team lead early rather than letting it fester.

14. How do I manage the learning from the project alongside the required Infosys training courses?

The mandatory Infosys training modules (available through Lex) are typically designed to be completed in evenings and weekends rather than during core project hours. Some project configurations allow dedicated training days. The standard expectation is that mandatory training is completed within the specified deadline while project delivery continues in parallel.

15. What is the best indicator that I have had a successful first 90 days?

The most reliable indicator is the team lead’s assessment: are they assigning you tasks of increasing complexity, are they requiring fewer corrections on your code reviews, are they including you in more discussions about technical decisions? If the answer to these three questions is yes, the first 90 days have been successful regardless of whether you feel confident about your performance.

The Emotional Reality of the First 90 Days

Most career guides are written to describe what should happen and what to do. This section addresses what actually happens emotionally during the first project period, because the emotional reality affects performance and because knowing it is normal is itself useful.

The Competence Trough:

Almost every professional, regardless of intelligence or technical skill, experiences a period of feeling significantly less competent than they felt at the end of their formal education. The Mysore training ended with a sense of accomplishment: assessments passed, stream allocated, training completed. The first project often replaces this with a sense that you do not know nearly enough.

This is the competence trough, and it is a normal feature of moving from a structured learning environment to a complex, real-world professional environment. It is not evidence that you are unsuited for the work. It is evidence that you are encountering the gap between academic learning and professional application, a gap that everyone in every field encounters when they first work professionally.

The trough typically lasts four to eight weeks before competence begins to feel more genuine. The way through it is consistent effort and engagement, not reassurance-seeking.

Impostor Syndrome:

Impostor syndrome, the feeling that you are less qualified than others believe you to be and that you will eventually be “found out,” is extremely common among high-performing individuals in new environments. Many Infosys freshers who are performing well still feel that they are not performing well, because they compare their internal experience (confusion, uncertainty, slow progress on problems) to their external perception of their colleagues (who appear confident and competent because they have experience).

Your colleagues’ apparent competence is the result of one to five years of experience on this or similar projects. You are three weeks in. The comparison is not meaningful. Focus on your own trajectory: are you learning faster this week than last week? That is the relevant metric.

The Loneliness of a New Professional Context:

The batch camaraderie of Mysore does not transfer directly to the project environment. Your Mysore batchmates may be on different projects in different cities. Your project team consists of people at different career stages who have existing working relationships.

This transition can be isolating, particularly for freshers who are deployed to a new city and do not have a pre-existing social network there. Actively building connections in the project team and in the Infosys employee community (through internal groups, sports clubs, and social events) helps bridge this gap. The Infosys campus in most cities has communities organized around shared interests (sports, music, literature, cultural events) that are accessible to all employees.

The Excitement Side:

The first 90 days also contain genuine moments of professional excitement that are worth acknowledging. The first time you submit code that is merged into a production system and you see it working for real users is different in quality from any academic exercise. The first client meeting where you contribute something genuinely useful creates a sense of professional identity that Mysore training cannot replicate.

The emotional arc of the first 90 days is typically: initial excitement → competence trough (confusion and self-doubt) → early wins → growing confidence. Knowing this arc exists makes the trough easier to navigate because you know it has an end.

Day-by-Day Guide: The First Two Weeks

For freshers who want a concrete daily structure for the first two weeks on a project, the following provides specific guidance.

Day 1:

Arrive on time (or log on on time for remote). Bring a notebook. Introduce yourself to every team member you meet. Ask the team lead for: the project overview document, the repository URL, and the local setup instructions. Do not expect to be productive today; today is about getting context and access.

End of day: write down the names of every team member you met and their roles. Write down what you understood about the project in two to three sentences.

Day 2:

Start setting up the local development environment following the setup instructions. This will likely hit obstacles. Document every obstacle and the resolution. Ask for help after spending more than 30 minutes on a single obstacle without progress.

Review any project overview documents that were shared. Ask three clarifying questions about anything you did not understand.

Day 3:

Continue environment setup. Get the application running locally and verify it responds to a test request. Review the existing test suite to understand what is already tested.

Ask the team lead for a 30-minute walkthrough of the codebase’s main components.

Day 4:

Read through recent Git commits to understand what has been worked on recently. Read the JIRA board to understand the current sprint’s goals and the backlog.

Ask the team lead about the first task: express that you are ready to pick up an initial task and ask what would be most useful.

Day 5 (End of First Week):

Review what you have learned in five days and write a brief summary. By now you should have: a working local environment, basic understanding of the application’s purpose and structure, awareness of the team’s current work, and a first task assigned or about to be assigned.

Day 6-10 (Second Week):

Begin working on the first task. Apply the approach described in the first task section: read first, form a hypothesis, confirm with the team lead, implement, test, write tests, submit for review.

Participate actively in the daily standup from day one: give a clear, specific update.

By the end of the second week: have submitted at least one code change for review and ideally had it merged. Even a documentation update or a test addition is a valid first contribution.

Day 11-14:

If the first code review is complete: address all feedback, resubmit if needed, and close the task fully.

Identify the next task and start the cycle again, applying the same approach but faster because the environment is now familiar.

The Tools and Systems You Will Use Every Day

Understanding the specific tools used in professional IT services work, many of which were not covered in Mysore training in their full professional context, reduces the learning overhead in the first weeks.

Version Control (Git):

Git is the foundation of all code management in professional software development. The Mysore training covered the basics; the professional context adds layers: pull request workflows, branch naming conventions, code review processes, rebasing versus merging, and resolving merge conflicts.

The most important Git practice for freshers: commit frequently with descriptive commit messages. Each commit should represent a single logical change, and the message should explain what was changed and why. “Fix null check in DateParser” is better than “fix bug” or “update”. Multiple small, well-described commits are easier to review, easier to revert if needed, and build a clear narrative of the development process.

IDE (IntelliJ IDEA or Eclipse for Java):

Most Java projects at Infosys use IntelliJ IDEA or Eclipse. Mysore training may have covered one of these; the professional context requires deeper proficiency. Specific proficiency goals for the first month: navigate the codebase using keyboard shortcuts (Go to Definition, Find Usages, Search Everywhere), use the built-in debugger to step through code execution, run tests from within the IDE, and use the built-in Git integration for commits and reviews.

The difference between a developer who is fluent with their IDE and one who is not is measured in hours per day. IDE proficiency is worth deliberate investment in the first month.

JIRA (or Azure DevOps):

Task management through JIRA requires specific habits: update task status when you start, make progress comments, log time accurately (Infosys projects typically require time logging against specific JIRA tickets), and close tasks fully (not just marking done but ensuring all subtasks are resolved and the closing comment explains what was done).

Microsoft Teams or Slack:

The team’s primary communication tool requires professional communication norms: respond to messages within a reasonable timeframe (30 to 60 minutes during working hours is the expectation), use threads for conversations rather than posting at the channel level for every message, and use direct messages for private conversations rather than broadcasting everything to the whole team.

Infosys InfyMe:

InfyMe is the Infosys employee self-service portal. During the project phase, it is used for: leave requests and approvals, accessing payslips and investment declarations, raising IT support tickets, and engaging with learning content on Lex. Ensure you know how to navigate it from the first week.

The Project’s Specific Tools:

Every project has specific tools: an API testing tool (Postman, SoapUI), a logging platform (Splunk, ELK), a database client (DBeaver, SQL Developer), a deployment pipeline (Jenkins, GitLab CI), and potentially client-specific tools. Ask the team lead for a list of tools used by the project and spend time getting familiar with each during the first two weeks.

Certifications and Learning: What to Target in the First Year

The first year at Infosys is an opportunity to build a certification portfolio that strengthens both the internal appraisal record and the external market profile.

What Infosys Supports:

Infosys has programs to support specific certification journeys. For cloud certifications (AWS, Azure, GCP), Infosys provides learning resources through Lex and in many cases covers the examination fee for the first attempt. Check the Lex platform and the unit HR for the specific certifications supported in your deployment year.

Infosys’s certification tracking in InfyMe makes certifications visible to managers and to the resourcing team, which can influence future project deployment decisions.

Recommended First-Year Certifications by Stream:

Java development stream: AWS Certified Developer - Associate or AWS Cloud Practitioner as a foundational cloud certification. OCJP (Oracle Certified Java Programmer) if the project is heavily Java-focused.

Testing stream: ISTQB Foundation Level Certification. This is widely recognized, achievable in two to three months of part-time study, and immediately relevant to testing work.

Infrastructure/cloud stream: AWS Cloud Practitioner first, then AWS Solutions Architect Associate within the first year. Azure Fundamentals (AZ-900) for Azure-heavy deployments.

Data stream: Azure Data Fundamentals (DP-900) or AWS Data Analytics specialty certifications at the introductory level.

The Certification Study Approach:

Study for certifications in the evenings and on weekends, not during project working hours (unless the team has dedicated training days). The expectation is that project delivery is not affected by certification pursuits.

Allocate four to six weeks for foundation-level certifications (AWS Cloud Practitioner, ISTQB Foundation): 30 to 45 minutes daily is sufficient for these. Associate-level certifications (AWS Solutions Architect Associate) require eight to twelve weeks of consistent study.

The most efficient certification preparation combines: the relevant Lex or Springboard foundational content, a focused study guide (AWS’s own study materials, Whizlabs or similar practice tests), and hands-on practice (for AWS, the free tier account; for testing, hands-on with the tools in your project context).

Navigating the Office Culture and Dress Code

The transition from the student-casual culture of college to the professional environment of an IT company involves adjustments that are practical and ongoing.

Business Casual at Infosys:

The standard dress code at Infosys offices is business casual: formal or smart-casual trousers, collared shirts or formal shirts for men, appropriate formal western or Indian attire for women. The Mysore training established this standard. At the project office location, the exact interpretation varies by office culture: some Infosys offices are stricter, others more relaxed.

Observe what the experienced team members wear and calibrate accordingly. When client visits are expected (which you will know from the project calendar), dress more formally than the standard.

Meeting Room Culture:

Conference rooms at Infosys offices are booked for meetings. Walking into a booked meeting room and setting up for your call, only to have the team that booked it arrive and need the room, is a common cause of friction. Book rooms properly through the InfyMe or office booking system for any meetings you organize.

Open Floor Plans and Focus Work:

Most Infosys offices use open floor plans. Deep focus work (coding, debugging, design) requires managing interruptions. Use headphones as a signal that you are in focus mode. Designate specific hours for focus work and specific hours for meetings and communication.

Cafeteria and Break Culture:

Breaks are genuinely important for cognitive performance. The Infosys campus cafeteria and break areas are social spaces where informal team connections are built. Eating lunch with team members (even occasionally) rather than at your desk builds the working relationships that make collaboration more effective.

The 90-Day Review: What to Expect and How to Prepare

Some Infosys projects conduct formal or informal 90-day check-ins for freshers, separate from the six-month appraisal. Whether or not a formal 90-day review exists, preparing for the conversation with your team lead at the three-month mark is valuable.

What to Document Before the Review:

Tasks completed: list every task you completed with the sprint it was in and the outcome. Code contributions: list PRs merged, bugs fixed, features delivered. Certifications or training completed. Skills developed: new technologies or concepts you understand now that you did not when you started. Challenges and how you addressed them.

Questions to Ask in the 90-Day Conversation:

“What are the two or three things I should focus on improving most in the next quarter?” “Are there specific skills or knowledge areas that would make me more effective on this project?” “Is there a more challenging task area I can take on in the next sprint?”

These questions frame the conversation as growth-oriented rather than just evaluative, which creates a better conversation and more actionable guidance.

The Trajectory Signal:

The 90-day point is also where the trajectory signal becomes visible to the team lead: are you getting better week over week, or have you plateaued? A fresher who is visibly improving in quality, speed, and independence at the three-month mark is on a strong trajectory regardless of the absolute performance level on day 90. A fresher who is performing at exactly the same level as day 30, without visible growth, is a more concerning signal.

Demonstrate growth deliberately: point out specifically what you could not do in month one that you can do in month three. “I can now debug production issues in our logging system that I would have needed to escalate to a senior team member three months ago” is a concrete demonstration of growth.

How the First 90 Days Shape the Next Two Years

The decisions and habits formed in the first 90 days on a project are not temporary; they establish patterns that persist and compound.

The Reputation That Forms Quickly:

Within the team, your reputation forms rapidly. Within three months, every team member who has worked with you has a clear impression: reliable or unreliable, quality-conscious or careless, communicative or opaque, growth-oriented or static. These impressions, once formed, are persistent and require significantly more effort to change than they took to form.

The most effective strategy: form the right reputation from day one rather than trying to correct a poor reputation at month four. The habits described throughout this guide, if applied consistently from the first week, form the reputation that leads to good outcomes.

The Skills That Compound:

Every skill developed in the first project compounds: faster debugging builds faster debugging, which builds more confidence, which enables more ambitious task selection, which builds even more skill. The reverse is also true: avoidance of hard problems in the first 90 days reduces exposure to the experiences that build the skills required for later success.

The Network That Persists:

The team lead who knows you performed well in your first project is a professional reference for the next decade. The senior team member who mentored you and saw your growth is someone who may recommend you for a role three years later. The relationships built in the first project team are among the most durable in a professional career, precisely because they were formed in the context of shared challenging work.

This guide, used well, provides the framework for making the most of those first 90 days. The framework is not complicated: show up consistently, work with quality and ownership, communicate transparently, learn deliberately, and build genuine relationships. The career built on this foundation in the first 90 days is the one that pays dividends for the following 30 years.

Stories From the Field: Patterns From Real First Projects

The following narratives are composites drawn from the patterns that repeat across many Infosys freshers’ first project experiences. Names and specific details are illustrative.

The Slow Starter Who Caught Up:

Arjun joined a banking application maintenance project with a Java team. His first month was difficult: the codebase was large and unfamiliar, the team was experienced and fast-moving, and his team lead was busy with client deliveries and not available for much guidance.

Arjun’s approach in month two: instead of waiting for guidance, he spent every evening reading the codebase systematically, file by file, building a mental map of the application. He created a personal wiki documenting what each major class did and how the components interacted. By month three, he was the team member who could answer questions about how the legacy components worked, because he had read them more carefully than anyone who had been on the project for years.

His first appraisal: “Slow start but strong ramp-up. Demonstrates excellent codebase knowledge for someone with three months on the project.”

The Strong Starter Who Plateaued:

Priya joined a data analytics project with strong Python skills from competitive programming preparation. Her first six weeks were excellent: she delivered tasks faster than expected, her code was clean, and her team lead was very positive.

In week seven, she received a task involving Spark optimization, a technology she had not used before. Instead of asking for guidance or spending time learning it properly, she produced a solution that looked correct on small datasets but failed in production with large volumes. The debugging took the team lead two days to resolve.

The lesson: visible early success creates expectation that the fresher can handle any task independently. The correct behavior when encountering a genuinely unfamiliar technology is the same regardless of how well you have been performing: acknowledge the unfamiliarity, ask for guidance or pointing to resources, and invest the time to learn before implementing.

The Quiet Contributor Who Got Overlooked:

Rahul joined a cloud infrastructure project and delivered consistently: every task on time, good quality, no issues. But he never spoke in meetings beyond the required standup updates, never asked questions about the broader project direction, and never initiated any conversations about his career interests with the team lead.

At his six-month appraisal, his rating was “Meets Expectations” despite genuinely good delivery. His team lead’s assessment: “Rahul delivers reliably but I do not have a clear picture of his technical interests, growth direction, or longer-term potential.”

The lesson: visibility matters. Consistent delivery is necessary but not sufficient for strong appraisal ratings. The team lead must know what you know, how you think, and where you are heading to rate you fully. This requires deliberate professional communication beyond the minimum required by the daily work.

The Infosys Fresher in the Broader Technology Career Context

The first 90 days at Infosys sit within the larger arc of a technology career. Understanding this context helps freshers make decisions in these early months that align with where they want to be five or ten years from now.

The Foundation Year:

The first year at Infosys, across the project and the continuing learning, is the foundation year of the technology career. The technical habits, professional habits, and work ethic established in this year compound across the following years. A first year characterized by genuine engagement, quality consciousness, and deliberate learning produces a professional foundation that all subsequent career development builds on.

A first year characterized by minimum viable effort, passive learning, and short-term thinking produces a foundation that limits rather than enables future development.

The Infosys Experience as a Signal to Future Employers:

When you eventually move from Infosys to a product company, GCC, or another IT services company, the Infosys experience is what that future employer sees. A five-year Infosys record showing consistent strong ratings, multiple certifications, progressively more senior project contributions, and eventually a team lead or module ownership role tells a very different story than a five-year record of “Meets Expectations” ratings and no certifications.

The investments made in the first 90 days, compounded over five years, produce one of these profiles or the other. The trajectory is largely determined by the habits and choices of the first project year.

What the Best Infosys Freshers Have in Common:

Looking at the profile of Infosys engineers who transition to product companies or GCCs with strong outcomes, who progress quickly through the Infosys designation hierarchy, or who build meaningful technical expertise within IT services, the common factors are not surprising but they are specific:

They were deliberately curious from day one: not just learning what was needed for the immediate task, but understanding the broader context, the business problem being solved, and the architectural decisions behind the systems they worked on.

They built relationships with intention: not networking in a transactional sense, but genuinely engaging with the people they worked with, learning from them, and being someone that others wanted to work with again.

They were honest about their performance: not waiting for a manager to tell them they were struggling, but raising their own concerns and asking for help before problems became visible.

They thought about the next thing, not just the current thing: while delivering the current sprint, they were also thinking about what skills they needed for the next stage of their career.

These are the behaviors that the first 90 days on a project either establish or fail to establish. They are learnable. They are visible. And they are, in the end, what determines whether the Infosys career is the beginning of something excellent or just the first of many undifferentiated years.

Quick Reference: The First 90 Days Checklist

Use this checklist to track your progress through the first project quarter.

Week 1:

Received project deployment confirmation and reported on time
Met all team members and noted their names and roles
Received and read project overview documentation
Obtained all system access (repository, JIRA, communication channels)
Started local environment setup

Week 2:

Local environment fully working, application running locally
Read the codebase entry points and traced at least one request end-to-end
Reviewed recent Git commits and current sprint backlog
Received first task assignment
Established daily standup contribution pattern

Weeks 3-4:

First code change submitted for review
Code review feedback received and addressed
First task fully completed and closed in JIRA
Time logging established in project tool
Completed introduction of self to PM/DM (at minimum, visible in team meeting)

Month 2:

Second and third tasks completed, showing faster turnaround than first task
Participated actively in sprint planning (asked at least one clarifying question)
Identified and raised one improvement opportunity (documentation gap, test gap, etc.)
Started certification study (minimum: selected a target certification)
Established check-in rhythm with team lead

Month 3:

Completed at least 3-4 tasks across the quarter spanning different complexity levels
No tasks missed without proactive communication
At least one task completed with minimal team lead guidance
Certification study on track
Prepared for 90-day check-in with specific examples of growth

For the First Appraisal:

List of all completed tasks with sprint, outcome, and any client feedback
Code contributions (PRs merged, features delivered, bugs fixed)
Certifications completed or in progress
Specific evidence of each appraisal dimension ready (delivery, technical quality, communication, initiative, learning)
Two questions for the team lead about development focus for next period

This checklist, completed consistently, represents the minimum for a solid first 90 days. Anything above this minimum builds toward an exceptional first appraisal.

This article is part of the InsightCrunch Infosys Series, the most comprehensive collection of guides for Infosys aspirants and employees. The series covers the complete Infosys journey from preparation through career development across 21 articles.

One Final Note on Mindset

The first 90 days are hard. Not overwhelmingly hard for someone who has made it through engineering college and Mysore training, but genuinely hard in a different way. The work is ambiguous, the feedback is sometimes slow to come, and the gap between what you know and what the work requires feels wider than it should.

The correct mindset for navigating this is not confidence (which you may not feel) but commitment: to show up every day, engage with whatever is in front of you, ask questions when stuck, and treat every interaction as an opportunity to learn something.

That commitment, maintained consistently through the confusion of the first weeks and the plateau of the second month, produces the competence and confidence that the third month delivers. And the third month is when the first project starts to feel like something you are genuinely contributing to, not just surviving.

That feeling is what all of the preparation was for. It arrives right on schedule for those who earn it.

Infosys Fresher Experience: What the First 90 Days on a Project Actually Look Like After Mysore Training

Table of Contents

The Transition From Mysore to Project: What Changes

The Project Allocation Process

Week 1: Orientation and the Onboarding Fog

Understanding Your Project: Codebase, Architecture, and Context

Your First Task: What to Expect and How to Handle It

Working With Your Team Lead and Manager

Client Communication: What It Looks Like as a Fresher

Agile and Project Management: How Work Is Organized

Common Mistakes Freshers Make in the First 90 Days

What Strong First-Year Performance Actually Looks Like

Managing Remote Work and Hybrid Arrangements

The First Appraisal: What It Evaluates and How to Prepare

Building Relationships That Matter in the First 90 Days

Technical Growth During the First Project

Frequently Asked Questions

The Emotional Reality of the First 90 Days

Day-by-Day Guide: The First Two Weeks

The Tools and Systems You Will Use Every Day

Certifications and Learning: What to Target in the First Year

Navigating the Office Culture and Dress Code

The 90-Day Review: What to Expect and How to Prepare

How the First 90 Days Shape the Next Two Years

Stories From the Field: Patterns From Real First Projects

The Infosys Fresher in the Broader Technology Career Context

Quick Reference: The First 90 Days Checklist

One Final Note on Mindset

Table of Contents

The Transition From Mysore to Project: What Changes

The Project Allocation Process

Week 1: Orientation and the Onboarding Fog

Understanding Your Project: Codebase, Architecture, and Context

Your First Task: What to Expect and How to Handle It

Working With Your Team Lead and Manager

Client Communication: What It Looks Like as a Fresher

Agile and Project Management: How Work Is Organized

Common Mistakes Freshers Make in the First 90 Days

What Strong First-Year Performance Actually Looks Like

Managing Remote Work and Hybrid Arrangements

The First Appraisal: What It Evaluates and How to Prepare

Building Relationships That Matter in the First 90 Days

Technical Growth During the First Project

Frequently Asked Questions

The Emotional Reality of the First 90 Days

Day-by-Day Guide: The First Two Weeks

The Tools and Systems You Will Use Every Day

Certifications and Learning: What to Target in the First Year

Navigating the Office Culture and Dress Code

The 90-Day Review: What to Expect and How to Prepare

How the First 90 Days Shape the Next Two Years

Stories From the Field: Patterns From Real First Projects

The Infosys Fresher in the Broader Technology Career Context

Quick Reference: The First 90 Days Checklist

One Final Note on Mindset

Related Reading