Technical Skills & Tools Inventory Questions

Be ready to discuss the specific tools, platforms, and technologies you have hands-on experience with in your own domain. Examples: programming languages, frameworks, or cloud/CI-CD tooling for engineering roles; SQL, Excel, Tableau, Power BI, or Looker for data and analytics roles; CRM and marketing automation platforms such as Salesforce, HubSpot, or Marketo for marketing and sales roles; or project and collaboration tools such as Jira and Confluence. For each tool, be specific about what you actually did with it (built a workflow, wrote a query, created a dashboard, configured an integration, resolved a production issue), not just 'familiar with it.' Quantify the outcome where you can (time saved, accuracy improved, adoption increased, cost reduced). If you lack a tool the role expects, describe how you approach learning new technical systems quickly, with a concrete example of a platform you picked up on the job.

EasyTechnical

76 practiced

In Power Query (Excel or Power BI), list the exact sequence of transformations you'd apply to standardize email addresses and remove duplicates. Mention specific functions/steps like Trim, Lowercase, Replace, Remove Duplicates, and how you'd handle malformed emails or common aliases (e.g., user+tag@example.com).

Sample Answer

Approach: create a normalized email column (trim, lowercase, remove display names/quotes, strip +aliases, fix common separators), validate/filter malformed rows, then deduplicate on the normalized value.

Example Power Query (M) steps and functions:

1) Trim whitespace and remove surrounding quotes/display names- Add Column -> Custom:

Normalized1 = Text.Trim([Email])

- Remove quotes, angle brackets or display name patterns:

Normalized2 = Text.Replace(Text.Replace(Normalized1, """", ""), "<", "")
Normalized2 = Text.Replace(Normalized2, ">", "")

2) Lowercase

Normalized3 = Text.Lower(Normalized2)

3) Split local and domain; remove +aliases in local part

Parts = Text.Split(Normalized3, "@"),
Local = if List.Count(Parts)=2 then Parts{0} else "",
Domain = if List.Count(Parts)=2 then Parts{1} else "",
LocalNoAlias = Text.BeforeDelimiter(Local, "+", Local)  // returns whole local if no +
NormalizedEmail = if Domain<>"" then LocalNoAlias & "@" & Domain else null

4) Fix common malformed characters (spaces, commas instead of @)

NormalizedEmail = Text.Replace(NormalizedEmail, " ", "")
NormalizedEmail = if Text.Contains(NormalizedEmail, ",@") then Text.Replace(NormalizedEmail, ",", ".") else NormalizedEmail

5) Basic validation flag

IsValid = (NormalizedEmail <> null) and Text.Contains(NormalizedEmail, "@") and Text.Contains(Text.BeforeDelimiter(NormalizedEmail,"@"), ".") = false and Text.Length(Text.BeforeDelimiter(NormalizedEmail,"@"))>0 and Text.Length(Text.AfterDelimiter(NormalizedEmail,"@"))>2

(Adjust domain-dot check: ensure domain contains a dot: Text.Contains(Text.AfterDelimiter(...), "."))

6) Filter out or review malformed rows- Filter where IsValid = true OR move invalids to QA table

7) Remove duplicates- Use Home -> Remove Rows -> Remove Duplicates on the NormalizedEmail column (Table.Distinct in M)

Notes / rationale:- Trim + Lowercase ensures case-insensitive de-duplication.- Removing +aliases (Text.BeforeDelimiter on "+") collapses mailbox tags common in Gmail.- Splitting local/domain prevents removing + signs in domain or mangling.- Validate rather than auto-fix risky cases — send malformed rows for review.- For enterprise domains where + is significant, make alias removal configurable.

MediumTechnical

107 practiced

Provide a checklist for validating Mixpanel instrumentation after a release: which event payload fields to inspect, how to test identity resolution, how to check property naming consistency, and ways to automate regression checks to catch broken events early.

Sample Answer

Checklist — quick validation you can run after a release to ensure Mixpanel instrumentation is correct (data-ready for analysis).

1) Core event & payload fields to inspect- event_name: matches spec exactly (case-sensitive)- distinct_id / user_id / anonymous_id: present and populated- timestamp (ISO/epoch) and event_time consistent with server/client clocks- project_token / environment tag (prod/staging) if sent- required properties per event spec (e.g., product_id, plan, price_usd, page_url)- property types: string/number/boolean arrays match spec- sample size: inspect 50–200 recent events to catch variability

2) Identity resolution testing- Track a flow: anonymous -> signup/login -> authenticated. Verify: - same user is merged (distinct_id before and after tie to user_id) - profile properties (email, created_at) get written/merged, not duplicated - test device + web combinations to validate cross-platform linking- Use Mixpanel’s people/profile endpoints and lookup by distinct_id to confirm merge

3) Property naming & consistency checks- Compare incoming property keys to canonical spec (case and punctuation)- Watch for synonyms: price vs. price_usd vs. amount — enforce canonical names- Ensure units and formats consistent (e.g., price in cents or USD float)- Spot-check categorical values for typos (e.g., "cancelled" vs "canceled")

4) Automation & regression checks- Smoke tests in CI that hit staging endpoints with canonical payloads and assert 200 + event present in Mixpanel via API- Daily/Hourly monitors: scheduled job that queries Mixpanel API for expected event counts and schema; alert on drops or schema drift- Lightweight validation script examples (Python/SQL) to assert required properties exist; integrate into pipeline- Seeded end-to-end tests: automated UI/API flows that produce events, then assert ingestion & identity merge- Maintain a test-suite of example payloads for each event; run in pre-release

Sample SQL-style check (use your event export warehouse):

sql

SELECT event_name,
       COUNT(*) AS events,
       SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END) AS missing_user_id,
       SUM(CASE WHEN price_usd IS NULL THEN 1 ELSE 0 END) AS missing_price
FROM mixpanel_events
WHERE event_date >= CURRENT_DATE - 1
GROUP BY event_name;

Best practices- Maintain a versioned instrumentation spec (JSON schema) and validate payloads against it.- Log discrepancies to a dashboard and route alerts to SLACK/PagerDuty.- Run identity-resolution smoke flows after every deployment to catch regressions early.

HardTechnical

60 practiced

Design a secure access model for PII in your analytics stack (data warehouse and BI tools). Explain how you would implement row-level security, column masking, audit logging, entitlement approvals, and a process for provisioning and revoking access while minimizing performance overhead and ensuring GDPR/CCPA compliance.

Sample Answer

Requirements & constraints:- Protect PII in warehouse + BI, enable analysts to do business queries with least privilege, support audit, approvals, fast queries, and GDPR/CCPA controls (right to access/erasure, data minimization).

High-level model:- Centralize PII in a protected schema/table set in the DW (e.g., Snowflake/BigQuery/Redshift).- Use layered access: raw PII only accessible to Data Stewards/Engineers; analysts access transformed/pseudonymized datasets via controlled views or materialized views; BI tools connect to these curated datasets.

Row-level security (RLS):- Implement RLS in the DW (native policies: Snowflake Row Access Policies, BigQuery Authorized Views / IAM + row filters) keyed off user attributes (department, region, business_unit) supplied by the identity provider (IdP).- Use ABAC: attach attributes in IdP (Okta/Azure AD) and propagate via federated login so queries are evaluated with user's attributes and filter rows server-side (pushdown to storage to avoid client-side filtering).

Column masking & pseudonymization:- Apply dynamic data masking functions at query-time for sensitive columns (PII masked for analysts, full for stewards). Use deterministic pseudonyms or tokenization for joinability when needed.- For irreversible needs, use one-way hashing with salt and separate mapping tables accessible only to stewards.- For BI visuals, create masked-materialized views: precompute masked columns to avoid per-query expensive transformations.

Audit logging & monitoring:- Enable DW access logs (QUERY_HISTORY/ACCESS_HISTORY), BI tool usage logs, and IdP/SAML logs; centralize into SIEM (Splunk/Datadog) and retention policy per compliance.- Log: who, when, dataset, query text (redact PII in logs), result counts, and policy applied. Alert on anomalous patterns (large exports, high-frequency reads).

Entitlement approvals:- Enforce role-based entitlements with an approval workflow in IAM + ticketing (ServiceNow). Automated provisioning via SCIM to grant groups/roles only after documented business justification and manager/DSO approval.- Implement time-bound access (TTL) and Just-in-Time (JIT) escalation for temporary elevated access.

Provisioning & revocation process:- Automated: request -> approval -> SCIM/Terraform applies role/group in IdP and DW. On revoke or TTL expiry, automation removes group membership and triggers audit entry. Include orphaned-access detection and quarterly access reviews.- Emergency access logged as “Break-the-glass” with mandatory postmortem and automatic rollback.

Performance & cost considerations:- Push RLS & masking into DW engine to leverage query pushdown; avoid client-side masking.- Use materialized/masked views for common queries to reduce CPU costs.- Cache non-sensitive aggregates in BI layer; limit row-exports via policies and rate limits.

GDPR/CCPA compliance:- Data minimization: expose only necessary PII, use pseudonymization.- Subject rights: pipeline to find & export user data on request; deletion pipeline that removes PII from primary stores and marks it in downstream aggregates where deletion isn't possible.- Maintain consent/log records and DPIA. Encrypt at rest/in transit; maintain breach detection and notification workflow.

Operational controls & governance:- Data classification catalog (automated tagging).- Periodic risk reviews, penetration tests, and training for analysts.- SLA for access requests and revocations.

Example:- Analyst requests access to customer_orders masked view. Request flows to manager + DPO approval; SCIM adds analyst to “orders_masked_readers” for 30 days. Queries apply row policy (region = analyst.region) and mask email/ssn; queries are logged to SIEM. After 30 days, group membership auto-removed and revoke logged.

This approach balances protection, auditability, and analyst productivity while enabling compliance and low runtime overhead by leveraging native DW features and automation.

EasyTechnical

94 practiced

Explain the practical differences between Mixpanel and Amplitude when analyzing funnels and user journeys. For an onboarding funnel (visit -> signup -> first-key-action), describe which features of each tool you'd use to analyze drop-off and how you would validate that events and properties are implemented correctly.

Sample Answer

High-level difference- Mixpanel focuses on flexible event-level analysis and quick ad-hoc funnels with strong user profile (People) features and count-based cohorting. It’s great for fast iteration.- Amplitude emphasizes behavioral workflows at scale (Pathfinder, Journeys), advanced cohorting, long-term retention, and product-focused features (e.g., Conversion Drivers, Behavioral Cohorts) with strong governance for event taxonomy.

For an onboarding funnel (visit → signup → first-key-action), which features to use

Mixpanel- Funnels: build the funnel, set conversion window, and view step-by-step drop-off.- Breakdown: segment funnel by properties (traffic source, country, device) to find where drop-off concentrates.- Cohorts: convert drop-off segment into a cohort for follow-up analysis or messaging.- Insights & Retention: check time-to-convert and downstream retention of converters.- Live View / Lexicon: inspect incoming events and property distributions.

Amplitude- Funnels: configure conversion windows and apply behavioral cohorts; use conversion funnels to compare cohorts or feature flags.- Pathfinder / Journeys: explore common paths before/after steps to detect detours that cause drop-off.- Conversion Drivers (or Compass): surface properties/events most correlated with conversion.- Behavioral Cohorts & User Look-up: create cohorts of drop-offs and analyze lifetime behavior.- Live Event Stream / Govern: validate schema and examine event volume trends.

How to validate events & properties (practical QA steps)1. Instrumentation spec: keep a single source-of-truth with event names, required properties and types.2. Live / Debug streams: use Mixpanel Live View or Amplitude’s Event Stream to watch events from test users in real time.3. Test users: generate controlled events (staging accounts) and confirm funnel shows expected conversions and property values.4. Count reconciliation: compare analytic counts to backend logs or raw exports (Mixpanel JQL/export; Amplitude raw export or Snowflake/Redshift) for sample parity and timestamp alignment.5. Property validation: check for null/malformed values, consistent user_id/device_id and correct time zones.6. Cohort sanity checks: build cohorts of “should-convert” users and validate they appear in funnel as expected.7. Regression monitoring: set alerts on sudden drops in event volume or schema changes (Amplitude Govern, Mixpanel Lexicon alerts).

Why these steps- Funnels and path tools reveal where users leave; segmentation and conversion-driver features point to likely causes. Real-time streams plus raw-export reconciliation ensure implementation correctness and guard against sampling, misnaming, or missing properties.

EasyTechnical

102 practiced

Write a standard SQL query (PostgreSQL or BigQuery syntax) to return the count of distinct users who triggered any event in the last 30 days. Table schema:

sql

events(event_id UUID, user_id UUID, event_name TEXT, occurred_at TIMESTAMP)

Handle NULL user_id values and timezone-awareness in your answer.

Sample Answer

Approach: filter events in the last 30 days using a timezone-aware cutoff, ignore NULL user_id, and count distinct user_id.

PostgreSQL (assuming events.occurred_at is timestamptz; use AT TIME ZONE if necessary):

sql

SELECT COUNT(DISTINCT user_id) AS distinct_users_last_30_days
FROM events
WHERE user_id IS NOT NULL
  AND occurred_at >= (now() AT TIME ZONE 'UTC') - INTERVAL '30 days';

If occurred_at is stored as TIMESTAMP (no zone) and you want to interpret it in a specific zone (e.g., America/Los_Angeles):

sql

SELECT COUNT(DISTINCT user_id) AS distinct_users_last_30_days
FROM events
WHERE user_id IS NOT NULL
  AND (occurred_at AT TIME ZONE 'America/Los_Angeles') >= (now() AT TIME ZONE 'America/Los_Angeles') - INTERVAL '30 days';

BigQuery (timestamps handled with TIMESTAMP and safe NULL filtering):

sql

SELECT COUNT(DISTINCT user_id) AS distinct_users_last_30_days
FROM `project.dataset.events`
WHERE user_id IS NOT NULL
  AND occurred_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY);

Notes:- Exclude NULL user_id to avoid miscounting anonymous events.- Use UTC or a specified timezone consistently to avoid off-by-one-day due to DST.- For large tables, consider partition pruning on occurred_at for performance.

Unlock Full Question Bank

Get access to hundreds of Technical Skills & Tools Inventory interview questions and detailed answers.

Join thousands of developers preparing for their dream job.