Zoho, Freshworks & Postman: ML / Engineering

from collections import Counter
def top_k(nums, k):
    c = Counter(nums)
    return [x for x, _ in sorted(c.items(), key=lambda kv: (-kv[1], kv[0]))[:k]]
print(top_k([4, 1, 1, 2, 2, 3], 2))   # [1, 2]

• A sort with the key (−frequency, value) is O(n log n). For large n and small k, use a heap with the same tuple ordering. State how ties are handled before you code.

• Entities: Train, Coach and Berth, Booking (CONFIRMED / RAC / WL), Passenger.
• Logic:
• Book: if a berth is free → CONFIRMED; else if RAC slots remain → RAC (two passengers share a side-lower berth); else → WL queue.
• Cancel a confirmed ticket: the first RAC passenger is promoted to CONFIRMED (gets the berth), and the first WL passenger moves to RAC.
• Cancel RAC: promote the first WL passenger to RAC.

from collections import deque
class Train:
    def __init__(self, berths, rac):
        self.free, self.rac_cap = list(range(berths)), rac
        self.conf, self.rac, self.wl = {}, deque(), deque()
    def book(self, pid):
        if self.free: self.conf[pid] = self.free.pop(); return "CNF"
        if len(self.rac) < self.rac_cap: self.rac.append(pid); return "RAC"
        self.wl.append(pid); return "WL"
    def cancel(self, pid):
        if pid in self.conf:
            berth = self.conf.pop(pid)
            if self.rac:
                self.conf[self.rac.popleft()] = berth
                if self.wl: self.rac.append(self.wl.popleft())
            else: self.free.append(berth)
        elif pid in self.rac:
            self.rac.remove(pid)
            if self.wl: self.rac.append(self.wl.popleft())
        elif pid in self.wl: self.wl.remove(pid)

• Discuss: concurrency (locking per train and date), persistence, berth preferences, and charts.

• Token + positional embeddings → N layers of multi-head self-attention (each token weighs all the others) + feed-forward network, with residual connections and layer norm.
• Encoder-only (BERT) for understanding; decoder-only (GPT) for generation with a causal mask; encoder-decoder (T5) for sequence-to-sequence tasks.
• Why it works: parallel training, long-range context, and scaling with data and compute (pre-training then fine-tuning).

• Ingest: a stateless HTTP/gRPC API → validate → write to a partitioned log (Kafka, keyed by workspace or monitor ID for ordering).
• Process: a consumer group of stream processors (aggregations, alert rules) with exactly-once or idempotent writes; windowed metrics (p95 latency per monitor).
• Store: a time-series DB for metrics, an OLAP store (ClickHouse) for analytics, Redis for the latest status.
• Alerting: a rule engine + notification fan-out with deduplication and rate limits.
• Scale and reliability: back-pressure, DLQs, autoscaling on consumer lag, multi-AZ deployment.

• Features: reply suggestions (RAG over the KB + past tickets), ticket summarisation, auto-triage (category, priority, sentiment), a customer-facing bot with handoff.
• Multi-tenant concerns: strict tenant isolation in retrieval, per-tenant configuration, cost controls, model routing by plan tier.
• Quality: acceptance rate of suggestions, resolution time, CSAT; an evaluation set per vertical.
• Safety: PII redaction, no cross-tenant leakage, agent approval before sending.

• Zoho: "I like that Zoho builds its own stack end to end, including private AI (Zia) running on its own infrastructure. That privacy-first approach matters to business customers, and owning the full stack means deep engineering problems."
• ML: connect it to a real problem you solved, and to what you want to build next (for example, document intelligence for Zoho's business apps).