Self-Introduction & Intro Video
Your opening sixty seconds set the tone for the entire interview. Pick the script length that matches the format, rehearse it out loud, and record yourself on your phone to refine your pace and energy.
Everything below is built on three real systems you can discuss at architectural depth. The scripts introduce them; the deep-dive reference is what you say when the interviewer stops you and asks for more.
Framing note — understanding a system and owning it are two different claims. You can explain all three of these end to end, which is genuinely rare, so lead with it. But keep the ownership line clean:
The 1Finance website and platform APIs — team contributor across the platform. Over three-plus years you have worked across product scoring and ranking, the financial calculators and the admin dashboard. Lead with those surfaces rather than a list of internal module names.
India HR Conclave — contributor. You did not design the ledger, the outbox or the saga. Say "I worked on" and "the design is X, and here is why I think it is right" — never "I built" or "I designed."
Describe it accurately, too: it is a gated community platform for HR professionals that happens to have a points feature, not "a rewards platform." Leading with the rewards undersells the product and invites the wrong questions.
Scope framing — name surfaces, not modules
Three-plus years is long enough that the interviewer is listening for blast radiusrather than activity. A list of four internal module names sounds like four small features, and worse, those names mean nothing outside the building, so nobody in the room can tell whether they were hard. Naming the product surfaces you have worked across — product scoring and ranking, the financial calculators and the admin dashboard — describes the same work at the scale it actually happened.
It is also more honest in both directions. You are not claiming to have designed the scoring engine; you are saying you have worked across it. That is true, it matches your tenure, and it invites exactly the follow-up you can answer.
Then have one concrete example ready for each surface. Breadth with nothing specific behind it sounds like you were nearby while other people worked. The pattern that lands is simple: name the surface, name one thing you personally shipped inside it, then stop and let them choose which thread to pull.
Timing maths — why these scripts are the length they are
Interview pace is roughly 150 words per minute, slower than casual conversation because you are pausing between sentences. So 60s ≈ 150 words, 90s ≈ 225 words and 2min ≈ 300 words. Every script below shows its real word count and the duration that implies, so you can confirm you are not overrunning before you are in the room.
Running long is the most common self-introduction failure. You spend two minutes on a question that wanted forty-five seconds, the interviewer stops listening around the ninety-second mark, and your best material lands in the part they tuned out. When in doubt, use the shorter script and let them ask for more — being asked a follow-up is a far better outcome than filling the silence yourself.
Dense technical phrases cost more time than 150 wpm suggests. "Loosely coupled via Kafka events and a transactional outbox" needs a beat after it, or the listener falls behind. If a script feels rushed in rehearsal, cut a system rather than speaking faster.
The 60-Second Script (Most Common)
HR screens, recruiter calls, panel round-robins • target 60s • this script is 131 words ≈ 52s at 150 wpm
"Hi, I'm Arvind Sharma. I'm a Full-Stack Engineer with around six years of experience, currently working with NeoSOFT on fintech products for 1Finance.
My experience spans both frontend and backend development, primarily with Next.js, React, Go, PHP, WordPress, PostgreSQL, and REST APIs. In my current role, I've worked across different parts of the platform, including financial calculators, product scoring and ranking, backend APIs, CMS integrations, and admin dashboards.
I've also contributed to the India HR Conclave platform, working with Go-based microservices and event-driven architecture using Kafka and PostgreSQL.
Earlier, I worked extensively with WordPress and WooCommerce, including custom development and payment integrations.
Now, I'm looking for a role where I can take greater ownership, contribute to architecture and technical decisions, and work more deeply with Go, Next.js, and scalable backend systems."
Recruiter variant: drop the architectural detail from the third paragraph entirely. "A private network for HR professionals, with a points feature that pays out vouchers" is the whole sentence. A recruiter is screening for fit and clarity, not for Kafka.
The 90-Second Script (Senior / Detailed)
Engineering managers, senior IC screens • target 90s • this script is 217 words ≈ 87s at 150 wpm
"Hi, I'm Arvind. I'm a Full-Stack Engineer with around six years of experience, and I've been working with NeoSOFT on 1Finance since January 2023.
In my current role, I work across multiple production systems, with a strong focus on Go, Next.js, PostgreSQL, WordPress, and REST APIs. One of our main platforms is a server-rendered Next.js application that integrates Go APIs, WordPress, and taxation services. I've worked across most of the platform, including product scoring and ranking, financial calculators, APIs, and the admin dashboard.
From an engineering perspective, I've also been involved in areas like security, authentication, authorization, A/B testing, and backend architecture. Our backend consists of multiple Go and Fiber services behind an API gateway, with shared infrastructure and database components.
I also contribute to the India HR Conclave platform, which uses nine Go services, Kafka, and a transactional outbox for asynchronous workflows. Since its points represent real monetary value, we use an append-only ledger and idempotency to maintain consistency and prevent duplicate transactions.
Earlier in my career, I worked extensively with WordPress and WooCommerce, including custom development and payment integrations.
At this stage, I'm looking for a Senior Engineer or Tech Lead opportunity where I can take broader ownership of architecture, technical decisions, implementation, and production reliability, while continuing to work deeply with Go and Next.js."
The 2-Minute Script (Walkthrough Style)
Tech leads, founders, final rounds • target 2min • this script is 319 words ≈ 128s at 150 wpmBeats sum to 127s — 17 + 35 + 30 + 32 + 7 + 6.
Click to expand
Opening (17s): "Hi, I'm Arvind Sharma — a full-stack engineer with six years' experience, currently at 1Finance through NeoSOFT. Mostly Go on the backend and Next.js on the front. There are three systems, and I can take you through any of them end to end."
The website (35s): "The public website is a server-rendered Next.js app that holds no data of its own — each of roughly fifty routes assembles its page at request time from our Go APIs, a WordPress CMS and the taxation services, inside getServerSideProps. The edge middleware is where most of the judgement sits: CSP and HSTS headers, origin-allowlist CORS, regex 301s that repair legacy fund slugs still sitting in Google's index, and 50/50 A/B bucketing that writes the cookie onto the inbound request, so the first server render already reads the variant."
The platform APIs, and where I fit (30s): "Behind it sit four Go and Fiber services that share database, auth and crypto packages through go.mod replace, all fronted by a path-prefix reverse proxy. There are two Postgres databases — our own store, plus a read-only vendor fund database whose absence degrades to stored values instead of failing at boot. Over three-plus years I have worked across most of that platform: product scoring and ranking, the financial calculators, and the admin dashboard our analysts work in."
The community platform (32s): "The third is India HR Conclave, a gated community for HR professionals, where I am a contributor. Nine Go services behind a Fiber API gateway, loosely coupled via Kafka events and a transactional outbox, so emails and point credits run off the request path. Points are a rupee each, so balances are a cache over an append-only ledger with row locks, idempotency keys and a trigger that blocks mutation. I didn't design that, but I can defend every piece of it."
Before this (7s): "Before 1Finance, WooCommerce with payment gateway integration at Thinkbar, and WordPress at Visualytes, working directly with clients."
What I want next (6s): "Deeper architectural ownership, Go-native engineering, and enough Next.js scope to keep growing on the frontend."
The Three Systems — Deep-Dive Reference
The scripts are the surface. This is the layer underneath: the sentence you say, and the follow-up it invites. If you can answer the questions below without hedging, then "I can explain any of it" is a claim you can genuinely make.
1 · The 1Finance website
Next.jsPages RouterReactServer-side renderingEdge middleware
A server-rendered marketing and financial-tools site covering the calculators and mutual-fund product scoring. It holds no data of its own: every route assembles its page at request time from the Go gateway, a WordPress wp-json CMS and the taxation services inside getServerSideProps, across roughly fifty routes plus eight sitemap endpoints generated at request time, all under a global no-store policy. The edge middleware emits CSP and HSTS headers, applies origin-allowlist CORS, repairs legacy indexed fund slugs with regex 301s, and performs 50/50 A/B bucketing. There is no user session — OTP gates enrollment, and internal endpoints use static bearer tokens. Tests run on Jest and Testing Library; Jenkins runs SonarQube and then deploys over SSH to PM2, one target per branch. The interface is built with CSS Modules, Bootstrap, MUI, Framer Motion, Highcharts and react-three-fiber.
Likely follow-up questions
- Why does the site hold no data of its own?
It is a composition layer. Data ownership stays with the Go services and the CMS, so there is one source of truth per domain and no synchronisation problem. The cost is real, though: every page pays for request-time fan-out, and an upstream outage becomes a page outage. - A global no-store policy on a marketing site is expensive. Why?
It is deliberate — calculator output and fund scores must never render stale. Freshness beats cacheability here. The honest addition is that the marketing pages do not need it and are the obvious candidate for per-route caching; say that before they do. - Why write the A/B cookie onto the inbound request rather than just the response?
A cookie set only on the response is invisible to the render that set it, so the first paint shows the default variant and only flips on the next navigation. Mutating the inbound request lets the same server render read it, which removes both the flash of the wrong variant and any client-side re-render. - Why regex 301s in middleware instead of static redirects in the config?
The legacy fund slugs were already indexed by Google. One regex at the edge repairs an entire slug family and preserves the link equity, instead of shipping and maintaining hundreds of individual redirect entries. - How does CSP survive Highcharts and react-three-fiber?
Those are the two awkward ones — inline styles from the charts, shader source from the 3D layer. Be ready to name exactly which directives you had to relax, and to say the relaxation was scoped rather than a blanket unsafe-inline. - With no session, what is actually protected?
There is nothing user-facing to log in to. OTP gates the enrollment flows, and internal endpoints use static bearer tokens. That is a smaller attack surface, not an absent one.
2 · The 1Finance platform APIs
GoFiberGORMPostgreSQLDocker Compose
Four Fiber services sit behind a path-prefix reverse-proxy gateway, each a separate module sharing the database, auth and crypto packages through go.mod replace, with a Next.js and MUI admin console alongside them. There are two GORM PostgreSQL databases: the application store, plus a read-only vendor fund database whose absence degrades to stored values instead of failing at boot. Fund catalogues load from analyst Excel workbooks — mapped by reflection, upserted by ISIN in batches, and written in the same transaction as their audit row. Credit-card ranking runs as SQL window functions over a weights table. Type-ahead search fans out nine goroutines under a 200 ms deadline and returns partial results. Auth is HS256 JWTs with mandatory TOTP, and scopes are revalidated against the database on every request. Rate limiting is a token-keyed sliding window behind trusted-proxy checks; integration tests run against in-memory SQLite; and golangci-lint runs at pre-commit.
Likely follow-up questions
- Why does a missing vendor database degrade rather than fail at boot?
It holds third-party read-only data. A vendor outage should cost freshness, not availability, so we serve the last known stored values. The risk is silently stale prices, which is why the staleness has to be visible rather than swallowed. - Why map the Excel import by reflection instead of by column index?
Analyst workbooks change column order between releases. Mapping by header through struct tags survives that, whereas index-based parsing corrupts data silently. ISIN is the natural key, so rows upsert in batches, and the audit row is written in the same transaction — an import can never be recorded as having happened when it did not. - Nine goroutines, a 200 ms deadline, partial results — what is the contract?
The deadline belongs to the user, not to the slowest source. One shared context deadline drives an errgroup, each fan-out writes into its own slot so there is no shared-map race, and any source that misses the deadline simply loses its section of the results. - Why revalidate scopes on every request instead of trusting the JWT?
A signed token cannot be un-issued, and access lists change mid-session. One indexed read per request is easier to reason about than a revocation list, and it means an admin demotion takes effect on the very next call. - Why key the rate limiter on the token and also check for a trusted proxy?
Keying on IP alone punishes everyone behind a shared NAT, while keying on the token alone lets an unauthenticated flood straight through. The trusted-proxy check is what stops a spoofed X-Forwarded-For header from choosing its own bucket. - In-memory SQLite for integration tests — name the gap before they do.
SQLite does not faithfully reproduce PostgreSQL window functions, so the credit-card ranking is precisely the code those tests cover least. Raising it yourself reads as engineering judgement; letting them find it reads as a hole.
3 · India HR Conclave (contributor, not author)
GoFiberKafkaPostgreSQLRedisS3Next.js / React
A community platform for HR professionals, built as a Go monorepo whose Fiber API gateway reverse-proxies nine microservices, with a Next.js, React and Tailwind admin dashboard over PostgreSQL and GORM, plus Kafka, Redis, Docker and S3. It is event-driven by design: services are loosely coupled through Kafka events and a transactional outbox rather than direct calls, so emails and point credits run off the request path. It is secured with audience-separated JWTs, Google OAuth for members, TOTP two-factor authentication for admins, and role-based permission middleware. Money moves through an append-only ledger with row locks, idempotency keys and a mutation-blocking database trigger, alongside a saga with compensating transactions for third-party redemptions. Member PII is deterministically encrypted at rest so that unique indexes still work. Rate limiting, circuit breakers, metrics and audit logging run throughout, and integration tests execute against a Testcontainers PostgreSQL instance.
Likely follow-up questions
- Why use an outbox instead of publishing to Kafka directly?
A direct publish can succeed while the surrounding transaction rolls back, at which point you have invented an event for state that does not exist. Writing the event inside the same transaction as the state change makes them a single atomic fact, and the relay is then responsible only for delivery. - At-least-once delivery means duplicates. What actually protects the money?
Not the consumer — the ledger. Every movement carries a deterministic idempotency key with a unique constraint behind it, so a replayed event becomes a no-op at the database rather than a second credit. - Why append-only with a trigger, rather than simply updating a balance?
The balance is a cache over the ledger, so the history stays reconstructible and auditable. The trigger that blocks UPDATE and DELETE defends the paths that are not code — a future migration, a console session, a well-meaning script. - What does the saga compensate once the voucher has already been delivered?
You cannot un-send a voucher, so the compensation is financial rather than physical: debit the amount back and flag the case for reconciliation. Say that plainly — it shows you understand that a saga does not actually give you rollback. - Deterministic encryption leaks equality. Why accept that?
Because that is the point: identical plaintext must produce identical ciphertext, or a unique index on an encrypted email address cannot exist. It is an acceptable trade for high-cardinality PII, and the wrong call for a low-cardinality column where equality leakage would reveal the value itself. - Why separate the JWT audiences?
An admin token must not be replayable against the member API. Separate audiences turn that into a validation failure rather than a policy question. Members authenticate through Google OAuth, and admins carry mandatory TOTP on top. - Testcontainers here but SQLite on the other system — why the difference?
Because this system's correctness lives in triggers, row locks and constraints, and none of those exist in a SQLite stand-in. Draw the contrast out loud; it shows you choose a test strategy from what the code actually depends on.
Before you rehearse: two rules
1 · Name your own contributions on the community platform. "I contribute" is vague, and vague invites "so what did you do?" Have two or three specifics ready — an endpoint or service you wrote, a bug you traced, a review queue or dashboard page you shipped, a migration you ran, tests you added. The sentence then becomes "I worked on X and Y there," followed by the observation about the system, which is far stronger than the observation on its own.
2 · Explaining a design is not the same as claiming it. Knowing why the ledger is append-only is worth saying, and you should say it. But say it as "that is the existing design, and here is why I think it is right," not as your own decision. The honest version demonstrates exactly the same understanding and survives the follow-up. The claim does not.
If a question goes past what you know, say where your knowledge stops and what you would check: "I know the relay is at-least-once. I haven't traced how it handles a partition mid-batch — I would read the relay loop." That answer costs you nothing. A confident guess that unravels costs you the round.
Recording Your Intro Video
Setup checklist
- Good lighting — face a window, or use a ring light
- Camera at eye level — stack books under the laptop
- Clean background — a neutral wall or a tidy bookshelf
- An external mic if possible — phone earbuds beat a laptop mic
- Wear a collared shirt or smart casual
Delivery tips
- Smile as you say your name — it sets a warm tone
- Speak at around 150 words per minute, slightly slower than conversation
- Pause for a second between sentences rather than rushing
- Pause after each system name, not mid-sentence — three systems in sixty seconds only works if the seams are audible
- Look at the camera lens, not at the screen
- Time yourself, and if you overrun, cut a system rather than a sentence from the ending
Variations by Interview Type
HR / recruiter screen
Use the 60-second script with the recruiter variant. Cover years of experience, current role, motivation for moving, and one or two highlights. Say "a website, the APIs behind it, and a community platform" rather than naming Kafka, outboxes or ledgers — a recruiter is screening for fit and clarity, not architecture.
Technical screen / engineering manager
Use the 90-second script. Lead with breadth across the platform — scoring and ranking, the calculators, the admin dashboard — and then let them choose which one to open up. Introduce the community platform as where your systems thinking grew, explicitly as a contributor. Engineering managers are calibrating scope, and after three-plus years, breadth across product surfaces is the answer that matches the tenure; a list of small modules is the answer that undercuts it.
Tech lead / senior IC interview
Use the two-minute script, and expect them to interrupt you partway through — that is the goal. The three richest stopping points are the A/B cookie written onto the inbound request, the vendor database that degrades instead of failing at boot, and the pairing of the outbox with idempotency keys. Each carries a real trade-off you can name, and naming trade-offs is what separates "I have read about this" from "I work in this."
Founder / CTO interview (smaller companies)
Lead with product impact and shipping speed, and mention working directly with clients at Visualytes. Emphasise that you work end to end across the stack and can move between a Next.js render path and a Go service in the same day — smaller companies are buying breadth and autonomy more than depth in any single layer.
Common Opening Questions & How to Bridge
"Tell me about yourself"
Use the 60- or 90-second script. Don't recite your resume from top to bottom — give the three-system highlight reel and stop. Silence after sixty seconds is fine; they will ask.
"Walk me through your resume"
Go in reverse chronological order and spend about seventy percent of the time on your current role at 1Finance through NeoSOFT, grouping the earlier roles briefly. Be precise about scope: "I am a team contributor — here is what I have personally shipped," and separately, "here is a system I contribute to and can explain end to end."
"Why are you looking to switch?"
"I have grown a lot at 1Finance — from writing endpoints to working across whole product surfaces. I am looking for deeper architectural ownership and a Go-native engineering culture, ideally with stronger Next.js scope so I keep growing on the frontend too." Never criticise your current employer.
"What is a feature you are proud of?"
Answer with one concrete thing inside a surface rather than the surface itself. This question always ends in a depth probe, and "the scoring engine" is too big to defend, whereas "the ranking query, and why it is a window function rather than application-side sorting" is exactly the right size. Pick something you personally wrote or fixed, say what was hard about it, and stop. Save the community platform for "what is the most interesting system you have worked in" — a different question, and one you can answer honestly as a contributor.
"What is the most interesting system you have worked in?"
This is the India HR Conclave question, and the one the deep-dive reference is built for. Open with the product — a gated community for HR professionals — and then give the single design fact that makes it interesting: nine services loosely coupled through Kafka events and a transactional outbox, so every cross-service effect is published rather than called. Then let them pick which thread to pull.
"Which of these did you actually build?"
This is the question you want. Answer it directly and without discomfort: on the 1Finance platform you have shipped across scoring and ranking, the calculators and the admin dashboard over three-plus years, and the community platform is one you contribute to and understand thoroughly. Then add what that understanding gave you — "working in a system where the currency is real money changed how I think about idempotency" — which is a truthful claim about your growth rather than your authorship.