Appearance
第一部分：与面试官飞的第一轮交锋 —— 设计、美学与实践的碰撞
1.1 开场与自我介绍：明确我的核心价值
面试开始，我与面试官飞进行了简短的寒暄。在确认了远程工作的模式后，我开始了自我介绍。我重点讲述了自己过往的工作经历，包括在某汽车大厂负责的HR人力资源看板和产线BI管理项目，以及在友邦保险负责的销售分析项目。我希望通过这些案例，引出我后续要重点展示的核心项目——那个从0到1负责的某汽车大厂HR看板。
1.2 岗位期望的对齐：一次对“高级感”的探讨
飞没有立刻让我介绍项目，而是先清晰地阐明了岗位的期望。她强调，团队里已经有数据分析师能搭建“差不多”的看板，但这个岗位更加看重设计的“美观程度”和整体的“审美” 。她将这个角色定位为“一个中级偏高级的这样一个看板开发的一个角色”，要求能交付出非常高质量、精美的作品。这一点与我的职业理念不谋而合，这是一个能让我“设计+开发”双重背景充分发挥价值的机会。
1.3 核心案例深度剖析：从Figma到Tableau的像素级还原
在明确了岗位要求后，我开始介绍HR看板项目。
设计先行：我首先打开并共享了Figma的设计稿。我向飞解释，在这个项目中，我们从需求沟通入手，然后由我独立使用Figma进行高保真原型设计。
协作流程：我详细描述了整个协作链路：“BI的落地也是我做的...包括那个数据结构也是我们根据他的这些需求去设计的。然后只是说有专门的DA的同事去做数据” 。也就是说，我负责UI设计、数据结构设计和最终的Tableau实现，DA团队负责上游的数据抽取和清洗，最后由前端团队将完成的Tableau报表嵌入到他们的系统中 。
成果展示：在飞的要求下，我找到了当时用Tableau实现的最终版本。我将Figma设计稿和Tableau成品并排展示，直观地证明了我具备将设计稿高保真还原为最终产品的能力。无论是整体布局，还是像漏斗图这样的复杂图表，都实现了像素级的还原。
【补充标签：我的项目方法论】
我之所以花大量篇幅介绍这个“Figma to Tableau”的工作流，是想传递一个核心理念：专业的可视化开发，是工程思维和设计思维的结合体。
设计先行是“蓝图”：直接在Tableau里开发，就像没有图纸就盖楼，容易导致方向性错误和大量返工。Figma原型是项目的蓝图，它让项目所有相关的人（业务、数据、前端）在开发前就对最终成品达成共识，这是项目成功的关键。
高保真是“承诺”：能够像素级还原设计稿，这不仅是技术能力的体现，更是对业务方的一种承诺。它保证了“所见即所得”，建立了团队的专业信任度。
流程定义“角色”：清晰的流程定义了我在团队中不可替代的“桥梁”角色。我既能理解业务的感性需求并将其设计出来，又能理解数据的理性逻辑并将其实现出来，这是我的核心价值。
1.4 现场实战大考验：在线评判面试官的Dashboard
介绍完项目后，飞发起了面试中的一个关键环节：她共享了自己的屏幕，让我对一个她正在制作的看板提出专业意见。
临场挑战：这是一个压力与机会并存的时刻。我迅速调整状态，从一个面试者切换到“可视化顾问”的角色。
我的诊断与建议：
布局问题：我首先指出，多个KPI指标卡看起来是由不同的工作表拼凑而成的，这导致了视觉上的“割裂感”和对齐困难。我建议用单一工作表配合布局容器来统一实现，并分享了使用“空白对象”辅助对齐的技巧。
视觉问题：我指出下方的趋势图“颜色会有点多” ，并建议一个页面的颜色最好不要超过五种，以保证视觉的清晰和焦点。
信息呈现：对于表格，我建议“加上一些可视化的元素。比如说正负的百分比用不同颜色去标记” 。对于KPI卡，我建议可以融合更多信息，比如同比环比和趋势箭头。
【补充标签：可视化设计的底层逻辑】
我提出的每一条建议，背后都有着数据可视化和UI设计的底层逻辑支撑。
整体性与亲密性：建议用单一工作表实现KPI卡，是应用了格式塔的“亲密性”原则。物理上靠近、视觉上相似的元素会被认为是相关的。多个工作表破坏了这种关联，而统一实现则能让用户一眼就将它们视为一个整体。
信噪比与认知负荷：建议减少颜色，是为了提高“信噪比”。颜色是一种强大的视觉编码，但滥用会成为视觉噪音，增加用户的认知负荷。克制地使用颜色，只在高亮关键信息时使用，才能达到最好的效果。
“手艺”的体现：能否熟练运用布局容器、处理对齐等细节，是区分Tableau初学者和老手的重要标志。这部分展现的是我对工具的精熟程度和对“手艺活”的追求。
第二部分：与团队负责人宙斯的第二轮面试 —— 流程、深度与边界的探索
2.1 项目流程的全景审视：从开发到运维
第二轮面试官宙斯是数据分析团队的负责人。她的问题更加宏观，聚焦于流程和协作。我再次阐述了从需求沟通到设计、开发、测试，再到上线后处理Bug和功能更新的运维阶段的完整流程 。当被问及数据处理的参与度时，我坦诚，在有DA的团队中我主要负责设计数据结构；但在目前缺少DA的公司，我也会使用Tableau Prep这样的轻量级ETL工具自己处理数据。
2.2 技术深度的极限挑战：三大高级场景提问
宙斯随后提出了一系列更具挑战性的技术问题。
场景一：多级下钻：她以公司的零售业务为例，询问我实现“全国-大区-城市-门店”这种多级下钻功能的经验 。我坦诚回答：“多级下钻没有太涉及到这一个功能”，表示过往项目层级不多，但愿意深入研究。
场景二：海量数据性能优化：她针对我简历中提到的亿级数据优化案例进行追问 。我详细解释了在友邦项目中的具体做法：首先排查数据源，发现“有很多字段其实没有使用到。我们先把这些字段去删除” ；其次，与业务方沟通后，调整了数据更新的粒度，从每天刷新改为“按照两三天或者是一周的这样的情况去刷新数据”，最终实现了性能的提升。
场景三：定制化可视化：她提了一个开放性问题：“有没有用过像python或者其他一些工具去...实现像...没有办法直接实现的一些定（制）化的可视化的效果” 。
【补充标签：面试中的攻防策略】
诚实是最好的策略：在“多级下钻”这个问题上，任何的掩饰都会被经验丰富的面试官看穿。坦诚自己的知识边界，并展现出积极的学习意愿，远比不懂装懂要好。这不仅是诚信的体现，也展现了我的成长型思维。
简历上的每一个字都要负责：面试官对简历细节的追问是必然的。我能详细说出性能优化的具体步骤，证明了这段经历的真实性。这也提醒我们，准备面试时，必须对简历上的每一个项目、每一个技术点都准备好一个能够详细阐述的STAR案例。
识别“机会问题”：“定制化可视化”这个问题，表面上是考察技术广度，实际上是一个让我展示亮点的“机会问题”。我敏锐地抓住了这个机会，引出了我准备的“秘密武器”。
2.3 我的“秘密武器”：用Tableau Extension API实现技术破局
主动出击：我立刻回答“有”，并主动提出：“方便直接投屏。然后我们具体看一下” 。
成果展示：我没有直接讲理论，而是打开了我在B站上分享过的视频，现场展示了我利用Tableau Extension API和Vega可视化库，开发的一个“雷达图”插件。
技术原理解析：我简明扼要地解释了其技术原理，它由HTML（作为容器）、TREX文件（负责声明需要从Tableau中调用的字段）和JavaScript（负责获取数据并使用Vega库进行渲染）三部分组成。我总结道，可以把Tableau理解成一个浏览器，它能够调用和渲染我们开发的网页插件。
2.4 软实力与岗位匹配度确认
最后，宙斯考察了我的软实力，并进行了岗位匹配度的确认。
沟通能力：对于如何与不同背景的人沟通，我将自己的角色定位为“沟通桥梁”和“翻译者” 。对业务方，要用他们听得懂的语言沟通价值；对技术方，要用他们能理解的逻辑沟通实现。
双向问答：在最后的提问环节，我了解了团队的配置和岗位的具体情况。宙斯也清晰地定义了这个岗位的价值：“我们有一些项目对看板可视化的一个要求会比较高...需要一个比较专业的同事来专门去做可视化的这部分”，最终定位为整个团队的“可视化专家”角色。
【补充标签：角色的深度理解】
当宙斯说出“可视化专家”这个词时，我意识到，这个岗位要做的远不止是“画图”。
制定标准：作为专家，我需要为团队的可视化输出建立一套设计规范和最佳实践，提升整个团队的出品质量。
赋能他人：我不仅要自己能做，还要能向其他DA同事传授高级的可视化技巧和设计理念，扮演半个“导师”的角色。
技术探索：我需要持续探索像Extension API这样的新技术，为团队引入解决复杂可视化需求的“武器”。
这次面试的成功，很大程度上在于我过往的经验和展示出的能力，与这个“专家”角色的要求高度契合。
我的面试总结与反思
优势总结：“设计驱动开发”的理念、扎实的Tableau功底和前端拓展能力，共同构成了我区别于其他候选人的核心优势。
待办事项：必须立刻补强“多级下钻”等企业级常用功能的熟练度，将其变成我的另一个“武器”。
最终感想：这是一次高质量的技术交流。它让我明白，一个优秀的数据可视化工程师，不仅要有发现问题、分析问题的能力，更要有将数据之美、逻辑之美呈现出来的能力。我对此充满热情，并准备好迎接新的挑战。