初创企业购买企业邮箱_初创企业/企业：招聘工程师时，他们需要什么资格？

初创企业购买企业邮箱

tl;dr: It takes time to become qualified. Answer questions through articles and comments and you will get there sooner than later.

tl; dr：花时间才能合格。 通过文章和评论回答问题，您很快就会到达那里。

背景 (Background)

Having worked in engineering and operations at early startups, late enterprises, and consulting gigs, I have observed hiring contexts and what qualifications sped up the hiring process. If you are having difficulty in landing technical work, read on and it might help you out.

在早期创业公司，后期企业和咨询机构从事工程和运营工作之后，我观察到了招聘环境以及哪些资格加速了招聘过程。 如果您在进行技术工作时遇到困难，请继续阅读，它可能会对您有所帮助。

什么都不重要 (What Does Not Matter)

The level of excitement is not a big deciding factor when it comes to hiring.

在招聘方面，兴奋程度不是决定因素。

The company’s mission may be exciting and world changing, but its execution is measured, discussed, and iterated on indefinitely. Excitement fades over time. Persistence and perseverance are more sustainable (though rarer traits). Excitement is also a weak sign of lacking actual experience. If there are two candidates:

该公司的使命可能令人兴奋并且世界在变化，但是它的执行是无限期地衡量，讨论和迭代的。 兴奋随着时间而消逝。 持久性和毅力更可持续(尽管较罕见的特征)。 兴奋也是缺乏实际经验的一个微弱迹象。 如果有两个候选人：

A is really excited about coming to work and learning about the technology (zero prior experience).

A真的对上班和学习技术感到非常兴奋(零经验)。

B has worked in the field for over 2 years. B is not as excited as A.

B在该领域工作了2年以上。 B不如A兴奋。

B would get hired over A every time.

B每次都会被A录用。

Startup or Enterprise do not even come into the question.

启动或企业甚至没有问题。

Let’s hire the candidate who has done similar jobs before to do this job.

让我们雇用在完成这项工作之前已经做过类似工作的候选人。

初创企业资格 (Qualifications for Both Startup and Enterprise)

Prior Experiences

以前的经验

If you have solved similar problems before, you will stand out when compared to other candidates. Experienced folks require less training to get up to speed. They have more insights to offer when encountering errors in production. They have already spent time in reading the relevant documentations.

如果您以前解决过类似的问题，与其他候选人相比，您将脱颖而出。 有经验的人需要较少的培训来掌握最新知识。 遇到生产错误时，他们将提供更多的见解。 他们已经花了时间阅读相关文档。

For an early startup, the time to market and speed in pivoting are important metrics. Hiring someone who requires excessive hand holding and learning ramp pushes both metrics back. Startup’s idea of prior experiences will be if you have worked in other startups before, or if you have launched similar products.

对于早期创业公司来说，上市时间和枢纽速度是重要指标。 雇用需要过多握力和学习坡度的人会把这两个指标都推后。 如果您之前曾在其他初创公司工作过，或者您已经发布过类似的产品，那么初创公司的先前经验将是这样。

For enterprise, there are existing documentations and they often do not assume you will be contributing immediately on day 1. However, if you have worked in relevant fields, you will still take less ramp time and introduce less workload for the team involved. Enterprise’s idea of prior experiences will be narrower and more specific.

对于企业而言，有现有的文档，并且它们通常不假定您会在第一天立即做出贡献。但是，如果您在相关领域工作，则仍会花费更少的时间并为相关团队带来更少的工作量。 企业对先前经验的想法将更狭窄，更具体。

Seasoned Troubleshooter

经验丰富的疑难解答

Even if you lack prior experience in the field, there are transferrable day to day skills in the tech field. Finding errors and gaining understanding quickly is one such repetitive task. The more troubleshooting you have done before, the quicker you can get to the heart of a problem.

即使您缺乏该领域的过往经验，在技术领域也有可转让的日常技能。 快速发现错误并获得理解是这样的重复任务之一。 您之前进行的故障排除越多，可以更快地找到问题的根源。

To put in an overly simplistic fashion, there are four categories of errors:

简而言之，错误分为四类：

1. Crashes the program/service and is immediately noticeable. (Company website/API endpoint is down) Rebooting often works. But it will quickly spiral out of hand if left unchecked.
   导致程序/服务崩溃，立即引起注意。 (公司网站/ API端点已关闭)重新引导通常可以进行。 但是，如果任其发展，它将Swift失去控制。
2. Does not crash the program, but fails to perform the work. (Customers seeings error popups) Either you hear from the customers, or you will have no more customers if not triaged.
   不会使程序崩溃，但是无法执行工作。 (客户会看到错误弹出窗口)或者您收到客户的来信，如果不进行分类，您将没有更多的客户。

3. Does not crash the program, but performs the work incorrectly (Garbage in, garbage out). This will be difficult to detect, as customers themselves may not notice the error in plain sight for months. When data integrity is eventually questioned/exposed, customer will have good justification in switching to other platforms.

   不会使程序崩溃，但是会错误地执行工作(垃圾进，垃圾出)。 由于客户自己可能几个月都看不到该错误， 因此很难检测到 。 当最终质疑/暴露数据完整性时，客户将有充分的理由转而使用其他平台。

4. Does not crash the program, performs the work correctly, but takes much much longer span/more resources to do so. Can be caused by scalability issues/obscure firmware bug/misunderstanding documentation/rare corner cases. The longer you stay on a project, the more chance of observing this type of bug. Requires significant amount of probing and understanding to solve.
   不会使程序崩溃，不能正确执行工作，但是需要花费更长的时间/更多的资源。 可能是由于可伸缩性问题/模糊的固件错误/误解的文档/稀有案例。 您在项目中停留的时间越长，观察到此类错误的机会就越大。 需要大量的探索和理解才能解决。

For a startup, errors in category one and two can break the entire company during the product launch. Knowing how to bring the service back alive is essential to the business. The modern tech stack has many layers and moving pieces, you will ideally want to get your hands wet in operation in any capacity, and write up about failure modes for future references.

对于一家初创公司而言，类别一和类别二中的错误可能会在产品发布期间破坏整个公司。 知道如何使服务恢复活力对于企业至关重要。 现代技术堆栈具有许多层和可移动的部件，理想情况下，您将希望在任何容量下都可以湿透双手，并写下有关故障模式的信息，以备将来参考。

For enterprise with a respectable team size, error in category one are already solved. Product and deployment are stabilized and locked down. This leaves us with issues in the other three buckets. They all do not crash the program immediately but impact the quality of experiences for end users. There is no single silver bullet to tackle these problems. Observability (Tracing/Logging/Instrumentation) is a great suite of tool, yet they do not replace understanding. You cannot gain experience in troubleshooting without the right tools and field experience. Fortunately, this is not every engineer’s cup of tea, if you value future employment opportunities, stick around a live product and these bugs will come out from under the carpet on a weekly basis.

对于团队规模可观的企业，已经解决了第一类错误。 产品和部署已稳定并锁定。 这给我们带来了其他三个方面的问题。 它们都不会立即使程序崩溃，而是会影响最终用户的体验质量。 没有解决这些问题的灵丹妙药。 可观察性(跟踪/记录/仪器)是一套很好的工具，但是它们并不能代替理解。 没有正确的工具和现场经验，您将无法获得故障排除方面的经验。 幸运的是，这并不是每位工程师的功劳，如果您重视未来的就业机会，坚持使用实时产品，这些臭虫将每周从地毯下冒出来。

K.I.S.S. = Keeping It Simple, Clark Kent

吻=保持简单，克拉克·肯特

Junior engineers are encouraged to stay up with the latest trend to maximize resume keyword matching. However, each new frameworks learned bring in additional unwanted complexity when running in production. Knowing how to solve the problem at hand (rolling out a product/implementing a new feature) by introducing the least amount of surprises is great help to the team’s sanity and well-being.

鼓励初级工程师紧跟最新趋势，以最大限度地提高简历关键字的匹配度。 但是，学习到的每个新框架在生产中运行时都会带来额外的不必要的复杂性。 通过引入最少的惊喜了解如何解决手头的问题(推出产品/实施新功能)，对于团队的理智和福祉非常有帮助。

Your company’s customers do not care about what kind of frontend framework you have switched to, but they will care when the site is not loading, frozen, or showing error popups. Customers demand availability and consistency.

公司的客户并不关心您切换到哪种前端框架，但是他们将关心站点何时不被加载，冻结或显示错误弹出窗口。 客户要求可用性和一致性。

Your teammates do not care about new syntaxes and frameworks that just came out last week, but they will care if it breaks code compilation when they need to touch it. Teammates demand convention and stability.

您的队友并不在乎上周才出现的新语法和框架，但是他们会在需要触摸时是否在乎它是否破坏了代码编译。 队友要求惯例和稳定性。

Your operators do not care about how much better you have made the product, but they will care about new dependencies and in-place upgrades happening in a short span of time. You better have good tangible reasons to make any deployment more complicated.

您的运营商并不在乎您的产品质量有多高，而是在短时间内发生新的依赖关系和就地升级。 您最好有明确的理由使部署更加复杂。

That is not to say you should never make any effort to improve the codebase with refactoring or trying out new frameworks and languages. There are simpler ways of achieving those things:

这并不是说您不应该通过重构或尝试新的框架和语言来努力改善代码库。 有更简单的方法可以实现这些目标：

Do it in a new company project. Ask for feedback from more experienced teammates. Try it in a personal pet project first. Create tech documentation for knowledge transfer: are you able to convince at least one other person?

在新的公司项目中进行操作。 寻求经验丰富的队友的反馈。 首先在个人宠物项目中尝试。 创建用于知识转移的技术文档：您是否能够说服至少另一个人？

Writing and Communication Skills

写作和沟通技巧

Lastly, you might as well be the most qualified candidates in this round of the interview. You have prior experience/put out many fires/evaluated many technologies outside of work. But, without the ability to communicate those qualities to your potential employer, they will pass you by and give the opportunity to someone who puts more effort in presentation.

最后，您最好还是本轮采访中最合格的候选人。 您具有先前的经验/在工作之外扑灭了许多火灾/评估了许多技术。 但是，如果没有能力将这些素质传达给您的潜在雇主，那么他们将使您失望，并给那些在演示方面付出更多努力的人一个机会。

When it comes to interviewing, we are all working with a time constraint, you do not want to be an escape room with no hints. Recruiter and hiring managers cannot read minds, even when it looks like they can.

在面试方面，我们都在时间限制下工作， 您不想成为没有提示的逃生室。 招聘人员和招聘经理即使在看起来可以的情况下也无法阅读想法。

We all know that one teammate who gets a lot done in Git, but never writes any comment and documentation. (Could be you and me, right now) Yes, they can implement features in half the time. But, they can never get sick or take a vacation, because their work is not understood by others at all. Manager will ask them to train a backup person to mitigate this issue, and only then will they make attempts in creating documentation.

我们都知道，有一位队友在Git中做了大量工作，但从未写过任何评论和文档。 (现在可能是您和我)是的，他们可以在一半时间内实现功能。 但是，他们永远不会生病或休假，因为其他人根本不理解他们的工作。 经理将要求他们培训备用人员以缓解此问题，然后他们才会尝试创建文档。

Don’t be this person. Write documentation today. If you catch yourself answering the same question more than 3 times in slack, it is time to create documentation about it. If no one is asking any question about your work, write documentation anyway just in case.

不要这个人。 立即编写文档。 如果您懒惰地回答同一个问题超过3次，那么该创建有关此问题的文档了。 如果没有人对您的工作有任何疑问，请以书面形式写文档，以防万一。

No one comes up with the perfect answer during knowledge transfer on their first try. Every person would have their own gaps in understanding. Having a documentation available is the first step in discovering where the gap is. (Step 0 is when you are asked the question)

在首次尝试时，没有人能提供完美的答案。 每个人的理解力都有自己的差距。 找到可用的文档是发现差距的第一步。 (第0步是询问您的问题)

All of your experiences and troubleshooting skills and elegant simplicity are only remembered through your words on your blog/stack overflow replies/Github Wiki documents.

您在博客/堆栈溢出回复/ Github Wiki文档上的文字只能记住您的所有经验，故障排除技能和简洁的优雅。

As for qualities specific to Startup and Enterprise teams, stay tuned for part two of this article! Thank for reading. If you are looking for Production Monitoring/AWS Services consultation, be sure to reach out to us via email at info@teamzerolabs.com

至于特定于Startup和Enterprise团队的素质，请继续关注 本文的第二部分 ！ 感谢阅读。 如果您正在寻找生产监控/ AWS服务咨询，请务必通过电子邮件与我们联系，电子邮件为info@teamzerolabs.com

翻译自: https://medium.com/teamzerolabs/startup-enterprise-what-qualifications-are-they-looking-for-when-hiring-engineers-da2d52006375

初创企业购买企业邮箱