让 AI 回答一下：

*** 问题 1: ***

有人发帖这样子说：
最近面试的几个人都有个共同点，会着重拿出自己写的测试平台来体现自己测试的技术能力，可一问他们测试的公司业务的技术架构和技术细节时，又都答得支支吾吾。我是觉得现在的测试同学们还是要有点意识，得有个专精方向，别整这种业务接口测试平台来欺骗自己啦，看似做了前后端有种全栈的满足感，实际上大多就是把 postman web 化了啦，确实锻炼了 crud 的能力，可是证明不了你是一个优秀的测试，毕竟像这种测试平台有太多参考的案例了，我更多是想知道你针对你测试的业务，有没有根据特定去做一些真正能提升质量的事，否则太同质化了。至于 crud 的能力，老实说扔一道代码编写的题目基本就知道得七七八八了

我这样子回复有没有太大问题：
I feel sorry that the interviewer is biased. 
You want to hire a AKA good software testing/qa talent, It is cool. And you also know having crud coding skill is just one perspective of a good testing engineer, It is very cool. 

you know the main reason these candidate didn't pass the interview is that they are not qualified in some perspectives of you so called good tester or qa. It is nothing to do with learning CRUD code skill. Learning CRUD code skill is not blinded, you already you the skill name is CRUD, and you already know the purpose of the CRUD, where to use, how to use, How you can say learning CRUD is blinded？

Please don't deny the fact that someone put their efforts into coding practices, it definitely took a lot of their time. Maybe they are still not qualified, but they are not blinded, they just simplify want to learn the specific coding skill to gain decent salary, It is fact and not wrong at all. 

If someone without any coding skill or knowedge, how can he convince you that he know the software architecture, understand the details, and differences between different software components? And aslo maybe there is no complex software architecture in their company, then it is nothing to tell. 

Please don't mix irrelavent things together,  it is just about your requirement and the skill of the candidate is mismatched. But it is nothing to do with learning some blinded

回答 1:

在回复这样的帖子时，需要保持尊重和理解的态度。你的回复表达了对面试官偏见的遗憾，并且强调了CRUD技能的重要性和学习的目的性。这是一个很好的出发点，但是有几个地方可以改进，以确保你的回复更加中肯和有建设性。

1. **避免直接指责**：你的回复中直接指出面试官有偏见，这可能会引起对方的反感。可以采用更委婉的方式表达，例如：“我理解您在寻找具有特定技能的测试人才，但也许我们可以从不同的角度来看待候选人的潜力。”

2. **强调多样性和成长**：你可以指出，不同的测试人员有不同的优势，而且他们可能正在学习和发展中。例如：“每个候选人都有其独特的技能和成长潜力，CRUD技能是他们技能树的一部分，而且他们可能还在学习如何将这些技能应用到更复杂的测试场景中。”

3. **提出建议**：你可以提出一些建议，帮助面试官更好地评估候选人。例如：“也许在面试中加入一些关于候选人如何将CRUD技能应用到实际业务场景中的问题，可以帮助您更全面地了解他们的能力和潜力。”

4. **保持客观**：避免使用过于情绪化的语言，保持客观和理性。例如：“学习CRUD技能并不是盲目的，它有其明确的应用场景和目的。我们应该鼓励候选人探索如何将这些技能与业务需求相结合。”

5. **避免误解**：确保你的回复没有误解原帖的意思。原帖似乎在批评候选人只关注CRUD技能而忽视了业务理解和技术架构，你的回复应该围绕这一点展开。

6. **使用更正式的语言**：你的回复中有些地方使用了非正式的语言，这可能会影响回复的专业性。例如，将“It is cool”改为“It is understandable that you are looking for candidates with specific skills”。

综上所述，你的回复需要更加细致和周到，以确保能够传达出你的理解和尊重，同时提供有建设性的反馈。

问题 2:

这样回复怎么样？ I am so glad that you figured out one important point, coding skill is not all about to be a AKA good tester or qa engineer.  To be a good tester, candidate also need to demonstrate other good skills in the interview.  But in another hand, the claim just build  another postman like web application, it hurts. It may not only underestimated the effort took by the candidate, also some learning ability  and adaptability was ignored. I think it may more focus on what the specific skill you preferred, what specific valuable thing is very important, but a lot of candidate ignored. 
It may be more constructive for all of us than just diss building another postman like web application or learning something blindly. This should be more valuable to help us to gain a decent salary job.

回答 2:

Your revised response is a step in the right direction as it acknowledges the complexity of being a good tester and the multifaceted nature of the skills required. However, it could be further refined to be more clear, diplomatic, and constructive. Here's a suggested revision:

---

I appreciate your insight that coding skills alone do not encompass the full spectrum of what makes a good tester or QA engineer. Indeed, a candidate should demonstrate a range of competencies during an interview to showcase their potential to contribute effectively to a team.

At the same time, it's important to recognize the effort and the learning process that goes into building a test platform, even if it might resemble an existing tool like Postman. Dismissing such projects as mere replications might underestimate the candidate's initiative, problem-solving abilities, and adaptability—skills that are also highly valuable in the field of software testing.

It's crucial to focus on the specific skills and attributes that are most relevant to the role. While it's true that some candidates may overlook the importance of these specific skills, it's also an opportunity for us to clarify what we value and why. This understanding can guide candidates in their professional development and help them align their skills with the demands of the job market.

Constructive feedback can be more beneficial than simply criticizing the replication of existing tools or the 'blind' pursuit of certain skills. By providing clear guidance on what is expected and valued, we can help candidates—and ourselves—navigate the job market more effectively and aim for a win-win situation that leads to fulfilling and well-compensated positions.

---

This response is more balanced, emphasizes the importance of a multifaceted skill set, and suggests a collaborative approach to identifying and valuing the right skills for the job. It also encourages a positive dialogue between the interviewer and the candidates.

Your reply captures the essence of the situation well, but it could be restructured for better clarity and impact. Here's a revised version:

**I completely agree that coding skills are only one facet of being a successful tester or QA engineer. Strong communication, analytical thinking, and problem-solving abilities are equally important.**

**However, I take issue with the claim that building a 'Postman-like' web application is a meaningless exercise.** This project could demonstrate a candidate's initiative, problem-solving skills, and knowledge of testing frameworks. While it may not be directly relevant to every role, it reflects valuable learning and adaptability.

**Perhaps a more constructive approach would be to clarify the specific skills you find most valuable for the role. What specific challenges does your team face that candidates could address?** This would help both interviewers and candidates align expectations and ensure a successful hiring process.

**Ultimately, the goal is to find qualified individuals, and building a 'Postman-like' application can be a positive signal in the right context.**

**Improvements:**

- **Clearer Structure:** Separates agreement with the interviewer on the importance of broader skills from disagreement about building a "Postman-like" application.
- **Stronger Word Choice:** Uses terms like "initiative" and "adaptability" to highlight the positive aspects of building such an application.
- **Shift towards Solutions:** Proposes a more constructive approach for pinpointing valuable skills and aligning expectations.
- **Emphasizes Mutual Benefit:** Focuses on finding qualified individuals, benefiting both interviewers and candidates.

By focusing on building bridges and finding common ground, this revised response aims to promote a more productive discussion.

我也想问，这个要回答什么东西？ 是前后端用的什么语言什么框架什么中间件吗？

说白就是理解开发的技术方案，也有助于用例的补充和测试（我待了那么多家公司，能参与技术方案的不多），当然好点的公司也会叫上测试 cr，每个环节参与度都比较高。大多数地方就是点完事了

我也想知道这个问题的答案

现在高不成低不就是真的，最好还是看看能不能换赛道吧

测试是这样的，大部分高不成低不就，所谓的代码能力在开发眼里就是基础基本要求天天都要干的事儿，只会点点点又心有不甘，业务总结的经验换个方向业务又是从新开始理解，如何测试保质保量提高产品质量并能通用到新项目中实在是一个很抽象的问题。

我认为一个好的测试懂得技术架构和技术细节是比较基本的

"特定去做一些真正能提升质量的事"楼主能简单举例么？--建议楼主自问一下，你到底要招啥样的？架构？打杂的？真的需要么？
还是这些人要的钱多了，你嫌弃人家菜还要的多？
PS：你要遇到我，我举完例子，就要你举例了。举不出来，那我就开始要阴阳你了。

这不是做测试，这是搞架构，职责还是要分清楚

何为"技术架构"和"技术细节"

总结：测试没前途 T﹏T

你这样说就没意思了

这就看人了，要不然你怎么会有优势呢？

说了就是挑。一般测过的项目我觉得大致用啥技术都能说上来，你说多细节我觉得未必。而且黑盒测试还能把研发写的代码都说出来么？要多细节？把技术方案说个七七八八都不错了好不？
也不是每个测试所在的公司都有机会参与技术方案评审，点点点嘛业务说明白就好了

大佬想问下，技术架构、技术细节都问哪些呀

你们的软件概要设计/详细设计文档没有技术架构说明嘛

非常赞同。
看到所谓的测试平台快吐了

最近面试的几个人都有个共同点，会着重拿出自己写的功能来体现自己开发的技术能力，可一问他们公司业务的组成和架构时，又都答得支支吾吾。我是觉得现在的开发同学们还是要有点意识，得有个专精方向，别整这种业务来欺骗自己啦，看似做了前后端有种全栈的满足感，实际上大多就是把 CV 了啦，确实锻炼了 crud 的能力，可是证明不了你是一个优秀的开发，毕竟像这种 CV 工程师有太多参考的案例了，我更多是想知道你针对你开发的内容，有没有根据特定去做一些能够提升架构的，否则太同质化了。至于 crud 的能力，老实说扔一道代码编写的题目基本就知道得七七八八了

作为一个刚入行的新人，每天的工作职责就是点点点，然后提交 bug，目前测试部门连数据库和 libux 的权限都没有，实在没有办法理解该怎么去熟悉业务的技术架构和技术细节，包括做一些的提升质量的事情，这又该怎么提升呢？选择只有在网络看教学视频，学着自动化测试这块，实在没有扫码方向，希望有大佬能解惑

试问，不写这些，能进的了面试环节吗？

纬度不一样。

1. 真正的不容易失业的一线测试，一定是业务专家，需求/版本过我的手，就是可以大幅降低风险。极度靠谱，就不需要造轮子来证明自己的价值。
2. 但是讲到 TL，要养活团队，就不能只有点点点了，必须养一些技术人才，一个只知道测试管理，排期和堆人的 TL，大概率是做不大的。

好吧，确实待在大厂的时候比在小厂安全感多多了。。。
过了 40 以后，明显感觉精力不济，至少学习新东西慢了很多，只能追求笨鸟先飞了。。。

那么聪明如你，你觉得呢？

违法的

48 就存够钱了