
How to Hire Great Engineers - bink
https://autoiterative.com/blog/posts/how-to-hire-great-engineers/
======
d_burfoot
I think a lot of small/medium companies should simply get realistic about the
following facts:

\- They are probably not going to be able to hire "great" engineers

\- Even if they get a couple of great engineers, they are not going to be able
to create an engineering culture where those engineers can do great work.

Instead of looking for "greatness", most companies in this position should
simply settle for competence. Hire people who use boring technology and build
systems that do things simply and directly.

~~~
dcewcrrec
I don't like this negativity. Pay and position doesn't necessarily reflect
competence. I don't buy that the smartest engineers in the world are all
working for big companies.

~~~
danielrhodes
That's because people are obsessed with this idea of a one-size-fits-all great
engineer.

A generally great engineer to a startup is somebody who can ship fast, make
good enough decisions and trade offs, can think on their feet, and is a jack
of all trades.

A generally great engineer to a big company is somebody who can work well with
others, can follow process, can work within huge code bases and abstractions,
and follow architectural best practices.

These two do not necessarily overlap.

------
protonimitate
I really like the idea of "chopping the onion". I've personally had a handful
of devs who passed our interview process with flying colors, but couldn't
actually deliver anything once they got in the door. They could recite any
leetcode problem from memory, but didn't know how to contribute value to their
team or company.

> The grading is automatic. I think is ok as _one_ metric, but I wouldn't want
> it to the be the _only_ metric that is being looked at. ICs aren't really
> ICs. You can be a JIRA champion, knocking tickets into the done column at
> the speed of light, but Great Engineers do more than just that.

Great Engineers build up their team, and help others grow. They know how to
push back on unrealistic asks. They can incite help when they get stuck. They
can translate complex issues into digestible bites. Writing good code is the
bare minimum quality of being a Great Engineer.

The main barrier I see to hiring Great Engineers is that you really need to
hire Great People. But a lot of hiring practices are taking all the human
aspects out of hiring (except for the "behavioral" questions, but even these
can be gamed like system design or leetcode). Great People worthy of hiring
are driven, passionate (not "spent all my waking time coding", but "truly
believe in the mission/goals of the company/project"), empathetic,
intelligent, and trust worthy. None of those traits are easily discernible
from random logic puzzles.

I don't know what the solution is. At some point there has to be a "can
actually write code" litmus test, but I don't believe any of the current
methods work well to prove that. I think take home tests are closer to the
"chopping onions" idea, but only require commitment from the applicant, not
the employer, which leads to a lot of wasted time.

Personally, I think temp-to-hire or work-for-a-day type models could work, if
there was some standards to prevent abuse. I would rather sacrifice a few days
to a week to see if I actually like working somewhere, and to prove to them
that I can do the job, then look at CTCI ever again.

~~~
Fiveplus
> handful of devs who passed our interview process with flying colors, but
> couldn't actually deliver anything once they got in the door. They could
> recite any leetcode problem from memory, but didn't know how to contribute
> value to their team or company.

Interesting, why do you think was this the case?

~~~
alpha_squared
Not the person you're responding to, but my perspective is that there is often
a false equivalency between academic understanding (solving hard/clever
problems) and productive development (meeting deadlines, building/fixing
projects). Many of the stereotypical developer interviews assume "good
developers" who are good at one are good at the other. My anecdotal experience
is that most are not, they excel in one or the other.

~~~
Olreich
I don’t think they are exclusive, you can be a great engineer that knows all
about the algorithms in CS books and keeps up on the latest research in parts
of the academic field. They aren’t even different skill sets, just different
places to find the knowledge. Game development and cryptography bear this out
well. The top engineers are the ones that read all the papers and that can
build solid systems based on them.

~~~
alpha_squared
I don't think I framed it as exclusive, but that the intersection of both sets
of skills is uncommon (I attest they are two different sets). Sure, you can
aim to hire only people who excel in both, but the typical software interview
certainly doesn't assess the latter.

------
krschultz
> Second—people who had spent the last month memorizing the “Cracking The
> Coding Interview.” They will pass as well, but you will have no assessment
> of whether they can apply their knowledge. That is, until their first
> deployment to your production environment.

Everyone criticizes this, including me before I decided to capitulate to the
system and do it myself. But it's actually kind of fair? Everyone knows the
game. Some people will choose to train hard enough to play, some people will
not. That is a signal in of itself as to whether the candidate will work well
in the big tech company environment.

~~~
unscaled
I didn't read it as criticism of the engineers reading “Cracking The Coding
Interview.” - if you want to pass algorithmic interviews you have to read it
or something equivalent - or be fresh out of college.

But just as this post says, as a hiring manager, you'll get very little
insight into how good the candidate is until _after_ you've hired them. This
does serve as a weak signal for dedication, but:

1\. You don't want to make your hiring decision _only_ based on dedication.

2\. There are other, better signals for dedication.

~~~
kamaal
>>very little insight into how good the candidate is until after you've hired
them.

The fact that one depends on a proxy measurement which has little correlation
with actual results is the core of the problem here.

------
raziel2p
Engineering is vastly more complex than chopping onions. I strive for the
ability to on-board in less than a day for projects I work on but it's not
realistic in many cases. Companies need to put effort into having small side
projects with dedicated github issues only meant for these candidates
(anecdote: the few companies I've applied to that do this type of thing did
not do a good job: their tickets were vague, lacking context, and mostly just
led me wanting to talk to the PO).

Many engineers are also looking for jobs while they currently have one, making
a half/whole day "trial" very difficult or impossible. Asking people to commit
their weekend or free time is also discriminating against those with families,
social lives, and those who just like leaving programming behind when office
hours are over.

The article only talks about algorithmic interviews. There are plenty of other
interview styles that delve into more pragmatic problem solving that still
aren't perfect, but work much better.

~~~
jordan801
Contract work would work similarly for engineers. Do it on your own time if
you have a job.

They can ask the current team questions via chat. Get some real code into PRs
and prove that they have skills.

Personally I don't even apply to jobs anymore. I am tired of 6+ hour code
reviews that I don't get paid for, and no explanation when I get passed up.

I would much rather be a contract worker and get paid at least something while
doing actual work, over building a search engine for star wars characters.

I'm exactly like what you describe. When I leave the office, I want to camp,
rock climb, and prep for marathons. I don't want to spend more time coding.
That's exactly what makes me absolutely disgusted with applying for new
opportunities. Eight interviews with various people, just to get ghosted. Time
I could have been improving at other passions. Instead I'm left with no time,
no indication of what I can improve on, and no job.

~~~
Icathian
I see sentiments like this expressed sometimes, and I'm usually a bit
confused. Are you currently employed, and if so is it in a permanent role or
as a contractor? What do you plan to do the next time you want to change jobs?

Genuinely curious here, I only know one model and it works well enough for me,
but you seem to have a different one and I'd like to know more about it.

~~~
jordan801
I have been fully employed for years. Though I have sought a less abusive
relationship a number of times.

Obviously, should my current security evaporate, I would resolve to deal with
the process.

I'm not entirely sure what you're confused about. Nor, what model you refer
to.

------
eternalban
_" The restaurant industry figured the hiring way better than the software
engineering industry! They test both professional skills and cultural
alignment! In other words, they test your ability to deliver. They do not ask
you to explain a recipe by heart or describe how you would chop the onion.
They ask you to do it. Live."_

It's ironic that the article points out the error in blindly imitating others
and then we get this entirely apples and oranges 'recipe for effective
interviews'.

What are the fixed costs of having a 'live' chop the onions and shoot the
breeze on slack for software companies? For a restaurant, they simply need a
bit of tabletop for the 'new workstation'.

\- All onions are pretty much the same in one industry; in our industry, we
famously have 'a new way to slice onions' every other day! Let's not even
discuss the variety of knives ..

\- What 'secret sauce' info is disclosed during the 'live' getting to know
each other? Can we just put candidates in company slack and check out how it
works? Seems problematic.

------
ryanianian
So much nope to this.

> They would put you to the test for like 2-3 days to see how you perform

And pay you. And give you some level of feedback along the way, not just "here
make some salads" and then "nah nevermind" after 3 days of hard work. And you
get to work with them and decide if you like working there too. It's not a
one-way street like these bullshit homework interview pipelines.

Unlike in food, you're not going to be productive with real code for a few
months. Unlike in food, just doing the coding is only 40-60% of the job.
Unlike in food, it's hard to improvise code in a language, framework, test-
style, knowledge-domain, or other toolset you may not be familiar with. Hiring
for restuarants is not a relevant comparison.

This just seems like the typical unpaid homework assignment--which is usually
a couple softball algorithm questions mixed with some arbitrary glue-code
riddles--with some CI-flavored slop on top.

~~~
yakshaving_jgt
> you're not going to be productive with real code for a few months

I've hired several engineers who get productive within the first week. Most
manage to get in a PR and deploy to production by the end of the first day.

If it's taking a few _months_ before the candidate can get productive,
something has gone horrifically wrong.

~~~
pmiller2
> If it's taking a few months before the candidate can get productive,
> something has gone horrifically wrong.

There's a big difference between "deployed their first PR" and "getting
productive." The latter implies the engineer knows or has figured out how to
use your source control, CI, and deployment processes. That probably is
something most people can manage in a day, with proper instruction, provided
the code change itself is simple enough. The latter means they're familiar
with large parts of the codebase and are able to make changes, and have an
idea how the major parts interact. This is what takes a few months.

------
kanobo
Chopping the onion? This is very roundabout advertisement. Why not just post
your company's homepage? At least the information is more direct.

~~~
jimbokun
It is a very direct advertisement.

------
Tehdasi
I've always thought that a good way to do a practical interview is to get the
candidate to do a fizzbuzz. Then tell them that the requirements have changed,
they need to add feature x. Then feature y, and so on. I reckon this would
avoid ppl who just learn the test, and comes some way to emulating what
actually happens in a real world job.

But anyways, I'm not a hiring manager, so someone go out and try this and tell
me why it's a terrible idea.

~~~
nhumrich
This is exactly how I do my interviews. I have them "whiteboard" (or use a
real computer) to wrote a very simple function, then I change requirements
when they are almost done to see what they do.

------
comvidyarthi
I do not agree with the premise that the best way to hire engineers is to
follow the hire—chef model of restaurants. I don’t think it’s fair in any way
to ask someone to work for free for few days, while you keep the candidate
guessing whether you will give the job to the candidate or not. Also how can
one plan to hire engineers who already have day jobs? Should the engineers
take 3 days leave from their employer every-time they try to interview?

This kind of model is way too biased towards employers and gives them too much
power to exploit, in an environment where employers anyways have a lot of
power as compared to one employee (prospective candidate in fact, not even
employee). This reasoning works well for companies whose job is to recruit or
help recruit engineers. After all, they are being paid by the employer and not
the candidate, so they want to make the process optimal for the employers. But
as much as I like the doing the right thing for customer attitude, this seems
like taking that to an extreme and exploiting everything that isn’t paying.

~~~
908B64B197
> This kind of model is way too biased towards employers and gives them too
> much power to exploit, in an environment where employers anyways have a lot
> of power as compared to one employee (prospective candidate in fact, not
> even employee).

And the issue with that is that great talent will simply lose interest. Unless
of course the company is willing to be extremely aggressive salary-wise or is
a leader in a very visible field (SpaceX). Because they typically have have
multiple offers on the table.

------
yeswecatan
Hiring is not a one size fits all problem. It's true that early stage startups
could probably use more product-minded engineers
([https://blog.pragmaticengineer.com/the-product-minded-
engine...](https://blog.pragmaticengineer.com/the-product-minded-engineer/))
and engineers who can ship code fast with the drawback being that it's not as
scalable. Even then, different teams have different needs. Some need people
who just want requirements and go. Some teams need junior developers, some
need senior.

------
zihotki
Half of the article is just an advertisement of their service.

~~~
jimbokun
The entire article is an advertisement of their service, and it is a pretty
well executed advertisement.

By the time I got to the end, I realized it was an advertisement, but still
felt I had learned something useful.

~~~
ilyaa
Thanks! Full disclosure -- it is my first advertisement, ever, so I'm glad you
liked it :)

I would challenge the assumption that this is purely advertisement, though. In
my head, this is not "buy our shit™" type of post -- in fact, there's no
mention of buying the subscription anywhere. All there is is a link to a demo,
with a valid challenge (not a fizzbuzz/fibonacci, but one you can actually
have a lot of fun with), which we provide for free to anyone, w/o even
requiring valid email -- it is up to you if you don't wanna reset the password
later. Instead, the post is more of a "use the right metric -- here's our
experience and what has worked for us" type of post.

Would you agree that this is a more fair assessment?

~~~
Terretta
As of 2 Aug, can’t read your ad. Your cert expired today.

~~~
ilyaa
yup, shame on me for that. thanks for headsup, this was addressed.

------
kevsim
I’m not sure better coding exercises is the solution here. What you want to do
is bring people in for a week and let them work with the team. But unless
you’re the hottest thing in town, no one is going to spend a week with you, at
least most likely not the people you want to hire.

~~~
nutshell89
I guess the argument is that the restaurant industry does it all the time -
hell, hiring a designer will often involve assigning them a project, having
them give a presentation on it, and asking questions about their portfolio.

We tend to put more trust in end product in that regard more than any specific
process (like quizzing them on the process to create a specific animation in
After Effects or on interaction cost or cognitive ergonomics).

------
commandlinefan
So... restaurants hire people by giving them onions to chop and seeing if they
can make good jokes. Every white collar job that's ever existed hires people
by checking resumes, checking references, considering education and past work
experience and a face-to-face introductory meeting. So, is programming (sorry,
"engineering") more like cooking food or more like every other job where you
sit in an office and work toward delivering business value?

~~~
scarface74
Amazingly enough, restaurants don’t see if chefs can grow food and raise
cattle, yet big tech does expect you to be able to reverse a binary tree on
the whiteboard.

------
ChrisMarshallNY
I know someone that was hired by Plex. He spent a couple of months as a
contractor before they hired him.

I assume it worked out, because he's still there.

I was a hiring manager for a long time. I seemed to make good decisions, most
of the time (a couple of notable exceptions). I kept fairly senior-level
employees on board for decades.

I don't know if I ever developed a "system." It was always important for me to
establish as much of a relationship with the prospective employees as
possible, up front; which meant treating them with respect, and being open and
emotionally available to them. I found that an attitude of trust and respect
goes a long way to figuring out how people will deal with you and your team.

Tests were worthless. I _loved_ portfolios, and discussing the details of
projects they had done. I did a great deal of homework before each interview;
carefully reviewing their resume, and finding out about as much as I could.

From all that, I have learned to be an "open book," myself. There's really not
much about me that can't be figured out with some quick googling. That's on
purpose.

But this seems to be more or less an advertisement for their company. It may
be a good idea and a good company, but I can't really say.

------
ilaksh
"We automatically test not only that the solution complies with the problem
definition, but that it works correctly, that it handles edge cases and
errors, that it replies within latency tolerance, and that it keeps working
when we throw a lot of load at it.

The candidate only has access to the initial test that gives them early
feedback on how they are doing. The rest of the stages are visible only to the
hiring manager."

I almost love this, except for the second paragraph. It sounds as if you can't
see how well your code performed in latency, load tests, or edge cases. That
does not seem like a realistic simulation of work, because normally one would
need to iterate a little bit to optimize those things.

I mean I know I would prefer to just do an average job passing the core tests
before I try to completely optimize it. Are the candidates even informed that
the latency and load tests exist?

I think it could be okay if you just mention that is part of it and there is a
straightforward way for them to do their own latency and load testing.. so
hopefully that's the case?

------
santoshalper
I don't agree with the author's (salesman's) conclusion. Most software
engineers in a small company are going to do a lot of design. There won't be
architects or principal engineers doing the design for you.

The kind of "chef" you interview by asking to chop an onion or cook for a few
days is not the type of chef you are probably going to ask to design the menu.
You're not making the menu, it's an almost pure execution role.

One of the things that can really set a great engineer apart is the ability to
design elegant systems and manage complexity. You're likely not going to find
that out coding with them for a few days unless you make sure to index for it.

Ironically, bigger companies where much of the design is centralized would
benefit from this approach much more. They can get a lot more out of a "grunt"
engineer who does journeyman work and is careful about testing.

------
dotemacs
Yes, this is an ad for their service. But then, you are on HN, not on
Lobsters.

I think that this is great idea that you're trying this. I hope you stick with
it and succeed. Because it would be great to be able to hire and be hired,
where you're not competing on how cheap you are or some other demeaning
metric.

Godspeed.

------
site-packages1
> Small and medium companies pick the crumbs of those rituals and fall into
> cargo culting. They want to reap the same promised benefits of the obscure
> interview rituals. Yet they miss the reasons behind these rituals and do not
> fully understand what trained interviewers exactly seek.

Just my opinion, but I think this line comes across as a little too
condescending or perhaps paternalistic. I work at a small (40-50 ppl) unknown
to you company and all of us (so far) are senior in our fields and largely
have FAMGAN experience on our CVs. We’re not just cargo culting, but rather
taking things from the FAMGAN hiring processes that make sense and using them.

~~~
ilyaa
Hey, post author here. Apologies if it sounded paternalistic, that was
definitely not the intention.

I would argue that 40-50 senior people in one place would be rather an
exception from the norm, and your company would be quite an outlier on the
bell curve. If all of you are not just seniors, but also had first-hand
experience participating (or even building) in hiring loops of the large
companies, then you would have all the necessary knowledge of why those
rituals were created, and why. The point of the blog post was that this is
usually not the case, so the imitation is the only option.

Could you elaborate on your hiring loop? Which of the stages is the most
effective and brings you the most value?

------
scarface74
_...and if you share the same kind of jokes and values._

 _Cultural alignment No less important is the cultural alignment, the “Can I
work with you?” question._

This screams all sorts of “isms” to me.

~~~
amflare
No, an -ism would be to deliberately reject an individual that _did_ fit
cultural and merit based parameters for reasons unrelated or not under the
control of the individual.

------
GoToRO
I was like: No. No. No. Up until I reached “Cultural alignment”! Then I was
like: hell no! You know who does “Cultural alignment”? All the dictatorships
in the world!

I once worked with a guy that was very difficult. People warned me ahead of
time. I made sure to accommodate him and we got it done. Otherwise, he would
not fit anywhere, he would be jobless and then what?

If you don’t respect the people’s right to work, you exclude them from
society. And then what do you think it will happen?

------
fxtentacle
How do they prevent people sending the problem to a friend or a paid advisor
and, thus, letting someone else solve it for you?

"The same happens with time-constrained problem-solving. That’s not how real
life happens. People need time to think and reflect on the problems they face
to build the right solution. Because of this, we do not artificially limit
time for solving a challenge."

sounds very critical in that regard. If you have lots of time, that makes it
much easier to get outside advice.

------
Traster
I wonder if other industries spend quite as much time focusing on how to hire
exceptional people? Do we see articles in "The Stage" magazine about how to
hire the next Lin-Manuel Miranda for your next production? Do we see Human
Resources industry magazine publish a thousand pieces about how to spot the
next Hannibal Lecter to really boost your HR teams performance?

------
dcewcrrec
Does anyone else feel like it should be illegal to make someone go through 3
or 4 interview stages, essentially making them work for free, only to not give
them the job?

On another note, if your code base uses very niche software and there aren't
too many people out there who know it, what's the process for hiring an
engineer that will be able to learn it? What do you look for?

~~~
Traster
I don't think you can sensibly say that most interviews are making people
"work" for free- you're not going to get any productive work product out of an
interview unless you're literally making someone do a trial shift in a coffee
shop, which I think people would agree is scummy. That doesn't really happen
in Tech. I can pay you to do our coding test, but I don't think anyone can
reasonably argue that 350 different solutions to the exact same toy
programming problem has any value to my company. Also, what am I going to pay
you? Minimum wage? £20 or so? We could do that, but I'm not sure it would make
any difference to anyone but the most marginal candidate.

------
oxfordmale
The difference is that you get paid at a restaurant for chopping onions, even
if it is for three days only. A highly valued IC wouldn't have time to spend
three days coding for free. On the other hand someone can outsource this to a
skilled developer in India or a friend who is good at coding.

~~~
jimbokun
> A highly valued IC wouldn't have time to spend three days coding for free.

So pay them, even if it's just a token amount. At least shows some
appreciation for the candidate sacrificing their time.

------
Animats
Anyone try their "demo"? Is it any good?

(Oh, autoiterative people? Where's your privacy policy? Where's your opt-out
of tracking link? For that matter, where's your company? And why is your
domain registered via WhoisGuard out of Panama?)

~~~
ilyaa
Hey John, how about you try it yourself? For the right mindset, I've been told
that it is very fun and addictive :)

Thanks for the questions, let me elaborate:

    
    
       - I didn't have time to prepare privacy policy, but we'll indeed make one and post it. You're right, we should have it.
       - There is no tracking. Never will be. We'll blog about why we're for 100% anonymity of the candidates in more detail, but for now: We don't collect names. We don't require valid emails to enroll in the demo. We don't use tracking cookies. We don't send HTML emails with tracking pixels, and we don't use any 3rd party service. We use cookies to authenticate you, and that's it. Javascript, social media buttons, or trackers or analytics of any sort on our pages are considered a bug. What we don't have, is a proper explicit privacy policy explaining all that.
       - We're a European company.
       - That's how Namecheap sets it up -- curious, why do you think it is a bad thing?

------
908B64B197
I'll copy-paste and expand something I wrote earlier about interviewing [0]. I
think you are spot-on that algorithmic interviews are a form of cargo culting
and that they select for the wrong thing but that's not because they are
algorithmic interview; it's because they are poorly conducted.

I'll play devil's advocate and defend whiteboard interviews as compared to
take home or online assessments. Take homes are not very respectful of the
candidate's time and, especially if they are not time bound, often leads to a
candidate wasting a significant amount of time on these assignments. Plus,
there's always the possibility that desperate candidates would cheat and have
the assignment done by someone else.

I would only use take homes and HackerRank style quiz for applicants that are
from institutions I don't fully trust with quality or applications that are
very spammy in nature, i.e from a college/bootcamp that has an abysmal
application-to-hire ratio [1].

For candidates from serious institutions I favor a two-step approach: a
screening interview with a light coding question and a full whiteboard
interview. The screening's purpose is really only to answer questions about
the hiring process and check that the candidate can write very simple code by
himself when given a trivial problem [2]. Something not more complicated than
FizzBuzz really.

A lot of folks do whiteboard interviews wrong. They often expect to get the
exact implementation of an algorithm they found in a textbook and for code on
the board to compile. This isn't the point of whiteboarding. Doing this only
promotes rote memorization. A good whiteboard interview should be a toy
problem that can be solved in several different ways by using different
strategies or data-structures. The idea is to see how the candidate will break
down the problem. Is the candidate able to formulate test cases, write a
simple implementation, verify his code and correct the implementation should
it fail a test? On the more meta side of things is the candidate able to take
feedback and explain why a certain strategy was chosen? Of course, it's not
representative of real world engineering but it's a good way to peek at
someone's ability to debug and reason about programs; these abilities
translate well into debugging and design. Especially at the college level, I
really can't make any assumptions on what the candidates know.

People, especially non-technical, over-emphasis on knowledge of specific
languages and framework and disregard computer science fundamentals, and I've
been doing the exact opposite. I'm not judging their knowledge of the standard
library of X programming language or the framework-du-jour but their ability
to learn it fast.

Now, large tech companies optimize hiring at the college level because that's
when everyone is on the market at the same time [3]. It's also why they have
internship programs, to make sure that the best talent is already in the
hiring pipelines a few years before even getting their diplomas. After that
initial post-graduation job search phase, you'll see great engineers often
spending several years at the same company and not even looking for a job.
They are often the strongest candidates and totally invisible to recruiters.

Lastly, you can either really hope hard to find a diamond in the rough at
whichever market rate you set or decide to compete with the companies that are
actually attracting top talent. There's really no secret formula it's:
compensation, interesting projects, technical career path and technical
management. You can try to play games with CoL or market rate, but just keep
in mind that if you do some of the top applicants won't even bother sending a
resume in the first place.

[0]
[https://news.ycombinator.com/item?id=23989466](https://news.ycombinator.com/item?id=23989466)

[1]
[https://economictimes.indiatimes.com/tech/ites/95-engineers-...](https://economictimes.indiatimes.com/tech/ites/95-engineers-
in-india-unfit-for-software-development-jobs-report/articleshow/58278004.cms)

[2] [https://blog.codinghorror.com/why-cant-programmers-
program/](https://blog.codinghorror.com/why-cant-programmers-program/)

[3] [https://www.inc.com/magazine/20070501/column-
guest.html](https://www.inc.com/magazine/20070501/column-guest.html)

------
throwawaygh
I feel like the crux here is requiring real work for 3-4 days. In addition to
screening time and so on.

A few days of a truly great engineers time costs like 4K-5k. At least.

------
acd
Actually if you think differently it’s better. This is like diverse team
skills. If you are the same what difference does you bring to the team?

~~~
snoman
It's not as straightforward as 'thinking differently'. Diversity of knowledge,
experience, and skill is extraordinarily valuable but if you...

* hoard knowledge

* refuse to elevate those around you

* are frequently combative

* lie about your knowledge/experience

* seek to be right instead of discover optimal solutions

... then all of that diversity is lost or wasted.

It's not about diversity for diversity's sake, it's about sharing in diversity
and using all of the differing perspectives to reach optimal solutions that
your organization would be blind to otherwise.

------
kodbraker
What's the blogging engine? Looks familiar

~~~
Narigo
I suspect Hugo:
[https://autoiterative.com/blog/index.xml](https://autoiterative.com/blog/index.xml)

~~~
ilyaa
You're spot on. We use hugo with a custom theme, which is derived from etch
([https://themes.gohugo.io/etch/](https://themes.gohugo.io/etch/)).

------
ilyaa
Hey folks! co-founder here, I'm one of the people behind autoiterative.com. I
did a ShowHN yesterday[1], but obviously, the blog post provokes much more
engaged discussion, love it ;) I appreciate your feedback, please keep it
coming and challenge our assumptions!

I will try to address the questions tomorrow, I already see some of them
require a ton of thinking indeed.

[1]:
[https://news.ycombinator.com/item?id=23986002](https://news.ycombinator.com/item?id=23986002)

~~~
busrf
Hi Ilya, I saw in your linked post that this started as an internal tool to
assess candidates which you then spun out. Could you talk more about that? How
many people did you screen and hire with this tool?

~~~
ilyaa
Hi! Thanks for asking. We will blog about it in more detail, but I can give
you some numbers right away. At the moment when we decided to start making it
into a product, we've been using this approach for roughly 4 months. During
this period, the data was: \- we processed roughly 600 candidates \- of which
we hired about 50 \- per-recruiter rate of processing people increased from
15/month to 100/month \- average invite-to-offer time reduced from two months
to two weeks \- on top of that, the number of challenges to review by our
engineers dropped by 60%. The explanation of why will be in our next blog post
about the cost of engineering engagement.

At this point, we decided that this is too good to hold only for ourselves.
Thus, AutoIterative was born, where we also significantly improved the parts
that weren't polished well enough and added features we lacked.

