Skip to content

Latest commit

 

History

History
127 lines (78 loc) · 6.09 KB

interviewing.md

File metadata and controls

127 lines (78 loc) · 6.09 KB
Raw

Tenets

Above all,

  1. Hire for motivation.
  2. Hire those motivated by others’ motivation. (Do not hire anyone that will get in the way of others’ good work.)

Cultural Values

  1. Don’t have a work allergy

We’re in this because building things is awesome. Sometimes it’s building skyscrapers, and sometimes its digging ditches.

a.k.a. Bias Toward Action

Don’t implement the bleeding edge unless it provides business value that nothing else can. Don’t over-engineer for a dirt-shoveling task that takes 30 minutes, 5 times per year. Don't wait on others to solve problems for you..

  1. Our method is science, Our aim is religion

Not that kind of religion. SEO as a religion. Webperf as a religion. Code quality as a religion. Shipping as a Religion.

This is Consensify made into a science.

  1. Everything sucks, don’t be pessimistic

The Good Egg principle. Good judgment and analysis can only make things better, but griping without a solution just makes for distracting drama.

  1. Lifelong Learning

This is, and always will be, a collegial environment. Tech will never stop mutating. Keep learning. Learn foundations, and then the foundations they're built upon.

  1. Foxhole

Choose to work with people who you would trust to have your back. (literally, as the metaphor goes) Remember what it takes to succeed as a team, not just as a person.

Work with doers that 'walk through walls' and bend reality.

  1. Done Done

Work toward the spirit of things, not the letter. 'CYA' is just a lesser form of failure. Remember to be a Good Egg.

Topics for Behavioral Questions

  • Moderation and Conflict management
  • Influence, Rapport, and Trust
  • Teamwork
  • Action-oriented / self-motivation
  • Adaptability
  • Creativity
  • Goal setting
  • Decisiveness
  • Time management / multitasking
  • High-Pressure Scenarios
  • Analytical Thinking

These are not to be considered comprehensive, nor concise. Assessing behavioral traits is not an exact science, nor is it easy to find agreement on 'norms' among a group. They can often be modeled to the operational patterns in a business/team. e.g. Sales teams may have more around the topic of rapport and communications.

Though this chart can be excessive, most of these pressure exist in people, in the way the react to their job, if not also their life. While it's important to not over-psychoanalyze anyone, it is important to help them untangle their pressures. The best professionals will self-manage the differentiation of personal development from work development.

Career Paths

I still sit with the largely-typical career ladder.
Management and executive titles go with people and leadership skills. Principle, Architect, and similar titles remain in the code — specifically: measuring and teaching. SREs are in both main branches.

How you grow, is another topic.

I still see lots of architect roles being performed like a (TPM) technical project manager. Doing so skews expectations and the market. It's not a 'tinker neat things' position.

Also, I like to highlight where engineering intersects other departments and teams.

  • Data science.
  • Data warehousing and BI.
  • Security.
  • Risk, compliance, QA automation.
  • Sales and solutions architecture.
  • Product and Program ownership.

These are often overlooked areas, and are viable career paths if a person doesn’t squarely align to Engineering.

Code Samples vs Code Tests

The point of the sample is to give something to talk about in at least one of the interviews they’ll have. This often works better than whiteboarding, as the time it gives to prepare is similar to a normal work environment. Likewise in allowing for more cogent explanations of the next design directions.

  • the sample is about an interactive/convo part of the process, which is also healthy
  • it’s not a “test”, as that doesn't pan out as people gain more experience.
  • "testing" is pedagogical, and we're not in school anymore, nor are most of us curriculum designers.
  • a sample invites many examples that someone may have to share.
  • whiteboarding is often overused in the attempt to measure many things at once.

We want to keep flexible on what someone sends for a sample. It could be a Project Euler workbook, a good piece of open source code, or a signature piece of code wrote in the past. Obviously it's not appropriate to share code from a current employer, as it breaks trust for past and futur eemployment.

Specs for a Code Sample

If none, a code-sample format (or spec) will ideally ask a minimum of complexity, while covering a range of demonstrable practices.

Good specs for a code sample will ask for something that is complex to know, but easy to implement. Often this may involve a design pattern common to a framework, and one similar to that used in the portion of the framework for the role. e.g. any middleware pattern for fullstack engineer, any frontend framework for FE.

It should be relevant to the area of industrial practice. Writing stack, parse, or graph-structure implementations may suit some enterprise environments, but be meaningless for an agency.

Questions to look for from Product candidates

  • How do you measure this product’s success?
  • Where do ideas come from?
  • What are you excited to work on in the next year?
  • What challenges do you want to solve?
  • What skills or personality traits does someone need to thrive in this role?
  • Product Must Be Essential — how is it so?
  • In what ways is the Product not Intuitive?
  • Who really experiences delight from the product?

Then, what do they stand for, and how do they seem themselves aligned?

References

  • #DisruptTechInterviews
    • Nerves / style under pressure
    • Context / Encoding Specificity
    • strategies
    • measures
    • flow / big picture