Merkle Science is accepting applications for a Software Engineer Intern in backend development. This one-year Bengaluru internship is hybrid: three office days and two work-from-home days weekly. Its official recruitment API returned the opening on 2 October 2026. The stipend is governed by company policy; no amount is disclosed.
Eligibility is limited to final-year B.Tech/B.E./Dual Degree students graduating in 2027 from IIT, NIT or IIIT, in CSE, IT or closely related branches. Strong academics and demonstrated coding ability are required. A possible full-time offer for high performers is subject to a two-year service lock-in; conversion is not guaranteed.
Requirements include Python/object-oriented programming, a Python web framework, relational databases, REST design, caching, DSA and Git. Work spans services, APIs, PostgreSQL, Redis, testing and blockchain datasets. Containers, queues, projects, open-source work and AI coding tools are advantages; previous crypto knowledge is unnecessary. Joining date, deadline, vacancies, academic cutoff and required experience years are undisclosed.
The following guidance is independent editorial advice, not additional employer criteria or predictions of its interview process. Start by checking whether your academic calendar permits the proposed commitment. A long internship can affect examinations, project submission and campus attendance. Discuss those constraints with the relevant people at your institution before presenting availability as settled or making plans that depend on an unconfirmed joining date.
Consider the practical cost of attending an office in Bengaluru. A hybrid arrangement still involves regular travel and may require relocation. Estimate accommodation, transport and equipment costs from your own circumstances. Ask the employer for the actual stipend and payment terms rather than using an online estimate. A compensation figure from a different role, year or employer is not evidence of what this position pays.
Choose a small project with a clear purpose, such as maintaining fictional equipment reservations. Identify the records it needs and the actions a user should be able to perform. Explain why you chose particular data relationships and how the application handles invalid input. Keep the first version small enough that you understand every important part rather than assembling many libraries you cannot discuss.
Write a short project note describing the problem, your decisions and a limitation. Explain which work you completed independently and where you adapted an example or received assistance. A reviewer should be able to understand what the application does without reading a large codebase first. Do not describe a classroom prototype as a production system or invent performance measurements to make the project sound more substantial.
For a practice endpoint, describe the request, expected response and possible failure cases before implementing it. Consider missing fields, conflicting updates and requests for records that do not exist. Explain what the client can rely on and what remains outside the example's scope. A consistent contract helps another person use the service without needing to guess how individual endpoints behave.
Use fictional data and a local environment or another system you are authorised to test. Keep credentials out of screenshots and public project files. When discussing your work, distinguish a test that checks a specific behaviour from proof that the whole service is secure or reliable. A small, understandable example with honest limits is stronger evidence than a broad claim unsupported by observation.
Prepare a few questions that your project database should answer. Show which records a query returns and why a relationship is needed. Think about missing values, duplicate records and a request that touches several tables. If you add an index, explain the access pattern it is intended to help rather than saying that indexes automatically improve every operation.
Keep any performance experiment reproducible and modest. Record the sample data, query and conditions under which you observed the result. Do not extrapolate a local test into a claim about handling millions of real transactions. For an application discussion, being able to explain a simple schema and an unexpected query result may be more useful than listing advanced database topics without hands-on evidence.
A practice project can demonstrate a cached read using invented records. Explain what is cached, how long it remains valid and what happens after the underlying data changes. Consider whether an outdated result would be acceptable for the particular feature. A cache adds behaviour to a service; it should have a reason beyond making the technology list on a resume longer.
Think through a failure case where the cache is unavailable. Describe whether the application can continue by reading its main database and what limits that fallback might have. Keep the exercise simple and avoid claiming that it matches the employer's architecture. The useful evidence is your reasoning about consistency and tradeoffs, not an unsupported statement that a tool guarantees speed or availability.
Prepare a readable change description for your project. Explain the problem, resulting behaviour and how someone can check it. Organise changes so another person can follow them without reconstructing every experiment you made. If you have worked with others, identify your contribution and how feedback changed the result. Avoid claiming sole ownership of a team project.
When using AI coding assistance, be prepared to explain the code that you kept. Review assumptions, handle errors you can reproduce and acknowledge parts that remain untested. Do not include private information in public examples or claim independent implementation for generated work you have not understood. Good collaboration includes knowing when to ask a focused question and keeping others informed of unresolved behaviour.
If an offer progresses, ask for written details of the internship and any later employment arrangement. Clarify the conditions governing a potential permanent offer, including the service period and what the employer expects if circumstances change. Do not infer terms that are absent from the listing or rely on a verbal assurance when the commitment affects your future plans.
Review the proposed start date, supervision, office attendance and stipend alongside your academic obligations. Ask questions early enough to make an informed decision. Being shortlisted is not the same as receiving a written offer, and completing an internship does not by itself establish permanent employment. Keep copies of relevant communication and compare the final terms with the vacancy you applied to.
Use the linked application and follow its current instructions. Check your institution, programme, graduation year and contact details for accuracy. Share project links that work and contain only information you are authorised to disclose. Jobsii publishes this opportunity but does not conduct selection or issue offers for Merkle Science. Recheck the vacancy before submitting because an undisclosed deadline does not guarantee continued availability.
Review the role details, deadline, and work mode before applying. Jobsii tracks the apply action so candidates can keep application history inside their dashboard.
