请勿主观带入，只讨论面试过程中处置此类问题的方式，不讨论对与错
第一人称：面试者
背景：
面试时，面试官给了错误的题目 A（求解一个至少数量的数学问题，漏了约束 m 且求解的问题给成了 “最少”,预期是至少）。
告诉面试官自己答案后。面试官表示没理解，并表示应聘者没讲清楚。面试官说此类题目应该使用 xx 算法。
过程：
a:由于面试官表示没有理解，应聘者表示：我可能口头表达不太好，应该是由于我是 yy 专业的原因，思维跟表达方式太 yy 化了，没表达清晰，我尝试用直白的方式讲清楚。
b:面试官情绪有点激动：既然你是 yy 专业出身的，理论上就应该使用 yy 思维啊，怎么不用 xx 算法？
c:应聘者当拿到答案，xx 算法时，意识到应该题目错误。跟面试官确认答案后得到答复题目就是 A,不变，应聘者道：我个人觉得 xx 算法不对，我的答案比 xx 算法得到的结果数量还要少。
d:面试官情绪更为激动：你既然 yy 专业出身，那么你来讲讲 xx 算法怎么不对？说说看为啥 xx 算法不对！
e:应聘者：额，这个？（希望降低进一步冲突的可能）
f:面试官：你要证明 xx 算法错误！
g:应聘者此时情绪也比较激动，未能进一步避免冲突，应要求面试官要求，举例证明 xx 算法错误。
h:面试官依然没有认识到问题：你看不应该是 xx 算法么？
i:应聘者：我的算法中比 xx 算法还要优良啊。使用 xx 算法得到的值明显多余我的算法啊。
j:此刻面试官反应过来后，反驳道：我没说该问题可以这样子跳过 约束 m 啊！
k:应聘者也比较激动：你题目中没有说有 m 的约束啊！
从上述的过程中 a-k, 应聘者与面试官分别该如何处置？
咸吃萝卜淡操心
回复
恩恩。猜测 是 example testing 跟 property based testing 的争论了。
有些是基于 固定的输入，固定的预期。类似于 example table 用例表格的方式。
有些是可以基于特定属性的的测试。
类似于 如何测试一个方法 f=a+b
方式 1，举例 a，b 是多少 f 是多少，分别 去检查
也可以方式 2，加法这个运算方法，满足单位元，a+b=b+a 交换律，结合律 (a+b)+c=a+(b+c)，随机输入，满足以上属性即可。
要么干他要么随着他，毕竟面试官都是我们需要哄一次的孩子
打起来了
打起来
不太明白，为何需要争论呢。
不是有个成语叫做【将错就错】吗
假如应聘者对这个问题了如指掌，可以依着面试官的理解，将错就错解下去，给他想要的答案
他得到满足后，你再指出来真实结果可能是这样的，不是更好吗
面试你的人，假如入职，可能基本是你的上级，你对，不可以理直气壮，只可理直气和
别把面试官不当人看，问题就迎刃而解了
Thirty-Thirty
回复
恩恩。也对。他觉得自己正确，我也觉得自己正确，所以在招聘过程中产生争论。
在这个之前还有个插曲，
碰到面试官提出 java 类加载过程的问题，面试官只知道一部分，另一部分不了解，就其中核心类加载过程不断的说应聘者讲的不对，此时就很尴尬，应聘者是告知准确答案还是选择沉默。 就问题本身讲需要告知准确的答案，就面试技巧讲，不要在招聘中产生争论。
恒温
回复
非常尴尬。面试中 不争论显得自己无知，争论显得 面试官不专业。
这个是不是 面试技巧的一种，压力面？
看应聘者在 这种情况下的表现，是反驳还是默默承受。
记得今年五月份面试的时候有个面试官在聊到控件元素定位方式优化的时候扯到了 w3c 协议, 把我都整懵逼了。
我遇到过类似的问题，面试官就说自动化数据应该事先固定写死了，我说我的自动化脚本的参数基本都是随机生成的，然后他就 一直盯着我问 我怎样保证我随机生成的数据是没问题的，当时真的差点打起来了，
我一直觉得，面试是双方的，面试官真的倔且不愿意承认自己的错误，那就 88。很多时候面试不仅看技能，也看性格和沟通方式是否合得来。如果真的合不来，不需要勉强。
而且从你这个例子里看，面试官是先激动的一方，面试者已经尽量降低冲突了，所以我觉得面试者没啥要改进的。即使面试里委屈求全通过了，说不定以后工作上的合作又出现类似的问题，到时候更坑。
同 10 楼，面试官在面试你，同时也是你在面试面试官
