
An interview code submission that wasn’t even submitted changed our process - rurp
https://stackoverflow.blog/2020/06/08/how-an-interview-code-submission-that-wasnt-even-submitted-changed-our-process/?cb=1
======
nsainsbury
I've been long frustrated about how technical interviewing takes place in our
industry (and I've written about it quite a bit as well eg.
[https://www.neilwithdata.com/developer-
hiring](https://www.neilwithdata.com/developer-hiring))

I think many companies through the hiring process completely lose sight of
what they are actually looking for. They forget that the barriers they erected
(whether they be whiteboard problems, take-home coding tests, algorithmic
dance on your head textbook problems, etc.) are simply signals about the
actual person and their capabilities...and usually, they're _exceedingly poor
signals_. That's why you end up with situations where extremely accomplished
and talented developers don't pass many technical interviews at companies
where they would have otherwise gone on to be outstanding employees.

And it keeps happening, and happening, and happening.

Interviewing for a developer role should be far, far, far more holistic than
it is today - rather than throwing away my entire history of accomplishments
and creations and just assessing me on the spot in a 2hr winner-takes-all
high-stakes game of whiteboard/technical trivia.

For example:

* If I have a strong GitHub portfolio of projects I can prove I worked on, that should 100% take priority as a signal as to my capability and how I think about committing regularly, writing clear commit messages, etc.

* If I've built products I can prove I alone built and I can walk you through my code, that should 100% take priority as a signal as to how I write code, my proficiency with a particular language, etc.

* If I communicate clearly over email, have a blog with my writing demonstrating my ability to clearly communicate technical topics, that should 100% take priority as a signal as to how well I communicate.

etc, etc.

Sadly, today, I'd say ~90% of technical interviews completely and utterly
ignore all the above and want you to do the technical monkey dance...because
clearly, what makes a developer great is grinding leetcode for 3 months and
then pretending you haven't seen the problems before during the interview.

~~~
vegetablepotpie
So here’s a counter perspective: there is no good way to interview, there are
just less bad ways, which depends on your company.

The worst filter is choosing at random. If I shuffle a stack of resumes and
throw half in the trash, I have eliminated the unlucky candidates. I have
certainly rejected a good number of skilled and highly qualified candidates.
Regardless the filter did its job, I have fewer applications to review.

If I give candidates whiteboard problems, I filtered out thoughtful people who
don’t perform well under pressure. If I look at interviewees github submission
and blog posts I have filtered out intelligent people with a dearth of free
time. If I combine the two filters with an OR relationship, I now let more
people through and have a filter that is less effective at narrowing down
candidates.

All filters filter out good candidates. Anyone who finds a way to find exactly
the right candidates from a filter in a way that isn’t bespoke and is scalable
is going to be very successful.

~~~
TedDoesntTalk
It's amazing to me that, in all the discussions and articles on HN that I've
read about interviewing, no one ever mentions coupling their favorite filters
with gut instinct.

Not everything has to be measurable to make good decisions.

~~~
toolz
but everything has to be measured to quantify if the decision was good or not.

You trust your gut when you have no other option, not because you believe it
to be better than a data driven approach

~~~
TedDoesntTalk
> but everything has to be measured to quantify if the decision was good or
> not.

Do you measure your romantic relationships or marriage or family interactions?
Do you measure any human relationship?Because hiring and working with someone
with fundamentally a relationship, not a data science or math problem.

I had a manager once who said, "if it can't be measured, it can't be managed."
You sound like him. Good luck with that approach, and i hope we don't work
together :)

~~~
toolz
You just measured our relationship based on a single comment. So yes, I along
with everyone else measures relationships based on data.

------
andrewstuart
Coding tests should be abolished.

There's almost never any science or systematic approach to evaluation.

How can you possibly evaluate a test without predefined criteria for
evaluating that makes the result good and what makes it bad?

Whether or not the code is "good" is simply a matter of opinion in almost all
cases.

Another down side to coding tests is that if the assessor knows less than you
about some area of coding and sees something they don't recognise or
understand, then they might well negatively view what in fact is a much better
way of doing things.

And, much worse than anything else, you have a very tangible chance of
spending 12 hours doing it and hearing nothing back at all.

And as for "Tic Tac Toe" as ANY sort of effective test topic, well, that's
where you should pull out and find a different job to apply for, where they
can at least formulate a _relevant_ test topic and come up with tangible and
defined criteria for measurement as well as a commitment from their end as to
who will assess it, against what criteria and within what time frame and what
feedback they will give you, if any. Ditch the Tic Tac Toe companies.

I did two coding tests in recent years ... in one, their feedback was "they
didn't like it", and the other one I worked on for 12 hours because I believe
in doing a good job and meeting the requirements, and I heard nothing at all
back - not a single word.

Coding tests are, for the most part, bullshit.

~~~
coffee
> you have a very tangible chance of spending 12 hours doing it and hearing
> nothing back at all

...which is so very frustrating. It's painful to read things like this:

> That was all we asked; we intentionally left it open-ended. Some people
> tried to impress us with huge, elaborate apps that used different services
> and engines.

The people hiring viewed this as a trivial, small, meaningless ask. They are
proud to have "intentionally left it open-ended."

Some potential candidates did not (through their own example) view this as
trivial, they went ahead and poured a ton of time into it and most likely were
"replied with well wishes" as the company moved on.

It's irresponsible.

~~~
9nGQluzmnq3M
Yes, companies need to be up front about roughly how much time they expect
candidates to spend.

That said, if a candidate spends 12 hours or 10,000 lines coding up tic-tac-
toe, the company is not entirely to blame here...

~~~
coffee
> the company is not entirely to blame here...

I clearly hear what you're saying, and I understand your stance on it. But I
can't agree with it.

The burden is on the folks hiring in my opinion.

This is not a "real life" scenario. It should be a SHORT assesment (for both
parties). If you were employed within a company as an engineer and you
received a nebulus spec (or no spec at all), the burden is then on you to
identify, educate, and communicate.

Not during a pre-interview (for the chance and maybe being blessed enough to
get a full interview with this world changing company).

~~~
9nGQluzmnq3M
Your line of argumentation seems to argue the opposite: since it's the
candidate who's the prospective engineer, wouldn't that imply that it's
_their_ job to clarify the nebulous spec?

FWIW, many of the FAANGs are famous for asking intentionally underspecified
questions, and the candidate preparing properly by figuring out what's in
scope and what's not is part of the scoring. But at least in an interview
you're timeboxed to 45 or 60 minutes!

~~~
throwaway298477
> wouldn't that imply that it's their job to clarify the nebulous spec?

Maybe, except when you try to clarify and their answer is that it's open-ended
-- and yet they want something super specific in the end. And the super
specific things are just one of many tech opinions and not objectively good
design.

> FWIW, many of the FAANGs are famous for asking intentionally underspecified
> questions, and the candidate preparing properly by figuring out what's in
> scope and what's not is part of the scoring.

Why is this a good thing though? Why is solving riddles in a professional
interview somehow ok?

------
P-ala-din
I don't understand why people hate to be tested objectively.

\- The task was to implement a basic tic tac toe AI (with open book !!!)

the state space is so small that anything would work fast enough in a modern
computer.

\- Some candidates somehow manage to build a program that loses?? that is,
it's buggy and they failed to test it.

\- The interviewer uses subjective criteria that somehow results in broken
code being accepted unanimously.

\- Some people overengineered their solutions and this is called impressive.

\- Someone failed to implement the exercise, wrote an answer that can be
googled in a couple of seconds. Made an irrelevant comment about "min-max" vs
"negmax" ( performance is not a concern (small state space) and negmax's main
advantage is being DRY).

Made a comment about "test bloat" despite empirical evidence from the
submissions showing that there was under testing.

and the conclusion that I am supposed to have is that interviewing without
code is better? a worth-mentioning portion of the candidates couldn't ship a
working implementation of a standard algorithm and the conclusion is less
code??

To be honest tic tac toe is a bad task to choose. it's trivial, easily
googlable, and has little room for skill expression. It's also doesn't test
the candidates' ability to choose the correct algorithm for the task. and it
fails to probe daily aspects of dev work ( concurrency, networking, databases
..) that traditional onsite interviews are less able to test.

~~~
throwaway298477
Because it's not objective?

Everyone seems to have very different opinions of what good or bad code looks
like, what's overengineered and what isn't.

Why is the problem even asking for AI? are they applying for an AI position?

And why is it ok to ask people to work for free on a coding project? From what
I've seen, people generally ask for pretty high rates to do consulting, with
good reason.

------
hysan
Hiring in our industry can learn a lot from education. Everything the author
wrote boils down to fundamental questions that teachers at all levels have to
deal with on a daily basis - how do I assess this student? Either in the
moment, on a test, through their assignments, etc. Teachers are constantly in
a struggle to figure out where a student is and if they are making progress
towards what they wish to impart to them.

Technical interviews are very similar, only smaller scoped. The goal is to use
the right tests to learn what you need to know about a candidate. A lot of
this boils down to having a rubric - what qualities are you looking for in a
candidate that makes them a good fit for your team? If you cannot answer this,
then your interview process is going to produce poor signals.

This also leads into another pet peeve of mine when dealing with technical
interviews - the ghosting and lack of feedback. If you are unable to give
generic feedback on why a technical assessment did not pass (not the
cultural), that is a strong signal that you don’t know what you are looking
for as a baseline in candidates. There is nothing wrong with generic feedback
along the lines of “relative to other candidates, your commit messages and
code style was lacking.” It is especially frustrating when the company invites
you to apply again in the future. That’s like failing a project in school, but
the teacher is giving you a second chance with the only feedback being,
“better luck next time.”

------
gwbas1c
> There are now many avenues to see how people develop that don’t require them
> spending a whole night coding for just a chance at an interview.

About two months ago I walked away from a pre-interview coding challenge that
looked like it was going to take 8-12 hours. The problem was too many
requirements.

The same job was posted in last week's "Who's hiring" thread. In this economy,
if you can't hire, the problem isn't the candidates. It's you!

~~~
sassyook
Sounds like Datadog's interview process.

~~~
gwbas1c
I'd say it was a case of poor empathy. I gave feedback to the hiring manager
but he didn't budge.

If I was working with a recruiter I would have been a lot more blunt.

Edit: if I see the same job posting in another "Who's hiring" I might reach
out again... If I'm still looking for a job!

------
vmception
This entire post is why I quit the interview circuit as a person with ample
prior relevant work experience.

This gaslighting bullshit has to go. People are given vague and contradictory
guidelines for the chance at an interview.

"Well we really like the UI and it passed all unit tests and didn't crash and
wouldn't crash and follows typical MVC practices, but we didn't like the
system design, and for this particular position we score heavily on system
design even though the requirements said not to prematurely optimize and not
to spend more than 4 hours on it"

 _But I thought it was scored by a double blind committee so what exactly are
other candidates doing from scratch in 4 hours--- oh..... they 're just like
me but recycling code from other similar interviews two months ago and adding
to it until they get a $500k compensation package_

This is still happening.

~~~
coffee
> This entire post is why I quit the interview circuit as a person with ample
> prior relevant work experience.

It is really bad. Removing yourself from it is probably a very healthy choice.

There's so much folklore, cult of personality, etc. behind all of this.

Hiring is REALLY hard. So exec's order a ramp up of head count. It falls on to
managers to start the process. They either don't want to do it (why would they
want to?), or they don't know how to do it...they are not technical, or
technical enough, they don't have "hiring" skills, etc...

So the burden is typically dumped onto the rank & file "senior engineers" to
do the dirty work. They don't know how to hire either. They don't like doing
things in a "manual" way. Easy solution! Give them a coding test!

~~~
mistrial9
> Easy solution! Give them a coding test!

(this is tangentially related to the above fine comment :) I believe it went
more like this.. The first time I saw this style of test, it was an
engineering hiring group from Microsoft, testing for advanced math skills for
some audio work in collaboration (?) with Apple. It was onsite at Apple (a
long time ago). The first thing the interviewer said is "we want you to solve
this problem right now" .. I said, I have a lot of code examples ready that
are representative of my best work, and he was pushy and slightly nervous, and
said "no we do not want to see that, this is the problem" .. I agreed, and I
believe I did solve it awkwardly, but they refused to look at anything except
the in-person test for that interview. It really surprised me, as at that
time, I had never heard of this way of doing things. There was no whiteboard,
it was a desk.

Sometime later, I believe Google famously used this testing method, on people
from The Five university programs, of course. Google probably spun it more
like a grad school situation, but I do not know that. Later, every EXEC wanted
to copy Google, or wanted to learn bullying like Microsoft.

It is so obvious to me that this sort of test is partially a command-and-
control exercise, giving the control role to the hiring group. Please recall
there was/is a real tug-of-war between excellent engineers and companies at
various points in the recent past.

~~~
coffee
You pulled out one small statement and ran with it. The problem is it's out of
context with the rest of what I said. Also, there is far more history than
what you just outlined which falls into "folklore" and "cult of personality."

You're statements alone have great truth to them, I'm just not clear how it
differs from mine and why it's a rebuttal to them. Oh-well :-)

~~~
coffee
This reply makes far less sense now that mistrial9 edited/updated their
original statement without attributing that fact :-\ It's been toned down for
sure.

------
siscia
Slightly off topic.

What is this deal about commit small and often?

I usually work on problems that requires a lot of thought, a lot of back and
forth between solutions, a lot of a reach this state where stuff kinda work
but it is not what I need yet and I am not sure it is gonna be in the final
version.

Eventually I reach the final version and I commit all together, but the commit
is rather big.

Do you guys come back and fix everything after? Like re-code the solution from
scratch committing at the right moment. Do you just add pieces related from
the final version in multiple small commits? And how do you make sure that
each commit is correct? Do you re-run the test suite after each commit? While
developing?

I must say that in smaller and simpler codebase than the one I usually work
with it might be possible. But if you work in complex stuff that have a test
suite that take hours, the approach of commit small and fast seems wrong.

~~~
l0b0
TDD makes small and frequent commits the natural way to work: figure out the
smallest non-trivial step in the right direction, write a single test, verify
that it (not the entire test suite) fails _for the right reason,_ implement
the simplest code which makes the test pass, simplify the implementation while
making sure the test passes, commit. This way each code change typically
amounts to a single new path through the code which is known to be tested.

Asking people to use TDD for a coding test is probably a bit much since it
takes a long time to learn the ins and outs, but small commits give a little
bit of the advantage and can tell you a lot: Does the candidate know how to
break the problem into _atomic_ changes? Do they commit only _reachable_ code?
Do they create simple, fast, and _orthogonal_ tests?

~~~
axaxs
This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can
make any awful code pass any test I want.

~~~
mjfisher
I can go one better, and make any program at all compile by removing code with
the annoying wiggly red lines under it.

The tools and options we have don't exist in a vacuum; you still need good
judgement and practice to make the most of them.

~~~
axaxs
It's funny you say that. Not long ago, one fresh dev was tasked with linting
old code. Their first pass was to delete everything that the linter complained
about. Hey, I guess they solved the problem!

------
p1necone
Not directly related to TFA, but directed at people doing stuff like this in
general: you _cannot_ say things like "don't spend more than a few hours on
this" or "don't worry about it too much" seriously.

People are competing for a job with these, potentially a big career step. A
_lot_ will spend _every waking hour_ between receiving the task and the
deadline working on it, because that makes sense when you're fighting for a
job alongside a bunch of other people.

Anyone who actually follows the "don't spend more than a few hours on this"
instruction is going to be at a huge disadvantage to the other people that
almost certainly will ignore it, so as much as you try to make sure to reduce
the pressure, you can't.

~~~
atomicity
It's really in the best interest of the interviewer to set hard time limits.
If you want your developers to work reasonable hours and be productive, you
better hope that they can get shit done in a reasonable amount of time.

A start would be to time-box your interviews. Then maybe time out your own day
and realize that spending 4 hours on an interview means that you miss dinner,
sleep, your workout, and/or social time. I wouldn't want to force a future
coworker through that mess.

So, now you've got to limit your interview to a couple of hours. Luckily,
since 80% of industry is satisfied with trivia questions, you don't really
need to try that hard to design an interview that helps you find better
candidates than your competitors.

------
coffee
This is so painful to read...

> That was all we asked; we intentionally left it open-ended.

> I let them know there was no time limit or minimum for how many hours they
> had to work on it

> But then over the next three paragraphs, they explained what they would have
> done.

> Normally, I would have replied with well wishes on their challenges

> When I came back, I had three replies in the email chain that just said,
> “Ship it.”

> Why did this work well yet was a big deviation from what we had planned?

> How did we get such a strong impression of them with very little code?

> Do we even need code? How much code? Let’s try less. Let’s try none! Do we
> just skip to the phone screen and talk about how they would start?

> Since then, I have moved away from coding tests altogether.

> ..that don’t require them spending a whole night coding for just a chance at
> an interview.

~~~
kbenson
> This is so painful to read...

What's the painful part? That it could have been much more terse but you ended
up having to read the whole thing?

If so, I kind of find your comment "painful" (not the words I would use if you
hadn't) in a similar way at a high level, if for different low-level reasons.
You provided very little information on what your found objectionable, and
simply quoted select sentences from the the article.

I think the fact I'm not even sure I'm correctly interpreting your comment
explains the problem with that.

I'm not sure the article is too long, maybe it is, but I definitely think your
comment is lacking enough information to convey your point accurately.

~~~
coffee
Wow.

This response (and how you responded to it) really illustrates, to me, the
problem with hiring in the first place when placing those hiring choices in
the hands of engineers that don't have hiring skills.

> What's the painful part?

The parts that I outlined.

> That it could have been much more terse but you ended up having to read the
> whole thing?

Nope.

> I'm not even sure I'm correctly interpreting your comment

Yup.

> but I definitely think your comment is lacking enough information to convey
> your point accurately

Right, so if it was an issue for YOU, one good choice in the future would be
to engage me in a discussion. Ask a simple follow up question.

"Hey, I didn't understand your comment, what did you mean by that? I'm
interested in finding out more..."

This illustrates the state of hiring in our industry. Snap, terse,
misunderstandings without exploring the idea that maybe the burden is on you
to get some clairity if YOU don't understand something.

"Hey, I didn't understand those lines of code, what did you indend to with
that? I'm interested in finding out more..."

Typically it falls inline with that the author of this article posted, he
passes out an "open-ended" coding task as a pre-interview, get's something
back, most likely "replied with well wishes" and moved on. They didn't have
the time, desire, skillsets, etc... to identify and engage.

~~~
kbenson
> Right, so if it was an issue for YOU, one good choice in the future would be
> to engage me in a discussion. Ask a simple follow up question.

"What's the painful part?" was the first thing I wrote.

> This illustrates the state of hiring in our industry. Snap, terse,
> misunderstandings without exploring the idea that maybe the burden is on you
> to get some clairity if YOU don't understand something.

I explained that I had a hard time understanding what your point was, I
explained that it was because of your lack of explanation (you could even say
it was terse, which is why I'm surprised you level that accusation at me), and
I asked you to clarify.

Perhaps you're offended that I said I found it painful? I made sure to note I
was only using that phrasing because you did. My purpose in doing so was to
note that it's not a very constructive way to criticize. If you did find
yourself ion any way offended by that, please consider how you originally
presented your position, and whether that was a constructive way to do so.

> This illustrates the state of hiring in our industry.

This exchange? Maybe it does! I did everything you criticize me for here, yet
you somehow failed to see it. I think perhaps there is a lesson here
somewhere.

~~~
kbenson
I'm going to go out of my way to apologize, as my original reply to you was
probably a bit snarkier than called for. At the time, I thought it warranted,
because my misinterpretation of your comment (of what I thought the most
likely meaning of it was, that is) lead me to view it as fairly snarky itself,
when it doesn't appear that accurate, and I intended to lightly reflect that
in a way I hoped would illuminate what I saw as the problem with that
approach. Obviously, that doesn't make much sense if that wasn't what you were
doing.

That said, I do think some of my criticisms hold weight. That is, that there
wasn't enough actual content from you in your message to easily discern what
you were trying to accomplish. I don't think I was the only one in that
position. I _did_ attempt to ask you what you meant, and that was genuine, I
just also included my reply for what I thought he most likely purpose, which
turned out to be incorrect. I'm not sure if you took that as sarcasm, or as a
method to bait you, but it wasn't.

Here's to hoping we both come away from this slightly better than we entered,
and with little or no resentment. :)

~~~
coffee
> Here's to hoping we both come away from this slightly better than we entered

That's very funny to me :-)

> my original reply to you was probably a bit snarkier than called for

> At the time, I thought it warranted

> my misinterpretation of your comment

> what I thought the most likely meaning of it was

> and I intended to lightly reflect that in a way I hoped would illuminate
> what I saw as the problem with that approach

Wow.

I quoted a few sentences that were painful to me, and out of that came all of
this?

A snarky reply, that you felt was warranted, followed up by you trying to
educate (illuminate) me on why you saw it as a problem.

Throwing in some "social proof" for why all of that was okay:

> I don't think I was the only one in that position

Along with justifying most of your approach:

> That said, I do think some of my criticisms hold weight. > there wasn't
> enough actual content from you > to easily discern what you were trying to
> accomplish

Emphasizing how big of a person you truly are by putting in extra effort:

> I'm going to go out of my way to apologize

~~~
kbenson
> Throwing in some "social proof" for why all of that was okay:

More just to explain what led to it, but you can interpret it how you like.

> Emphasizing how big of a person you truly are by putting in extra effort:

Actually, just trying to live up to the standard I set for myself, but don't
always achieve. I chose an idiom that might have implied something I didn't
intend. By "going out of my way" I was really just referring to how I was
replying to myself, and not waiting for your reply to me, so try to short
circuit that wait, and express my feelings even if you chose not to reply but
still felt negatively about the exchange.

It is possible to apologize for _how_ you did something, but not for _why_.
This isn't some attempt and stealing a "win" in an argument through meta-
analysis, it was just me deciding I had been uncharitable, and deciding to do
something about it.

I'm sorry it sounds like you couldn't accept this in the spirit it was meant.
It's probably not productive for us to continue further on this topic. I hope
you have a good night.

------
throwaway298477
I don't want to sound cynical, but is the interview process likely to change
any time soon?

Looking at the HN history, it's been a better part of a decade, if not longer,
since people have been complaining about the hiring process.

It doesn't seem like much has changed except that it's worse, in the sense
that you're usually asked to spend several hours on a coding project for
screening AND have a subsequent whiteboard/leetcode interview or 10.

When you take into account all of the 'signals' that you're supposed to
provide to even get a job, let alone be successful, maybe this isn't a good
profession to be in anymore? Example:

\- Several hours - several days coding projects. Some are screening tests.

\- Having to practice leetcode continuously in order to keep it fresh in your
head, because you never use it in actual work.

\- Robust open source portfolio is highly encouraged, in some places required.

\- Constantly keeping up with new libraries, frameworks and languages. It's
unusual to get to learn these on the job, usually you have to do this on your
own time.

Let's face it:

When you take into account all of that extra time, it seems like Software
Engineers are not being paid very well.

Especially if you value your leisure time.

Why is it like this? Maybe it's just too competitive, too many Software
Engineers applying for too few positions. Whatever the reason, it doesn't
sound at all what it used to be, and maybe it's time to get out.

~~~
quietbritishjim
Maybe there are some places that require everything you've listed (open source
repos, take-home project, whiteboard coding). But I think many, or maybe most,
only require one of them.

At the end of the day, I'm sure we've all met someone that justifies requiring
sight of _some_ sort of code of the candidate before hiring them. But
different people will find different types of coding test better or worse ("I
don't want to spend loads of my free time on a take-home project" vs "I can't
code under pressure in front of a white board even though I'm great at coding
in general"). So Hacker News will always be filled with endless debate
trashing all forms of assessment with no agreement on what to use instead.

~~~
throwaway298477
That definitely has not been my experience at all.

My experience is that _almost every_ place I've interviewed requires both a
coding project and at least one whiteboard interview, with open-source as a
huge plus in your favor.

Maybe it's not an either-or thing and just requires a little bit more
consideration of how it's affecting the industry as a whole.

\- If someone has stellar experience on what's desired, they shouldn't have to
jump through the other hoops.

\- If they have a strong open source portfolio that reflects exactly what's
desired, they shouldn't need the other hoops.

\- If there's a whiteboard interview, don't ask about anagrams or anything
that an experience dev wouldn't already be using in their day-to-day. Ask
something relevant, like their understanding of databases, networking, etc if
they are going to be Senior Backend dev. Ask about something a strong,
experience dev actually knows that a junior doesn't. If you suspect possible
gaming, then go deeper into the questions to filter out bs.

\- If there's a coding exercise, keep it timed to a max of 1 hour if it's a
screening test, up to 3 hours if it's a final interview. Have the project
already set up for them so they're spending time on the problem and not on
config. Clarify exactly what you're looking for in the results.

It's basic common sense.

I've heard on other threads a lot about being 'too old' to code. This doesn't
happen in other engineering disciplines, where age is highly valued because of
the experience it brings.

I'm suspecting this kind of hazing ritual to be screening out very good older
devs that have a lot to bring to the table, but don't have the time to do all
this extra stuff because they have a family.

------
scarface74
My interviews have been some combination of:

1\. Techno trivia on whatever stack the company was interested in.

2\. Database modeling and queries.

3\. Questions about past projects and the choices I made.

4\. Whiteboard design questions (no coding)

5\. Here is a skeletal project - do these 5 or six simple programming tasks.
Use google if necessary.

6\. Process, design and soft skill questions.

I have changed jobs 8 times in 24 years.

Since all of my experience is in the enterprise development/architecture
space, I figured my best bet into getting into $BigTech without spending time
“learning leetCode” was through their cloud consulting division. I tried my
luck at AWS and I got in - no algorithms, not much techno trivia, just a lot
of explaining past projects and soft skills questions on “Leadership
Principles”. Also - fully remote with travel post-Covid.

------
tsegratis
An advantage of coding interviews: some people just can't help themselves...

To never lose at TicTacToe is not possible. If you're trying to never lose,
you don't want minimax, you want a brute force of the search space

Seems like space is 2^9, but actually a few if statements is enough. You said
I must never lose?? Okay I take the center (corner has same outcome, but
center simplifies)

You now have 2 choices: corner, or side. Internally I will rotate the board so
your choice was square 0 or 1

    
    
       012
       3x5
       678
    

If you chose square 1, I just need 2 if statements

    
    
       play(0)
       if(yourplay()!=8) return play(8)
       play(3)
       if(yourplay()!=5) return play(5)
       return play(6)
    

If you chose square 0, ... it is left as an exercise for the examiner

~~~
graton

      To never lose at TicTacToe is not possible
    

Sorry I don't understand that. Normal playing at decent skill level is going
to always lead to a draw, which is not losing.

Am I missing something?

~~~
tsegratis
I was counting failure to win as loss. Your take is correct and better

My main other point :/ :) is a full -never-loosing- AI takes 6 if statements,
and minimax is technically wrong for that goal

------
pkukkapalli
I have thought about this quite a bit recently as well. I think the main thing
to look for in interviews is "does this person have a clear and sound thought
process?" In theory, the whiteboard questions are meant to suss this out, but
the prevalence of Leetcode and other interview prep websites blurs the signal.

I wonder if just asking for a one or two page design doc on something would be
a much better signal, since that's probably what you'll need to do on the job
anyways.

~~~
atomicity
I've seen a lot of engineers that rely on their intuition and end up just
creating shit that works and is surprisingly maintainable. I've also seen a
lot of different ideas on what a "clear and sound thought process" is.

In fact, someone who is clear and sound in writing might get bogged down when
writing code. Good writers are (obviously) not necessarily good coders.

I do think there is potential around the design doc. Design is a big part of a
lot of roles. In addition, in a lot of these roles, having the "best" design
isn't better than having a design that the rest of the team can understand.
Still, I wouldn't do it for the purpose of identifying good "thinking". I
would do it because I expect the people I hire to be good (or have potential)
at what they will be expected to do.

------
nerder92
What we seem to forget is that the hiring process is actually to hire people
not to reject them.

Companies should remind themselves to help out the candidate, give them prep
material, and create a safe and relaxed space if they want to see really how a
person will perform in their daily job. I think that a lot of this is driven
by big company ego where a high rejection rate implies a higher reputation
because of course: "we only hire the best, that's why so many didn't make it"
this is a total bias IMO, a sane metrics for a smooth interview process should
not be based on the result of the interview solely. You should ask your self
how diverse are the profile that you are able to attract, how long did they
stay and how good their annual/performance review goes after 1 year, what's
the feedback of their coworker and leads after 3/6 months. Getting feedback
out of this and tune the interview process interactively and in a data-driven
fashion, because this is what it is, a process that can and should be
improved, not a sort of fetish medal to show people and (falsely) say: "Hey
look how cool I am, I hire only `the best`"

------
bambax
> _if the app made sense and the code was readable_ , even if in a very
> different style _than what we were used to, we would be up to talking more
> and asking the applicant about it_

Not sure what "style" means here, but this seems strange. Why does the author
need to say this / why should style matter?

It sounds like the habit of the candidate about the position of braces had an
influence on their hiring process, and after giving it some thought, they
decided against it. This is the lowest signal one could possibly imagine.

~~~
atomicity
Did you misread? The author wants readable code and accepts "style"
differences.

------
xtiansimon
> "Why did this work well yet was a big deviation from what we had planned?"

Huh? Maybe because you only had one person to review who deviated from the
norm?! StackExchange changed the way tech forums were ran by forcing
everything into the Q&A format. It focuses people and prevents a lot of back
and forth to understand the what the OP is asking.

Spec work sucks as a requirement in an interview SUCKs, but at least you can
run it.

------
coffee
Some of the best people I've had the honor of hiring, and some of the best
jobs I've had the privilege to be offered, never once involved opening a code
editor, sharing a screen, reviewing any code, completing a take home project,
or being challenged with a brain teaser.

Why is that?

------
Forge36
>in the end, whether in hiring, coaching, or giving recognition, connecting
with people is the goal for a manager.

Go with your gut? Did I miss the part where the lesson learn was named? Learn
what you're looking for first?

~~~
coffee
My takeaway was the author learned how to better interview, by not giving code
tests, but instead to begin engaging in a discussion with someone.

------
p1esk
_their submission was incomplete. But then over the next three paragraphs,
they explained what they would have done._

I would not hire this candidate for an IC role based on this submission. The
main quality I'm looking for in an engineer is "gets things done". If this was
a manager role, then sure. A manager could describe what they would have done
or (preferably) what they did in a similar situation.

They were given two (!) weeks to complete a simple task. I saw no excuse for
not delivering.

~~~
coffee
> They were given two (!) weeks to complete a simple task. I saw no excuse for
> not delivering.

So you're saying that in your worldview, it is 100% acceptable for a pre-
interview candidate to spend a full 2 weeks (or even a significant portion of
that) coding something, for free, at the off chance they'll maybe get an
actual interview?

~~~
p1esk
Yes.

If I want a job badly enough, I'm willing to spend 2 years preparing for a
chance to have an interview there. For example, if I wanted to work at a top
AI lab (like DeepMind, FAIR, or OpenAI), I'd better start working on a paper
that gets accepted at NeurIPS, or a research project that puts me on their
radar.

If that's not 100% acceptable in your worldview, then perhaps you're not who
they're looking for.

~~~
coffee
This is reaching far beyond the context of the article, and the comments
replying to it with this example.

