Institute of Advanced Research Students: Ethical Habits for Java Interns Handling Company Data

Ethical Java interns treat every line of company code, every database row and every password as someone else’s property until they are told otherwise in writing. In practice that means four habits: keep code off public repositories, use fake or masked test data, never hard-code credentials, and check an open-source licence before you copy anything. This guide gives you the do’s and don’ts, a scenario quiz, a 14-day habit plan and a checklist to use on your own work.

Why a Java intern’s ethics matter more than the size of the task

Enterprise Java work usually sits close to money, identity or operations: banking back ends, ERP modules, logistics services, hospital systems. Even a small bug-fix task gives you access to class files, configuration, logs and sometimes a database copy. A mistake with any of these is rarely a “student error” in the eyes of a company. It can be a contract breach, a data-protection issue or a security incident.

India’s Digital Personal Data Protection Act, 2023 sets duties for organisations that handle personal data. As an intern you are not the legal data fiduciary, but you can still be the person who leaks the data. Treat any real customer information as regulated, and ask your supervisor what the organisation’s policy is rather than guessing.

A short internship is also where your habits get set. A student who learns in week one to ask “am I allowed to share this?” will do the same at a full-time job.

Confidential code: what is yours, what is not

Code you write during an internship is normally owned by the organisation or its client, not by you. Whether you may show it in a portfolio depends on what you agreed to. Many offer letters or onboarding forms include a confidentiality or non-disclosure clause. Read it before you start, not after.

Do

• Ask in writing: “May I describe this project on my CV, and may I show any code?” Keep the reply.
• Keep company code only on devices and repositories the company has approved.
• Describe your work by outcome (“built a REST endpoint with input validation and unit tests”) rather than by client name or internal architecture, unless cleared.
• Recreate a small, generic version of a technique from scratch for your portfolio, using your own invented domain.

Don’t

• Push company or client code to a personal or public GitHub, GitLab or Bitbucket repository, even a “private” one that the company did not create.
• Paste proprietary code, stack traces with internal hostnames, or schema details into public forums, chat tools or AI assistants that the company has not approved.
• Take screenshots of internal dashboards, IDE windows or logs for social media.
• Email code to your personal address “to work from home”.

Test data: real rows do not belong on your laptop

Developers are often tempted to ask for a production dump because it is the fastest way to reproduce a bug. As an intern, that shortcut is not yours to take. Real names, phone numbers, Aadhaar-like identifiers, account numbers and addresses are personal data.

Do

• Use synthetic data generated by a library or script, with obviously fake values such as test.user1@example.com.
• If you must work from a real extract, ask your supervisor whether it has been masked or anonymised and who approved it.
• Delete local copies of any shared dataset when the task ends, and confirm that with your supervisor.
• Check logs: make sure your logging statements do not print full request bodies containing personal data.

Don’t

• Request production database access just to make debugging easier.
• Commit SQL dumps, CSV exports or .xlsx samples into version control.
• Use real people’s details in unit tests, demos or screenshots.

Credentials and secrets: the habit that prevents the most damage

Leaked keys are one of the most common ways a small mistake becomes a large incident. Automated bots scan public repositories for secrets, so a key committed even for a few minutes should be treated as exposed.

Do

• Load secrets from environment variables, a secrets manager or a configuration service the team already uses, not from source files.
• Add .env, local application-*.properties and key files to .gitignore before your first commit.
• Use the minimum access you need, and ask for read-only access when read-only is enough.
• If you commit a secret by mistake, tell your supervisor at once so it can be rotated. Deleting the file in a later commit does not remove it from history.

Don’t

• Hard-code database passwords, API keys or tokens in Java classes or application.properties.
• Share your login with a teammate to “save time”.
• Store passwords in chat messages, sticky notes or shared documents.

Illustrative snippet of the safer pattern:

// Illustrative only
String dbUrl = System.getenv("APP_DB_URL");
String dbUser = System.getenv("APP_DB_USER");
String dbPass = System.getenv("APP_DB_PASS");
if (dbUrl == null || dbPass == null) {
    throw new IllegalStateException("Database settings are missing");
}

Open-source licensing: copying code is not free of conditions

Java projects rely heavily on libraries from Maven Central and GitHub. “Public” does not mean “free to use however you like”. Each library has a licence that sets conditions, and a company may have rules about which licences are acceptable.

This table is a general orientation, not legal advice. The company’s legal or engineering lead decides what is acceptable.

Do

• Add dependencies through the build file (Maven or Gradle), so they are visible and reviewable.
• Note the licence of any new library in your pull request description.
• Credit sources in comments when you adapt an approved snippet.

Don’t

• Paste large blocks from Stack Overflow, blogs or GitHub into company code without checking the terms.
• Bring code from a previous employer, college project or another client into the current one if it was not yours to share.

Scenario quiz: five situations Java interns actually face

Pick your answer before reading the suggested one. These scenarios are illustrative.

1. Your internship is ending and your supervisor praised your payment-service module. You want it on your public GitHub. Best response: do not upload it. Ask in writing whether a sanitised, generic version is allowed, or rebuild a similar service with invented requirements.
2. A bug only appears with real customer data. A teammate offers to send you a database export on a pen drive. Best response: decline the export, and ask for a masked extract approved by the data owner, or reproduce the bug with synthetic rows.
3. You notice that a teammate committed an API key to the shared repository. Best response: tell the supervisor or security contact immediately so the key can be rotated. Do not try to quietly fix history yourself.
4. You find a perfect utility class on GitHub with no licence file. Best response: do not copy it. Look for a library with a clear licence, or write your own implementation.
5. You want help from a public AI chatbot and plan to paste a failing service class with real table names. Best response: check the company’s policy first. If unclear, strip identifiers or write a minimal, invented example that shows the same problem.

Worked illustrative example: handling one bug-fix task end to end

Imagine you are asked to fix a null-pointer error in an invoice-generation service. This is an invented case.

1. Access: you request read access to the repository and a development database, not production.
2. Data: you write a script that inserts five fake customers and three invoices using example.com emails.
3. Reproduce: you write a JUnit test that fails with the null customer address.
4. Fix: you add a validation check, and the test passes locally.
5. Secrets check: before committing, you search your diff for passwords, tokens and hostnames, and confirm that .env is ignored.
6. Dependencies: you wanted a small string-utility library, but its licence is GPL, so you ask your supervisor and use the existing Apache Commons dependency instead.
7. Handover: you note in the pull request that only synthetic data was used, then delete your local test dump.

The intern’s pre-commit ethics checklist

A 14-day plan for building these habits

A free two-week internship such as the CareerSwami free two-week online internship is a good place to practise, because you can build habits before a paid role puts real data in front of you. Here is a plan for any 14-day Java internship.

CareerSwami offers the internship free of charge, with a free offer letter and a free completion certificate after successful completion. It does not promise a stipend, academic credit or a job.

For IAR Gandhinagar Java students: what is and is not confirmed about internships and data ethics

If you study at the Institute of Advanced Research, your likely route into Java work is through the School of Computing and Technology, which lists B.Tech (CE and IT), BCA, MCA, M.Sc. IT and other programmes. The academic programmes page describes the B.Tech as a four-year, eight-semester course. Check the current version of both pages, since these are excerpts.

The placement cell page describes the Career Advancement Cell as the bridge between recruiters and students, and lists incorporating industrial training in all academic programmes among its objectives. The same page shows placement achievements only as images and gives no figures, internship rules or credit details in text. So there is no published rule you can rely on for questions such as whether an outside internship counts for credit, what paperwork the university needs, or who owns work done for an external company.

The academic calendar lists 2026 odd-semester activities, including orientation on 6 July and first-year inductions in July, but the excerpt does not show semester break dates. If you plan a 14-day internship, do not assume a gap in your timetable.

Because the data-handling terms will come mostly from the host company and not from the university, your own paper trail matters. Use these steps:

1. Ask the Career Advancement Cell, in writing, whether an online internship needs prior approval and what documents it expects.
2. Ask your department coordinator whether an internship can count for credit or only appear as extra-curricular, and get the answer by email.
3. Request the confidentiality or NDA wording from the host organisation before day one, and read it fully.
4. Ask your internship supervisor which repository, tools and AI assistants are approved, and whether portfolio use is allowed.
5. Check the current academic calendar for exams and breaks overlapping your 14 days.
6. If your final-year project report will use internship material, ask your guide and the company whether that material may be disclosed.

What to do when you realise you have already made a mistake

• Report fast. Early disclosure usually limits damage; hiding a leaked key or data file makes it worse.
• Give facts. State what was exposed, where, for how long and who might have seen it.
• Do not erase evidence. Avoid force-pushing or deleting repositories before the team decides how to respond.
• Follow instructions. Let the company rotate credentials, notify affected parties and decide next steps.
• Learn. Add the cause to your checklist so it does not repeat.

Frequently Asked Questions

Can I put my internship project on my public GitHub profile?

Only if the company or client has said yes in writing. If not, build a separate, generic project that demonstrates the same skills using invented data and your own code.

Is a private personal repository safe for company code?

No. A private repo is still outside the company’s control, and it may breach your confidentiality terms. Use only the repositories the company provides.

What counts as real data in a test?

Any information relating to an identifiable person, such as names, phone numbers, emails, addresses, account or government ID numbers. Even partial or lightly altered values can be risky, so prefer fully synthetic records.

I accidentally committed a password. Is deleting the file enough?

No. The secret stays in version history and may already have been copied. Tell your supervisor so the password or key can be changed, and then follow the team’s process for cleaning history.

Can I use code from Stack Overflow or GitHub in my internship work?

Only if the licence or site terms allow it and the company’s policy permits it. Small ideas are different from copied blocks. If you are unsure, write it yourself or ask your supervisor.

Are GPL libraries always forbidden?

Not always, but they can create source-sharing obligations depending on how they are used. Many companies restrict them. Never add one without approval from someone responsible for licensing.

Does IAR have a published rule on internship confidentiality?

No such rule has been verified in the university’s published pages reviewed for this guide. Ask the Career Advancement Cell and your department in writing, and rely on the host company’s agreement for data-handling terms.

Does the free CareerSwami internship give academic credit?

CareerSwami does not promise academic credit. It offers a free two-week online internship with a free offer letter and a completion certificate. Check with your department whether it can be recognised.

Related Java & Enterprise Software guides

• XIM University Students: Java Internship Opportunities for Business and Management Majors
• Rama Devi Women's University: Finding and Asking for a Java Internship Mentor
• North East Frontier Technical University: Low-Bandwidth Habits for Remote Java Internships
• All Java & Enterprise Software internship guides