CloudSEK has an open SDE Intern - Frontend vacancy in its Core Platform Engineering department. This guide covers the verified requirements, an important duration discrepancy and practical preparation advice. It is an office-attendance opportunity, not a fully remote internship, so check your availability and travel plans before applying.
The employer asks for frontend programming skills, hands-on object-oriented JavaScript, React experience, component decomposition, stateful versus presentational components and CSS architecture. It also lists basic familiarity with HTML5, CSS, Bootstrap and jQuery, alongside understanding of Webpack, Babel and Sass. The listing does not publish a minimum number of professional experience years, a required degree discipline, graduation batch or GPA cutoff.
The location is Bengaluru, Karnataka, India. Applicants must be able to attend the Bangalore office at least four days weekly; the stated working week is Monday to Friday. The fifth day's arrangement is not specified, so do not assume a guaranteed work-from-home day.
The vacancy description states 3–6 months, but a required application question describes a three-month internship. Ask the recruiter to confirm the actual duration before accepting. The form also asks whether you can join immediately. This is a joining-availability question, not a published calendar start date.
The employer mentions competitive salary in its benefits section, but gives no internship stipend or salary amount, currency, payment schedule or conditions. Jobsii therefore labels the amount as undisclosed. Do not use older social posts about another CloudSEK vacancy as proof of this role's pay.
The official vacancy feed and application page were available when checked on 4 October 2026. No application deadline or vacancy count is published. Applications can close without a stated deadline, so reopen the official page before submitting.
The form requests your first and last name, email, phone and resume. The rendered form also includes education information with an end-date year, plus required answers about office attendance and immediate joining. Fill these truthfully; a student who needs college approval should not claim unrestricted availability.
Everything below is independent editorial guidance, not an extra employer requirement or a description of CloudSEK's interview. A useful frontend portfolio example is a small issue-tracking dashboard built with fictional records. Include a list, a detail view, a filter and a simple status change. The goal is to demonstrate decisions you understand rather than a large collection of copied screens.
Describe what you built personally, which parts came from a tutorial and what you changed. Keep the example accessible through a working link or clear repository instructions. If you used generated code, explain how you checked and adapted it. An honest small project is more useful than an impressive application whose behaviour you cannot explain.
Review how your own project handles collections, objects, functions and asynchronous requests. Pick one feature and trace what happens from a user action to the displayed result. Identify where data is transformed and where an error could occur. This gives you concrete examples instead of a memorised list of definitions.
For practice, make a fictional request fail and decide what the interface should show. Then try an empty response and a slow response. Explain these cases in ordinary language before discussing implementation details. You are preparing to reason about software; you are not recreating a disclosed CloudSEK assessment or predicting its questions.
Choose a screen in your project and sketch its component boundaries. Decide which element owns a selected record, which elements merely display information and which action changes the selection. If several components need the same information, explain the approach you chose and why it fits this small example.
Avoid adding a library just to make the tool list longer. Instead, describe the trade-off: what became easier, what became harder and what you would change if the application grew. Include a short diagram in your project notes if that helps communicate the design. These notes are optional preparation materials, not documents requested in the official application.
Check your example at a narrow phone width and a wider desktop width. Look for long labels, large tables, awkward line breaks and controls that are hard to reach. Try using the main actions with a keyboard and ensure important information is not conveyed only through colour.
For a dashboard, consider how a user distinguishes loading, empty results and a failed request. Write plain-language messages and provide a sensible next action where appropriate. Use fictional, non-sensitive data throughout. Do not copy customer screenshots or attempt to connect your demonstration to CloudSEK's production systems merely to make a portfolio look realistic.
Be ready to point out where development and build commands are defined in your project. Explain what a fresh reviewer needs to install and how to start it. If your tooling came from a starter template, say so; you do not need to pretend you configured every dependency yourself.
A short README can include the project's purpose, setup steps, implemented features, known limitations and one design decision. Remove unused commands and check that any shared links point to your own work. Do not expose tokens, private repositories or personal information while preparing a public demonstration. This documentation exercise helps you communicate clearly regardless of the eventual hiring format.
Use concise bullets describing a feature, your contribution and a result you can support. If you improved a layout, explain the issue you addressed. If you worked in a team, distinguish your own responsibilities from the team's overall delivery. Avoid invented performance percentages or claims of commercial scale for a classroom project.
Keep skill labels consistent with what you can discuss. Mentioning familiarity is different from claiming expertise. Where experience is limited, an accessible project and thoughtful explanation can demonstrate learning more clearly than a long list of technologies. This is preparation advice, not a guarantee that any particular portfolio will qualify or secure an interview.
Ask about the exact duration, joining date, compensation, payment timing and any relocation or equipment support. Confirm daily hours, office location and whether all five working days could require attendance. If examinations or coursework overlap, raise that before making a commitment.
The public information does not specify interview stages, a selection test, an application fee or guaranteed full-time conversion. Do not treat these as established terms. Retain recruiter communications and review a written offer before accepting. Jobsii publishes opportunity information and preparation guidance; it is not CloudSEK's recruitment team and cannot guarantee selection.
Review the role details, deadline, and work mode before applying. Jobsii tracks the apply action so candidates can keep application history inside their dashboard.
