Course Content
Scenario-Based AI Engineering Questions
26 sections · 146 lessons
A new user signs up and asks a complex question immediately. No history, no preferences, no profile. How do you bootstrap personalization for a brand-new user?
What you need to know
Personalisation needs a signal. A new user has little, but not zero: the signup form, where they came from, their device, their language, and the question they just typed.
Three layers, in order
- Signup signals and cohorts — role, industry, plan tier, locale, referral source and device map the user to the nearest existing cohort. They inherit that cohort's defaults: answer depth, preferred sources, examples from their industry.
- In-session adaptation — classify the first question's intent and level. Adjust retrieval filters, answer length and technical depth for this session immediately.
- Lightweight explicit feedback — a "more detail / less detail" control or a two-option choice, remembered for next time. One click is a cost most users will accept.
Two or three onboarding questions are acceptable only if each visibly changes the product. "What is your role?" is worth asking if developers then get code examples and managers get summaries.
Signals and what they change
| Signal | Available when | What it changes |
|---|---|---|
| Plan tier, company size | Signup | Which features and documents apply |
| Role (for example "developer") | Signup question | Depth, code examples, jargon level |
| Locale and language | Browser, first message | Answer language, regional rules, currency |
| First question's intent and vocabulary | First message | Retrieval filters, answer depth |
| Clicks on "more detail" | First session | Stored preference for later sessions |
The complex first question
Don't personalise it; ground it. Answer thoroughly, with citations, and consider a more capable model for a user's first few turns. First-session quality strongly affects whether people come back, and at that volume the extra cost is small.
1profile = cohort_defaults(signup) # e.g. {"depth": "medium", "role": "analyst"}2intent = classify(first_question) # e.g. {"topic": "billing_api", "level": "expert"}3session = {**profile, **intent_overrides(intent)} # the question beats the cohort guess4model = "strong" if user.turns < 5 else route(session)The order matters: what the user actually asked overrides what the cohort guessed.
The failure mode to avoid
Cohort defaults that are wrong and invisible feel worse than no personalisation. A developer treated as a beginner because of a signup field will be annoyed and not know why. Show a short "Answers tailored for: analyst, India" note with an edit link.
A real-life example
Scenario (illustrative numbers). A B2B accounting-software company launches an in-app assistant. New users from small businesses often ask a hard first question, such as how to handle GST on exports. In the first month, first-session success, measured as no rephrase and no support ticket within a day, is 54% for new users versus 78% for users older than 90 days.
The team adds two signup questions (role, business type), in-session intent detection, and a stronger model for the first five turns. New-user first-session success rises to 71%. The extra model cost is about ₹9 per new user, and the drop in support tickets from new users pays for it several times over.
Follow-up questions to expect
- "When do you switch to learned, per-user personalisation?" — Once a user has enough interactions to fit a profile reliably; until then, cohort defaults plus session signals win.
- "How do you avoid stereotyping by cohort?" — Keep cohort defaults mild, let the session override them, and make the profile editable.
- "What about privacy?" — Use only signals the user knowingly gave or that the product needs, explain them, and let the user reset their profile.