You cleared IRA, passed every diagnostic, survived the PRA, and completed your ILP. The training is over. What happens next? The transition from ILP trainee to project-assigned associate is one of the most talked about yet least understood phases of the TCS fresher journey. Rumors about months-long bench periods, technology mismatches, and confusing project interviews circulate freely in fresher communities, but detailed information about how the system actually works is surprisingly hard to find.

This does not have to remain unclear. The project allocation process at TCS follows a structured framework managed by the Resource Management Group (RMG), and understanding how that framework operates gives you a significant advantage over freshers who enter the post-ILP phase blindly.

TCS ILP to Project Allocation - What Actually Happens After Training Ends

This guide covers every stage of the transition: the final days of ILP, the PRA exam, reporting to your base location, how RMG works, the project interview process, the bench period and what you are expected to do during it, technology mismatch scenarios, the impact of ILP ratings and cadre on allocation, and the new 2025 deployment policy that has fundamentally changed how TCS manages bench time. The information draws from the documented TCS process, official policy communications, and the reported experiences of freshers across multiple batches and base locations.

For preparation on the assessments that happen before this phase, use the TCS ILP Preparation Guide tool on ReportMedic.

The Final Week of ILP

The last week of your ILP training is not just about finishing coursework. It is a structured wind-down that includes your final assessment, your ILP rating disclosure, your base location logistics, and the administrative handover from your ILP center to your base branch.

The PRA Exam

PRA stands for Project Readiness Assessment. It is the last formal exam you take during ILP, conducted after all technical modules and diagnostics have been completed. PRA is a comprehensive assessment that draws from multiple modules rather than testing a single one. The question format includes multiple-choice questions, scenario-based problems, and sometimes code interpretation or short-answer coding exercises.

There is a persistent myth that PRA is the decisive factor in project allocation and ILP ratings. Based on what past batch trainees have consistently reported across ILP centers in Trivandrum, Hyderabad, Chennai, and Ahmedabad, this is not accurate. PRA scores contribute to the overall ILP evaluation, but they are one factor among many. Your cumulative diagnostic scores, business skills performance, attendance record, and IRA scores all feed into the final rating.

One alumnus from the Trivandrum center put it clearly: “There is a myth that PRA will decide your ILP ratings. But trust me, it is not like that. For ILP ratings, your overall performance will be measured.” This has been echoed consistently by freshers from other centers as well.

The practical advice from past batches is to take PRA seriously but not stress about it disproportionately. If you have been engaged throughout ILP and performed reasonably on your diagnostics, PRA is a review exercise covering material you have already been tested on during individual module diagnostics. The questions are not fundamentally different in difficulty or scope from what you encountered throughout training.

ILP Ratings - What They Mean

Your final ILP rating is a composite score derived from IRA scores, diagnostic performance across all modules, business skills evaluations, PRA, attendance, and qualitative factors like participation and professional behavior.

The rating is expressed on a scale from 1 (lowest) to 5 (highest). Based on reports from multiple ILP centers, the vast majority of trainees receive a rating of 3. A rating of 4 indicates consistently strong performance across both technical and business skills tracks. A rating of 5 is described as extremely rare and reserved for trainees who demonstrated “extraordinarily outstanding performance” across every dimension. The rating uses whole numbers only, so there is no distinction between a high 3 and a low 3.

Your ILP rating is shared with you on the second-to-last or last day of ILP. It is not a secret - you are told your rating directly. However, the exact weighting formula that produces the rating is not publicly disclosed, which means you cannot calculate it yourself from your individual scores.

The ILP rating matters during the project allocation phase. Associates with ratings of 4 or 5 typically get allocated first. They may receive priority consideration for certain projects, a higher chance of getting their preferred base location, and consideration for the differential batch if eligible. Associates with a rating of 3 follow in the standard allocation queue. A rating below 3 does not prevent allocation but may result in a longer wait or fewer initial options.

However, and this is important to internalize, the influence of ILP ratings diminishes rapidly once you start project work. Within six months on a project, your project performance, client feedback, and skill development completely overshadow your training scores. Your project rating, which uses decimal points unlike the ILP whole number system, becomes the metric that matters for appraisals, promotions, and career progression.

The ISU Assignment

During ILP, you are assigned to an Industry Solution Unit (ISU), also referred to as a domain. ISUs are the organizational units within TCS that focus on specific industry verticals: Banking and Financial Services (BFS), Insurance, Telecom, Retail, Manufacturing, Healthcare, Energy, and several others.

Your ISU assignment determines which pool of projects you are eligible for during allocation. If you are assigned to the BFS ISU, you will be considered for banking and financial services projects. If you are assigned to the Telecom ISU, your project opportunities will be in the telecommunications domain.

You do not get to choose your ISU. The assignment is made by TCS based on business requirements, batch distribution needs, and sometimes your ILP stream. A Java-trained associate might end up in any ISU, just as a .NET-trained associate might. The technology you learned during ILP and the industry domain you are assigned to are two separate dimensions of your role.

Alumni consistently report that the ISU assignment is not something you can influence or change easily. Once assigned, your project opportunities are filtered through that ISU. However, after spending time on a project and building a track record, internal transfers between ISUs are possible through the iJoin portal and by talking to your RMG manager.

Travel and Relocation to Base Location

On the last day of ILP, you receive the details for reporting to your base location. Your base location was mentioned in your original joining letter and is the TCS office where you will work after training. If your ILP center and base location are in different cities, TCS provides travel reimbursement for the journey.

The reimbursement policy, as documented in official TCS communications, covers train fare up to a maximum of second-class AC (2A) for non-pre-mapped employees traveling from their ILP center to their base location. Pre-mapped employees, those whose base location is the same as their ILP center, are not entitled to travel reimbursement since no relocation is involved. The reimbursement amount is credited directly to your payroll rather than requiring you to submit bills and wait for processing.

You are expected to arrange your own travel. TCS does not book tickets for you. Plan your travel in advance - train tickets for popular routes between ILP cities and major base locations (Trivandrum to Bangalore, Hyderabad to Pune, Chennai to Mumbai) can sell out quickly, especially during batch completion periods when hundreds of freshers are traveling simultaneously.

Reporting to Your Base Branch

The first day at your base location is structurally different from your first day at ILP. There is no IRA exam, no document verification marathon, and no auditorium orientation. Instead, you report to the designated office, check in with the administration team, and connect with your RMG representative.

What Is RMG and How Does It Work

RMG stands for Resource Management Group. It is the team within TCS responsible for matching available associates with projects that need staffing. RMG operates at multiple levels - there is a unit-level RMG within each ISU, a regional RMG at each major TCS location, and a global RMG that oversees the entire allocation framework.

For you as a freshly trained associate arriving at your base location, the relevant RMG is the unit or regional team at your office. Your RMG manager is the person who will track your availability, share your profile with project managers looking for team members, schedule project interviews for you, and ultimately facilitate your allocation.

It is important to understand that RMG is not a single person making decisions about your career. It is a team running a process. They maintain a database of available associates and open project positions. When a project needs a team member, the project manager raises a requirement with RMG specifying the skills needed, the expected start date, the location, and other parameters. RMG then searches their available pool for matching associates and shares profiles with the project manager. The project manager reviews the profiles and may request interviews with specific candidates.

The global head of TCS’s RMG is Chandrasekaran Ramkumar, who oversees the deployment framework across the organization. Under the latest 2025 policy directive issued by his team, the allocation process has been tightened significantly, with clear expectations on how quickly associates should be deployed and what is required during unallocated periods. More on this updated policy later in this guide.

The First Interaction With RMG

When you arrive at your base location, your first step is to register your availability with RMG. This typically involves meeting your RMG manager (or the designated RMG representative for new joiners), confirming your ILP completion details, updating your profile on the internal system with your ILP stream, rating, and ISU assignment, and letting them know you are available and ready for project allocation.

Alumni describe this first interaction in various ways. Some report a formal meeting where the RMG manager reviewed their profile and discussed potential project opportunities. Others describe a more informal check-in where they were told to wait and that their profile would be circulated to project managers with current openings. The formality depends on the office size, the batch volume, and the RMG team’s current workload.

One consistent piece of advice from every batch: be proactive with RMG from day one. Do not wait passively for someone to call you. Check in regularly. Ask if there are any project interviews you can attend. Express your willingness to be flexible about project type, technology, and even location if you are open to it. RMG managers handle dozens or sometimes hundreds of associates simultaneously. The ones who are responsive, available, and easy to work with get prioritized naturally - not through favoritism, but through simple operational efficiency.

The Project Interview Process

Once RMG identifies a potential match between your profile and a project requirement, you are sent for a project interview. This is not an external hiring interview. It is an internal discussion between you and the project team to assess fit.

What Project Interviews Look Like

Project interviews for freshly trained associates are generally low-pressure compared to what you might expect. The project manager or team lead already knows that you have completed ILP and passed the required assessments. They are not testing whether you can code - they are evaluating whether you are a reasonable fit for their specific team and project context.

Expect questions along these lines. What did you learn during ILP? What was your ILP stream? Tell me about your Phase 2 project - what technology did you use and what was your role? Are you comfortable with a particular type of work - development, testing, support, or maintenance? Have you done any self-study or personal projects beyond ILP curriculum? Are you willing to travel or work from a client site in a different city?

The format is typically conversational. It may last 15 to 30 minutes. In some cases, you might face a brief technical question or two to gauge your comfort level with specific concepts relevant to the project. For example, if the project uses Spring Framework and your ILP was in core Java, the interviewer might ask whether you have any exposure to Spring and how quickly you think you could ramp up.

Past batch trainees from multiple base locations report that project interview outcomes fall into three categories. Some freshers are accepted immediately after the interview and begin onboarding onto the project within days. Some are not selected, in which case RMG sends them to a different project interview - this is not a negative mark, it simply means the fit was not right for that particular project. And some freshers are allocated to projects directly by RMG without any interview at all, particularly when the project has a bulk staffing need and the RMG matches multiple associates at once.

Being rejected in a project interview is not something to worry about. It is a normal part of the allocation process. RMG’s job is to keep sending your profile to projects until a match is found. Some freshers go through one interview and get placed immediately. Others go through three or four before finding the right fit. Both outcomes are normal.

What Projects Look Like for Freshers

This is an area where expectations and reality often diverge significantly.

Most freshers entering TCS hope for development projects - writing new code, building applications from scratch, working on cutting-edge technologies. The reality, as reported by alumni across every batch and base location, is that the majority of freshers are assigned to support, maintenance, or testing projects, at least initially.

Support projects involve maintaining existing applications, troubleshooting issues reported by users, and implementing minor fixes or enhancements. Maintenance projects are similar, focused on keeping established systems running smoothly. Testing projects involve designing and executing test cases, identifying defects, and validating fixes. Change Request (CR) work, where you implement specific modifications requested by the client on an existing system, is also common for freshers.

Development projects - building new applications or features from the ground up - are less common for freshly trained associates. As one ILP alumnus noted, “You will get development project if you are lucky because as a fresher you are not expected to work on development.”

This may sound disappointing, but it is important to reframe it correctly. Support and maintenance work teaches you how real-world enterprise applications function - how they are structured, how they interact with databases and external systems, how bugs manifest and get resolved, and how client communication works. These are skills that development-focused training does not fully cover. Many experienced professionals look back on their first support or maintenance project as the experience that taught them how software actually works in production.

The type of project you start with does not define your career trajectory. It defines your starting point. Associates who perform well on any type of project get noticed, earn strong performance ratings, and move into more interesting work over time. Your first project at TCS is a learning platform, not a permanent role.

The Bench Period - What It Really Is

The bench period is the gap between completing ILP and starting your first project. It is the most discussed and most anxiety-inducing phase of the early TCS career. Understanding what bench actually means, how long it lasts, and what the expectations are during it helps you navigate this period productively.

How Long Does the Bench Last

The honest answer is that bench duration varies enormously. The factors that influence it include your base location, your ISU assignment, your technology stream, the timing of your batch completion, and overall market demand for IT services.

Major TCS hubs like Mumbai, Bangalore, Hyderabad, Chennai, and Pune generally have a larger pool of active projects, which translates to shorter bench times. Smaller offices may have fewer project openings at any given time, extending the wait. Some ISUs (like BFS and Telecom) tend to have higher project volumes than others, which also affects allocation speed.

Alumni reports across multiple batches and locations suggest a range from as short as one week to as long as three to four months for freshers. The median for associates posted to major hubs appears to be in the range of two to six weeks, based on compiled batch experiences. However, these are historical patterns, and the new 2025 deployment policy has significantly changed how TCS manages bench time going forward.

The New 2025 Deployment Policy

In June 2025, TCS implemented a major policy change that fundamentally altered how bench time is managed across the organization. This policy is directly relevant to every fresher completing ILP in 2025 and beyond.

The policy, issued by Chandrasekaran Ramkumar, Global Head of RMG, requires associates to be actively allocated to client projects for a minimum of 225 business days per year. This effectively caps the maximum allowable bench time at 35 business days per year. That is roughly seven weeks - not seven consecutive weeks, but seven weeks total across the entire year.

The implications for freshers are significant.

First, extended bench periods of three to four months that some earlier batches experienced are no longer within the acceptable framework. Under the new policy, prolonged unallocation can adversely affect an associate’s compensation, career growth, overseas deployment opportunities, and even job continuity. The policy document explicitly states that it is the “primary responsibility of the associate to proactively engage with the Unit/Regional RMG for seeking allocation.”

Second, what you are expected to do during bench time is now formally codified. Associates who are unallocated must dedicate four to six hours per day to upskilling through TCS internal platforms including iEvolve, Fresco Play, and VLS (Virtual Learning System), as well as external platforms like LinkedIn Learning. You must complete all required training sessions, regularly update your skills profile, and use TCS’s Gen AI interview coach to prepare for project interviews and address any feedback received during previous interviews.

Third, physical office presence is now mandatory for unallocated associates. The default work mode is on-site. Remote or work-from-home arrangements during bench time are generally not permitted unless there are exceptional personal emergencies with prior RMG approval. This means you are expected to report to your base location office every working day during the bench period, even if you do not have a project assignment.

Fourth, the policy discourages frequent short-term project switches. Associates who repeatedly take brief allocations and then return to the bench may face HR scrutiny and potential disciplinary action. TCS wants stable, meaningful project engagements, not a revolving door of short assignments.

This policy represents a significant tightening compared to the earlier, more informal bench management approach. For freshers arriving at their base locations after ILP, the message is clear: the bench period should be as short as possible, and the responsibility for making it short is shared between you and RMG, with an explicit expectation that you will be proactive rather than passive.

What to Do During the Bench Period

Regardless of the policy framework, the bench period is best used as an intensive skill-building window. Here is what the most successful past-ILP associates have done with their bench time.

Upskill in your ILP technology stream. If you learned core Java during ILP, the bench period is when you learn Spring Framework, Hibernate, JPA, and other enterprise frameworks that projects actually use. If you learned basic Python, learn Django, Flask, or data processing libraries. The gap between ILP curriculum and project-level technology requirements is real, and the bench period is your opportunity to close it.

Learn adjacent technologies that make you more versatile. Basic Linux commands, shell scripting, Docker fundamentals, Git version control, and SQL optimization are skills that almost every project needs but that ILP may not cover in depth. Each additional skill you build widens the pool of projects you are eligible for, directly shortening your bench time.

Complete certifications through TCS internal platforms. TCS offers a range of certification programs through its learning platforms. Completing relevant certifications during bench demonstrates initiative and adds tangible credentials to your profile that project managers can see when reviewing your candidacy.

Use the TCS ILP Preparation Guide as a benchmark for your technical foundations. If there are areas where your preparation felt weak during ILP, the bench period is when you can fill those gaps without the pressure of imminent diagnostics.

Network within your office. Talk to colleagues who are on projects. Attend knowledge-sharing sessions. Build relationships with people in domain areas that interest you. Project managers sometimes source team members through informal internal channels, and being visible and known within the office increases your chances of hearing about opportunities before they go through the formal RMG queue.

Stay responsive and professional with RMG. Answer calls and emails promptly. Show up to project interviews on time and prepared. Follow up after interviews. The associates who are easy to work with and quick to respond get prioritized operationally, simply because they are easier for RMG to place.

Technology Mismatch - When Your Project Uses a Different Stack

One of the most common concerns among freshers is the possibility of being assigned to a project that uses a completely different technology from what they learned during ILP. This is not a rare exception. It happens frequently, and it happens to associates from every stream and every batch.

Why It Happens

TCS assigns projects based on business need, not training alignment. When a client project urgently needs additional team members, the project manager raises a staffing requirement with RMG. RMG looks for available associates whose profiles are the closest match. If no exact match is available - and for specific technology stacks, exact matches among fresh ILP graduates are often unavailable - they assign someone with adjacent skills and expect them to ramp up on the specific technology during the project onboarding period.

The result is scenarios that feel disorienting. You were trained on Java during ILP, and you end up on a Unix shell scripting project. You were trained on .NET, and you end up doing SAP BASIS administration. You were trained on Python, and you end up testing a mainframe application. These are not hypothetical examples - they are commonly reported outcomes across multiple batches.

How to Handle Technology Mismatch

The first and most important thing to understand is that technology mismatch is not a career setback. It is a reality of working in a large IT services organization that serves hundreds of clients across dozens of technology platforms.

Associates who are forced to learn new technologies early in their careers develop broader skill sets. A Java developer who spends their first year on a Unix project and then moves to a Java project understands both ecosystems and can bridge gaps that a pure Java developer cannot. The short-term discomfort of learning something unfamiliar creates long-term versatility that is genuinely valuable.

Second, your project team expects a ramp-up period. They know you were trained in a different technology. They will provide project-specific training materials, assign you a mentor or buddy on the team, and give you time to get comfortable before expecting independent contributions. The ramp-up period is typically two to four weeks, during which you are learning the project’s codebase, tools, and processes alongside the new technology.

Third, most programming concepts are transferable across technologies. If you understand loops, conditionals, functions, object-oriented principles, and database queries in Java, learning the syntax of C++ or Python is a matter of days, not months. The conceptual foundation is the same; only the implementation details change.

If you are genuinely uncomfortable with a project assignment or feel that the mismatch is too extreme for you to contribute effectively, you can raise this with your RMG manager. However, be strategic about it. Refusing a project outright is generally not advisable for freshers, especially under the new 2025 deployment policy where extended bench time has explicit career consequences. Instead, accept the assignment, ramp up as best you can, and if after a reasonable period (two to three months) you feel the mismatch is fundamentally unresolvable, have a constructive conversation with your manager about potential internal transfers.

Stream Selection During ILP and Its Relevance After

During ILP, you may be assigned to one of several streams: Java, .NET, UNIX/C++, BIPM, SAP, Mainframe, Assurance (Testing), or others. In some batches, stream assignment was based on a preference form submitted through Aspire. In others, it was assigned randomly. Some batches allowed candidates with relevant certifications (such as OCJP for Java) to request a specific stream.

Regardless of how you were assigned, the stream determines your ILP curriculum but does not guarantee your project technology. As one veteran TCS employee and ILP guide author put it: “It is not necessary that you will get project on the same technology on which you were trained in ILP. If you are trained on dot net then you may get a java or unix or some other technology project. Be prepared for that too.”

This disconnect between training stream and project technology is a structural feature of how TCS operates, not a bug. TCS trains freshers in fundamentals and assigns them to projects based on business demand. The expectation is that a well-trained associate can adapt to different technology stacks with reasonable ramp-up time.

The Role of Cadre in Project Allocation

TCS hires freshers into different cadres based on their NQT performance and interview results. The three primary cadres - Ninja, Digital, and Prime - have different starting points in the project allocation process.

Ninja Cadre

Ninja cadre associates have the longest ILP duration (typically three to four months for a full program) and enter the standard RMG allocation process after training. Their project assignment depends on the same factors described above: base location, ISU, technology alignment, and RMG matching. The Ninja cadre represents the largest volume of freshers in any given batch.

Digital Cadre

Digital cadre associates have a shorter ILP (typically two to three weeks) and are often fast-tracked into projects involving newer technology areas such as cloud computing, AI/ML, automation, and digital transformation initiatives. The Digital cadre benefits from a higher starting compensation and a generally faster allocation timeline, partly because the demand for digital skills tends to be consistently high across ISUs.

Prime Cadre

Prime cadre is the most selective tier, with the highest starting compensation and access to premium client engagements. Prime associates go through an accelerated ILP and are typically allocated to high-visibility projects with significant technology depth. The allocation for Prime cadre is often handled more directly, with less bench time than the standard process.

Does Cadre Matter Long-Term?

The cadre distinction is most pronounced immediately after ILP. Compensation differences persist, of course, but in terms of project quality and career trajectory, the cadre gap narrows significantly within two to three years. A Ninja cadre associate who performs exceptionally well on their projects, builds strong skills, and earns consistent high ratings can absolutely reach the same career milestones as a Digital or Prime cadre associate. Conversely, a Digital cadre associate who underperforms will not benefit from cadre advantages indefinitely.

The key insight from alumni across all cadres is consistent: your cadre determines your starting compensation and your initial allocation speed. Your performance determines everything after that.

Salary During the Transition

A practical question that many freshers have but hesitate to ask: what happens to your salary during the ILP-to-project transition?

During ILP

You receive your trainee salary throughout ILP. For the first month, the typical take-home has been reported at approximately 21,500 INR (net of deductions). From the second month onward, HRA (House Rent Allowance) deductions begin, and the take-home decreases accordingly. If TCS provides you accommodation during ILP, the HRA deduction is higher. If you are not provided accommodation (which happens for some pre-mapped associates whose base location is the same as ILP location), the deduction is lower.

The salary amount varies by cadre. Ninja, Digital, and Prime cadres have different CTC structures, and the monthly take-home reflects this. However, during ILP, the differences are modest since all cadres are in trainee status.

During the Bench Period

You continue to receive your full salary during the bench period. Being on the bench does not mean being unpaid. You are a full-time TCS employee from the day you join, and your salary is credited on the regular schedule regardless of whether you are on a project or on the bench.

However, under the new 2025 deployment policy, prolonged bench time can affect your compensation indirectly. If your bench time exceeds the 35-day annual cap, it may be reflected negatively in your performance review, which in turn affects salary increments and career progression.

After Project Allocation

Once you are allocated to a project, your salary continues unchanged in the immediate term. Any changes to compensation (performance-based increments, role changes, promotions) happen during the regular annual appraisal cycle, not at the point of project allocation.

The iJoin Portal and Internal Mobility

TCS operates an internal job portal called iJoin where associates can browse available project openings across the organization and express interest in specific roles. After completing a minimum tenure on your first project (typically six months to one year), you become eligible to use iJoin for internal transfers.

iJoin is relevant to the project allocation conversation because it represents the mechanism for course-correcting your initial assignment. If your first project does not align with your career interests, technology preferences, or location preference, iJoin provides a structured pathway to explore alternatives without leaving TCS.

Alumni who have used iJoin report that the process works but requires patience. Internal transfers are not guaranteed, and you need to have a strong performance record on your current project to be competitive for desirable openings. Project managers are also more likely to release associates who have completed meaningful tenures and contributed substantially to the team.

The practical takeaway: accept your first project with an open mind, perform well on it, and if it is not where you want to be long-term, use the internal mobility tools to transition when you are eligible. This is a far more effective strategy than refusing or underperforming on your initial assignment.

Base Location Dynamics - How Your City Affects Allocation

Not all TCS base locations are created equal when it comes to project allocation speed and variety. Understanding the dynamics of your assigned city helps you set realistic expectations and plan accordingly.

Tier 1 TCS Hubs

Mumbai, Bangalore, Chennai, Hyderabad, and Pune are the largest TCS operational hubs. These cities host hundreds of active projects across all ISUs, with a constant flow of new requirements. Freshers posted to these locations generally experience shorter bench periods because the sheer volume of projects creates more matching opportunities. The trade-off is higher cost of living, longer commutes in some cases, and a more competitive environment where multiple freshers from the same batch may be vying for the same project openings.

Bangalore in particular is consistently reported as one of the fastest locations for project allocation among freshers. The concentration of technology companies and TCS client offices in the city creates strong project demand, particularly in BFS, Telecom, and Digital transformation ISUs.

Chennai has a dual character. The TCS Siruseri campus and the Ambattur facility handle large volumes of trainees and projects, but the allocation speed depends heavily on which ISU you are assigned to and which TCS facility you report to within the city.

Mumbai and Pune benefit from proximity to major financial services clients, making them strong locations for BFS ISU associates. Hyderabad has a broad mix of projects across ISUs, with a growing presence in cloud and digital services.

Tier 2 and Tier 3 Locations

Smaller TCS offices in cities like Kolkata, Lucknow, Bhubaneswar, Goa, Kochi, Coimbatore, Nagpur, Jaipur, and Indore have fewer active projects and correspondingly narrower allocation pipelines. Freshers posted to these locations may face longer bench periods, particularly if their ISU has limited project presence in that city.

The key question for freshers at smaller locations is flexibility. If RMG offers you a project at a different city - perhaps a Kolkata-based fresher is offered a project in Bangalore - your willingness to relocate becomes the decisive factor. Associates who are open to relocation from tier 2 or tier 3 locations to major hubs typically get allocated faster than those who insist on staying at their assigned base.

Some freshers have reported being offered projects in their base city but in a different ISU or technology area, while simultaneously being offered projects in a different city within their ISU. The choice between geographical preference and domain alignment is a personal one, but understanding that this trade-off exists helps you make informed decisions when the options are presented.

The Location Preference Question

During ILP, you may have submitted a location preference for your base posting through the Aspire portal or a preference survey. The degree to which this preference is honored varies significantly.

Alumni reports suggest that the base location is approximately 90% based on the preferences you submitted during the NextStep registration process, particularly for pre-mapped associates. However, business requirements can override preferences. If your preferred city has no openings in your ISU at the time of your batch completion, you may be posted to a different location.

Once posted, changing your base location is possible but not easy. You can request a transfer through your RMG manager or through the iJoin portal after completing a minimum tenure on your first project. For freshers, a medical reason (your own or an immediate family member’s) significantly strengthens a transfer request. Without a compelling reason, location transfers for freshers are uncommon in the first year.

Lessons From Past Batches - What Actually Happened

While respecting anonymity, here are composite scenarios drawn from commonly reported experiences across multiple batches that illustrate how the ILP-to-project transition plays out in practice.

The Fast Track Scenario

A CS graduate completed ILP at Trivandrum with a rating of 4, trained in Java, assigned to the BFS ISU, base location Bangalore. Within one week of reporting to the Bangalore office, RMG sent them to two project interviews. The first project was a Spring-based banking application that aligned closely with their ILP training. The interview lasted 20 minutes, primarily discussing their Phase 2 project and their comfort with SQL. They were allocated within three days and started onboarding the following Monday. Total bench time: nine working days. This is the best-case scenario and is more common at large hubs with high project volumes, especially for associates with strong ratings in high-demand ISUs.

The Standard Scenario

An ECE graduate completed ILP at Hyderabad with a rating of 3, trained in .NET, assigned to the Insurance ISU, base location Pune. After reporting to Pune, they waited three weeks before their first project interview. The first interview was for a testing role on a .NET application. They were not selected because the project needed someone with automation testing experience, which was beyond their ILP curriculum. RMG sent them to a second interview two weeks later for a maintenance project on a legacy .NET system. They were selected and started the project. Total bench time: five weeks. This is a typical middle-ground experience for freshers at major hubs.

The Extended Scenario

A mechanical engineering graduate completed ILP at Ahmedabad with a rating of 3, trained in BIPM, assigned to the Manufacturing ISU, base location Kochi. After reporting to Kochi, they found that the Manufacturing ISU had limited project presence at that location. RMG shared their profile with several projects, but the matches were poor. After six weeks, RMG offered them a project in Bangalore in the same ISU. They accepted the relocation, traveled to Bangalore, and were allocated to a data analytics project within a week of arriving. Total bench time: seven weeks. This scenario illustrates how location constraints can extend bench time and how flexibility about relocation resolves the bottleneck.

The Technology Mismatch Scenario

A CS graduate completed ILP at Chennai with a rating of 3, trained in Java, assigned to the Telecom ISU, base location Chennai. Their first project allocation was to a Unix/shell scripting role supporting a telecom billing system. The technology was entirely different from their ILP training. Initial frustration was significant. However, with support from the project team and self-study during evenings, they became proficient in shell scripting within a month and eventually became the go-to person for complex scripting tasks on the team. By their first annual review, they had earned a strong project rating and received a competitive increment. Within 18 months, they transferred to a Java-based development project through iJoin, now equipped with both Java and Unix skills. This is one of the most common trajectories for freshers who experience technology mismatch - initial discomfort followed by skill broadening that creates long-term career advantages.

These scenarios are not exhaustive, but they represent the range of experiences that freshers commonly encounter. The consistent thread across all of them is that the transition period, however it unfolds, is temporary. The career that follows is shaped by what you do once you are on a project, not by how quickly you got there.

Common Mistakes Freshers Make During the Transition

Alumni from multiple batches consistently report the same transition-phase mistakes. Understanding these patterns helps you avoid them.

Mistake 1: Being Passive During the Bench Period

The single most common mistake. Freshers who treat the bench period as an extended holiday - sleeping late, coming to office just to mark attendance, not engaging with learning platforms or RMG - extend their own bench time and make a poor first impression at their base location. Under the new 2025 policy, this passivity has explicit consequences.

The fix is simple: treat every bench day as a working day. Show up on time. Upskill actively. Follow up with RMG. Be visible and available.

Mistake 2: Being Inflexible About Project Type

Freshers who refuse to consider support projects, testing projects, or maintenance work because they only want “development” narrow their allocation pool dramatically. For a freshly trained associate, any project experience is valuable. The distinction between “good” and “bad” projects is far less important at the start of your career than the distinction between having a project and being on the bench.

Mistake 3: Being Inflexible About Location

Some projects require working from a client site in a different city from your base location. Freshers who refuse any relocation limit their options. Being open to short-term or medium-term travel expands the number of projects you are eligible for and directly shortens your allocation timeline.

Mistake 4: Not Preparing for Project Interviews

Even though project interviews for freshers are low-pressure, showing up without being able to articulate what you learned during ILP, what your Phase 2 project was about, or what technologies you are comfortable with reflects poorly. Spend 30 minutes before each project interview reviewing your ILP highlights and preparing a concise professional introduction.

Mistake 5: Ignoring Upskilling During Bench

The technologies used in real projects often extend beyond what ILP covers. Freshers who arrive at project interviews with only their ILP curriculum knowledge are less attractive to project managers than those who have used the bench period to learn additional tools, frameworks, and platforms. Every certification completed and every additional skill learned during bench makes your profile more competitive.

Mistake 6: Not Building Relationships at the Base Location

Your RMG manager, your office colleagues, and the people you meet during knowledge-sharing sessions are all part of your professional network. Freshers who isolate themselves during the bench period miss opportunities for informal project referrals and mentorship. Be social, be approachable, and be known.

Frequently Asked Questions About Project Allocation

Can I request a specific project or client?

You can express preferences to RMG, but allocation decisions are driven by business requirements and availability. Having a specific technology certification or demonstrable skill in an area that aligns with a particular project can increase your chances, but there is no guarantee mechanism for specific project requests.

What if I am rejected in multiple project interviews?

This is normal and not a cause for alarm. Different projects have different requirements, and not every profile matches every opening. RMG will continue sharing your profile with new project opportunities. If you are consistently getting rejected, ask for feedback (from your RMG manager, not directly from the project interviewers) to understand if there are specific skill gaps you can address.

Can I switch projects after being allocated?

Not immediately. TCS expects associates to serve a minimum tenure on their assigned project, typically six months to one year. After this period, you can explore internal transfer options through iJoin. Premature project exits are discouraged and may affect your performance review.

What happens if my base location has no projects in my ISU?

This is a real scenario that some freshers face, particularly at smaller offices. In such cases, RMG may offer you a project at a different TCS location. Your willingness to relocate becomes a significant factor here. If you decline relocation and no local projects are available, you may face an extended bench period.

Does the bench period count toward my service agreement bond period?

Yes. The service agreement bond period starts from your date of joining TCS, which is day one of ILP. The bench period falls within this timeline. You do not need to “restart” the bond clock when you get your first project.

Is it true that ILP toppers get allocated first?

Generally, yes. Associates with higher ILP ratings, particularly those rated 4 or 5, receive priority consideration during the allocation process. However, “first” does not mean “immediately.” Even top-rated associates may wait a few weeks if no suitable project opening is available at their base location in their ISU.

Can I do a personal project or freelancing during bench time?

TCS employment terms require your professional efforts to be dedicated to TCS during working hours. Under the 2025 policy, bench time must be spent on upskilling through approved platforms. Personal freelancing during bench time is not aligned with TCS expectations and could create complications if discovered.

What if I want to resign during the bench period?

You are free to resign at any point, but the service agreement bond applies. If you have not completed the bond period (typically one to two years from date of joining), you will need to pay the bond amount specified in your service agreement. The notice period also applies - TCS requires a three-month notice period. During the notice period, you can only use sick leaves and flexi holidays. These conditions apply regardless of whether you are on a project or on the bench at the time of resignation.

How do I know what projects are available at my base location?

Your RMG manager is the primary source of this information. Additionally, the iJoin portal shows internal openings across TCS, though freshers typically need to complete a minimum tenure before they can formally apply through iJoin. Informally, talking to colleagues and attending knowledge-sharing sessions at your office gives you visibility into what projects are active and what skills are in demand locally.

What happens to my career if I have a long bench period?

Under the pre-2025 framework, bench periods of several months were relatively common and did not necessarily harm your career trajectory - you continued receiving salary and eventually got allocated. Under the new 2025 framework, bench periods exceeding 35 business days annually can affect compensation, career progression, and potentially job continuity. The organizational message is clear: extended bench is no longer an acceptable steady state.

The Post-Allocation First Week

When you are finally allocated to a project and receive your project joining date, the transition happens quickly.

You report to the project team, which may be at your base location office or at a client site. You are assigned a team lead or manager who briefs you on the project context, the technology stack, your role, and the immediate work items. You may be assigned a buddy or mentor from the existing team to help you ramp up.

The first week on a project is an information-dense period. You are learning the project’s domain context (what does the client do, what problem does the application solve), the technical architecture (what technologies are used, how the components interact), the development and deployment processes (version control, CI/CD pipelines, testing frameworks), and the team dynamics (who handles what, how communication flows, what the escalation paths are).

Your ILP knowledge forms the foundation, but the project-specific learning curve is real. Do not expect to be productive from day one. Project teams understand this and build ramp-up time into their planning for new team members. What they do expect is engagement, curiosity, and willingness to learn. Ask questions. Take notes. Request access to documentation and codebase early. Shadow your buddy or senior team members during the first few days to understand the workflow.

The effort you invested during ILP and the bench period pays dividends here. If you used your bench time to learn relevant frameworks, complete certifications, and practice coding, the ramp-up period on your first project will be noticeably shorter. Your project team will see the difference, and it will reflect in your first project performance review.

The Long View

The transition from ILP trainee to project-assigned associate is a brief chapter in what will hopefully be a long and progressive career. The bench period feels significant when you are living through it, but in the context of a twenty or thirty year career, it is a footnote.

What matters far more than the speed of your initial allocation is the pattern you establish during this transition. If you build a habit of proactive engagement, continuous learning, professional responsiveness, and flexibility during the post-ILP phase, you are establishing the same behaviors that drive success in every subsequent phase of your career - project work, team leadership, client management, and eventually senior roles.

The associates who build the strongest careers at TCS are not necessarily those who got the fastest allocation or the best first project. They are the ones who approached every phase, including the uncertain bench period, with discipline and a growth mindset. They learned when they could. They stayed ready. And when the opportunity came, they were prepared to make the most of it.

Complete your ILP strongly, prepare for the transition with the seriousness it deserves, use the TCS ILP Preparation Guide to ensure your fundamentals are solid, and walk into your base location office ready to begin the next phase of your career. The training is over. The real work, and the real growth, starts now.

Pair your ILP preparation with a clear understanding of the post-training landscape described in this guide, and you arrive at your base location with both technical readiness and strategic awareness. You know how RMG works. You know what project interviews look like. You know what the new bench policy expects of you. You know that technology mismatch is normal and manageable. You know that your first project is a starting point, not a permanent assignment. And you know that the habits you build during this transition - proactive engagement, continuous learning, professional responsiveness - are exactly the habits that define successful careers in IT, at TCS and beyond.