面试作战台

“The prices came from Bloomberg and the company’s internal system. I used a consistent market cut-off and checked that the security code and instrument matched before updating the sheet. If a movement looked unusual or the two views did not appear consistent, I would not overwrite it silently; I would recheck the timestamp, currency and source before adding a remark or escalating the difference.”

“The purpose of the control was to make the daily movement report reliable and easy to review, not to create a complex trading or valuation model.”

“The core columns were security name, security code or ticker, previous closing price, latest or current price, absolute price change, percentage change and remarks. The remarks field allowed concise context for an unusual movement or a source issue.”

“If asked about formulas, I would explain that absolute change was the latest price minus the previous close, and percentage change was that difference divided by the previous close. I would only mention sorting, conditional formatting or lookup formulas if I had actually used them.”

Safe answer template—replace the bracketed facts with a real event before using it:

“In one task, [team A] needed [specific market update or document] from [team B], but the initial request was interpreted differently because [language, format, timing or data-cut-off issue]. I first restated the request in one sentence and confirmed the expected output, owner and deadline with both sides. I then used the same bilingual terminology and version of the file in the follow-up, and summarised the final action in writing.”

“As a result, [specific outcome]. The experience taught me that cross-department communication is not simply forwarding a message; it requires confirming that both sides share the same definition, version and next action.”

“One difficult problem I worked on was traffic-light detection for first-person assistive glasses. The model had to recognise small objects under complex lighting, and yellow-light data was underrepresented. I first analysed the errors instead of immediately tuning the model. I found three recurring issues: missed yellow lights, difficult illumination and nearby targets being suppressed.”

“I mapped each issue to a specific response: targeted augmentation and scale transformation for robustness, resampling and increased class weight for yellow lights, and confidence and NMS threshold adjustment for suppression errors. I also recycled difficult cases into later fine-tuning. Validation mAP@50 improved from about 70% to 95%. The experience taught me to segment a difficult problem into measurable failure modes and prioritise actions based on evidence.”

“At SenseTime, the product team wanted to know whether familiar-person recognition would work on monocular smart glasses. The phrase ‘work well’ was too broad, so I clarified the immediate use case and translated it into one-to-one verification.”

“I built a 2,000-image evaluation set for 50 familiar people, defined the pairwise comparison flow and included difficult first-person conditions such as side angles, occlusion and glasses. I then grouped failures by image quality, alignment and similarity behaviour. This gave the team a repeatable baseline and a clearer basis for deciding what to improve next. The lesson was that ambiguity becomes manageable once the user, decision and success criteria are explicit.”

“I start with user impact, not the technical parameter. In the scenic-attraction ASR project, I would not begin by discussing decoding weights. I would explain that a general ASR model may perform well overall but still fail on the attraction names that visitors care about most, so the average metric does not fully represent the experience.”

“I would then explain the action in business language: we built a priority terminology layer, gave stronger influence to high-value names and tested both missed terms and false activations. Only if the stakeholder wanted more detail would I explain how this was implemented in code. This sequence keeps the discussion connected to the decision that the stakeholder needs to make.”

Only use this version if it is factually accurate: the initial optimisation focused too much on the aggregate metric and did not isolate yellow-light performance.

“In an early traffic-light model iteration, I paid too much attention to the aggregate validation score. The overall result improved, but a review of class-level cases showed that yellow-light recall was still weak because the class was much less represented.”

“I acknowledged that the evaluation view was incomplete and changed the process. I added class-level error review, separated results by scenario and treated minority-class performance as an explicit acceptance criterion. I then used resampling, class weighting and hard-example mining to address the issue.”

“The important lesson was not simply to optimise a headline KPI. Since then, I have tried to define segment-level checks at the beginning of an analysis so that an average result cannot hide a critical user failure.”

Adaptation template—use only after confirming a real disagreement: do not claim that this exact event happened if it did not.

“In a team project, we disagreed about whether to prioritise a more complex analysis or deliver a simpler, interpretable result within the deadline. I first asked each person to explain the decision their approach would support, rather than debating the method in isolation.”

“We agreed on three criteria: relevance to the research question, interpretability and time required for validation. Based on those criteria, we delivered the simpler core analysis first and treated the more complex method as an extension if time allowed. This kept the team moving without dismissing either perspective.”

“I learned that productive disagreement requires a shared decision criterion. Once the team agrees on what success means, the discussion becomes less personal and more evidence-based.”

“At Chiyu, market information had to be converted into a concise daily update within a limited time window. I separated the task into fixed and judgement-based components. I first updated the consistent Excel fields—security name, code, previous close, latest price, price and percentage change—from Bloomberg and the internal system. I then reviewed the largest movements and added concise remarks where context was relevant.”

“Using a repeatable order reduced omissions and left more time for checking unusual movements. Before sharing the update, I verified the source and cut-off time so different teams would be working from the same market snapshot. This taught me to use structure and quality checks rather than simply working faster under pressure.”

“At UCLA, I led a five-person R project using approximately one million Lichess games. The dataset allowed many possible directions, so my first responsibility was to turn a broad exploration into a small number of answerable questions around Elo, colour, opening and time control.”

“I divided the work across data cleaning, modelling and visualisation, set common variable definitions and brought the outputs together regularly so that the team did not produce five disconnected analyses. When results differed, I asked the team to check filters and assumptions before debating the conclusion.”

“We produced one coherent analysis using logistic regression, hypothesis tests and temporal views. I learned that leadership in an analytical project is mainly about alignment: shared definitions, visible ownership and an integrated final story.”

“My first strength is structured problem-solving. When a problem is broad, I naturally break it into a decision, measurable indicators and smaller causes. For example, in the traffic-light project, I separated class imbalance, difficult lighting and target-suppression errors before choosing different actions for each.”

“My second strength is analytical discipline. In the Afrobarometer project, I paid close attention to missing-value definitions, abnormal values and survey weights before interpreting the result.”

“My third strength is translation across contexts. I can understand enough technical detail to work with a delivery team, while explaining the issue through user impact and business priorities. I believe this combination is particularly relevant to a Digital Business Analyst.”

“One area I am improving is making my communication concise earlier in the process. Because I enjoy analysis, my first explanation can sometimes contain more technical detail than a stakeholder needs.”

“I have been addressing this by using a top-down structure: I begin with the decision, then give two or three supporting points, and keep the technical detail available for follow-up. For example, when explaining the ASR project, I now begin with the visitor impact of misrecognising an attraction name rather than beginning with the decoding mechanism.”

“This has helped me become more audience-focused without losing analytical depth, and I expect client-facing consulting work to strengthen this further.”

“I would bring three things to the team. First, I have hands-on analytical experience across market research, large-scale data and AI product evaluation, so I am comfortable working with both qualitative and quantitative evidence.”

“Second, I have repeatedly translated broad questions into structured deliverables: a management briefing at Chiyu, a clean research dataset at HKUST, an evaluation baseline for face verification and targeted model actions at SenseTime.”

“Third, I am comfortable learning across disciplines. I do not expect to know every client industry on day one, but I know how to ask clear questions, validate facts and organise unfamiliar information quickly. As an intern, I would bring strong execution, intellectual curiosity and a willingness to support the team wherever the delivery requires.”

“The main reason is the nature of Deloitte Digital’s work. I am interested in the point where business needs, customer experience and technology delivery meet. My technical experience showed me that a model is useful only when the user scenario, requirements and evaluation criteria are clear.”

“Deloitte Digital’s ability to connect strategy with design and implementation therefore fits the way I want to develop. I also value the opportunity to work on varied client problems in Hong Kong, where teams often need to operate across industries, languages and regional stakeholders.”

“I am not choosing consulting only for variety. I am specifically looking for an environment where analysis must lead to an implementable result and where I can learn the disciplines of requirements, stakeholder alignment and delivery.”

“Hong Kong is a natural place for me to begin my consulting career because I have studied and worked here and understand its bilingual, international business environment. My experience at Chiyu also gave me exposure to how market information and internal communication move across English- and Chinese-speaking teams.”

“At the same time, Hong Kong organisations are managing practical digital-transformation questions across finance, consumer services and the wider Greater Bay Area. That combination of international standards, regional context and technology adoption is exactly where I believe my cross-disciplinary background can add value.”

“I first clarify the business consequence, deadline and dependency of each task. A task that blocks another team or affects a client decision usually deserves priority over one that is simply visible.”

“I then break the work into must-have and nice-to-have outputs, estimate the effort and confirm priorities with the relevant owner if there is a conflict. During execution, I use short checkpoints so that risks are visible early rather than at the deadline.”

“At Chiyu, for example, I would complete the consistent market-data update first, identify the largest or unusual movements and then spend the remaining time adding context. This protected accuracy while ensuring that the team received the essential update on time.”

“I begin by defining the decision that the work needs to support. I then build a basic issue tree covering the customer, economics, process, technology and regulation, and identify which assumptions need evidence.”

“I use a small number of authoritative sources first, create a glossary of unfamiliar terms and interview people close to the process. I summarise what I think I understand and ask them to correct it, which is faster and more precise than asking only broad questions.”

“Finally, I keep an assumption and evidence log so that the team can distinguish confirmed facts from working hypotheses. My transitions between political economy, finance and AI products have trained me to learn this way.”

“I would start with the business objective and the decision-maker, then identify the user groups and stakeholders affected by the process. I would combine interviews, observation, existing documents and performance data rather than relying on a single stakeholder’s description.”

“I would map the current process, pain points, exceptions and system dependencies. I would then translate needs into clear requirements or user stories with priority, owner and acceptance criteria. For example: ‘As a visitor, I want the assistant to recognise the official attraction name so that I receive the correct explanation.’ The acceptance criteria would specify the test set, target performance and fallback behaviour.”

“Before development, I would play the requirements back to both business and technical stakeholders to expose ambiguity and confirm scope.”

“I would first understand whether the change reflects new information, an unresolved objective or a genuine scope increase. I would document the original requirement, the requested change and the reason, then assess the impact on timeline, cost, dependencies and testing.”

“I would present options rather than simply rejecting the change—for example, include it in the current release by moving another item, treat it as a later phase, or run a small validation first. The decision should be made by the appropriate owner and reflected in the requirement and project log.”

“The goal is to stay responsive without allowing informal changes to create hidden delivery risk.”

“I treat data quality as part of the analysis, not a preliminary housekeeping step. I begin with definitions: what each field means, its source, valid range, unit, time cut-off and missing-value codes.”

“I then check completeness, duplicates, consistency across sources, outliers and reconciliation totals. For a recurring process, I make the checks repeatable and document any manual judgement. In the Afrobarometer project, distinguishing refusals, ‘do not know’ responses and system missing values was essential because treating them as ordinary numbers would bias the result.”

“Finally, I communicate remaining limitations so that a stakeholder understands the confidence level of the conclusion.”

“I separate reversible exploration from decision-critical output. During exploration, I work quickly to identify the likely drivers. Before an output is used for a client or management decision, I apply stronger checks to the source, calculation, definition and version.”

“I also use an 80/20 approach to scope, not to quality. I may narrow the number of questions, but I do not knowingly relax the accuracy of the answer I deliver. If time is limited, I state what has been validated, what remains uncertain and what I recommend checking next.”

“Digital transformation is not simply adding a new system or AI feature. It is redesigning how an organisation creates value and how customers and employees complete important tasks, supported by data, technology and new ways of working.”

“A successful transformation therefore requires a clear business outcome, process change, user adoption, governance and measurable benefits. Technology is an enabler, but a technically strong solution can still fail if it does not fit the workflow, integrate with existing systems or earn stakeholder trust.”

“I would consider data privacy and consent, model accuracy and bias, explainability, security, integration, operating ownership and user adoption. I would also distinguish the cost of different errors: in some cases a false positive is more harmful, while in others missing a critical event matters more.”

“I would recommend a controlled pilot with approved data, human fallback, logging and segment-level evaluation. The governance should define who owns the model, who reviews errors, when the system must escalate and how performance will be monitored after launch.”

“My SenseTime work reinforced that an aggregate metric is not enough; the team must test the scenarios that matter most to the real user.”

“In the next three to five years, I want to become a strong digital Business Analyst who can independently structure a client problem, gather and challenge requirements, work confidently with data and support delivery from discovery through testing.”

“I also hope to develop deeper expertise in data- and AI-enabled transformation, but I do not want to specialise only in the model layer. My goal is to understand the full business and user context and become someone both client and technical teams trust to connect decisions with execution.”

“I see it as an extension rather than a complete change. My technical experience gives me credibility when discussing data, evaluation and implementation constraints, while my finance and research experience trained me to synthesise information and communicate conclusions.”

“The capability I now want to develop is the full client-facing process: stakeholder interviews, requirements, prioritisation, change management and delivery governance. I know consulting also involves detailed execution such as minutes, documentation, testing and follow-up, and I am prepared to contribute at that level as an intern.”

“I study Global China Studies at HKUST. Although the programme is interdisciplinary, I have deliberately built a quantitative and analytical direction through comparative politics, Chinese political economy, political-culture research and data-focused projects.”

“For example, I have used Python and R to clean large datasets, analyse survey and text-based evidence and test hypotheses. My political-economy coursework also trained me to consider institutions, incentives and stakeholder interests rather than looking at a business problem through only one metric.”

“For consulting, I think the value is the combination: I can work with data, but I also understand that digital change happens within an organisational and social context.”

“The course encouraged me to turn broad concepts such as trust, values and public attitudes into measurable variables. The difficult part was not only running an analysis; it was deciding how a concept should be operationalised and whether the available survey or text measure truly represented it.”

“I used Python or R workflows for data cleaning and quantitative analysis and learned to check missing-value definitions, comparability across groups and alternative explanations. That experience is relevant to Business Analysis because client terms such as ‘engagement’ or ‘customer experience’ are also broad concepts that need clear operational definitions and measurable indicators.”

“Archaeology trained me to build an argument from incomplete and imperfect evidence. Rather than relying on a single object or source, we considered context, classification, chronology and competing explanations.”

“I found that mindset surprisingly relevant to data analysis. A dataset is also a partial record created through a collection process, so the analyst needs to understand what is missing, how categories were defined and whether the evidence supports the conclusion. The course strengthened my attention to evidence quality without turning me into an archaeology specialist.”

“I am most proud of the traffic-light detection project because it combined technical execution with a clear user scenario. The model was designed for first-person assistive glasses, so a missed small traffic light was not just a benchmark error; it affected whether the product could give useful information in the real environment.”

“I contributed across data preparation, error analysis and targeted iteration. By identifying class imbalance, difficult lighting and suppression errors separately, I helped translate each problem into a concrete action and improved validation mAP@50 from about 70% to 95%.”

“I am proud not only of the result but of the method: begin with the user context, diagnose the evidence and make each technical change traceable to a real failure mode.”

“I think they would describe me as analytical, dependable and willing to make unclear work more structured. In team projects, I often become the person who clarifies definitions, checks whether different outputs are comparable and consolidates the final story.”

“They might also say that I ask many questions at the beginning. I do that because I prefer to expose ambiguity early rather than discover near the deadline that different people were solving different problems. I have learned to keep those questions focused on the decision, owner and acceptance criteria.”

“I try to separate feedback on the work from a judgement about me. First, I restate the feedback to confirm that I understand the expected change. Then I ask for an example or success criterion if the comment is broad, update the work and show the revision early rather than waiting until the end.”

“I also look for a process lesson. If feedback reveals a recurring issue—such as too much technical detail—I change the template or checkpoint I use in future work. The value of feedback is not only improving one deliverable but reducing the chance of repeating the same issue.”

“I would first check the analysis and understand the stakeholder’s assumptions before presenting it as a contradiction. They may have context that is not in the dataset.”

“I would show the evidence transparently: definitions, source, method, sensitivity and limitations. I would frame the conclusion as a question for joint investigation—for example, ‘The current data suggests a different pattern; could we test whether this segment or operational factor explains the difference?’”

“If the evidence remained robust, I would state it respectfully and offer options for validation. The goal is not to win an argument but to help the team make a better-informed decision.”