
The technical interview is an ego trip - kowsheek
https://blog.kowsheek.com/the-technical-interview-is-an-ego-trip/
======
TheCapn
This was my take on interviewing with Amazon at one point a long while ago.

The initial interview itself was pretty straight forward, but it seemed like
every answer I gave was "wrong" because the interviewer was looking for key
phrases instead of understanding of the concepts. We talked about hashing, and
when he asked if I knew what hashing was I said sure, its a one-way function
to create a unique identifier. He asked me to elaborate, so I sorta... talked
more? I remember feeling confused because I'm not sure what else he wanted me
to say. Eventually he ended the question, said he was looking for me to say
hashing is for "fingerprinting"

We moved on, he asked me for an example of a hash function. I said md5 or sha.
He pressed further, asked about collisions and eventually cut off the line of
questioning telling me he was looking for an example like the modulus
function. Questioning lead further to reaching into linked-lists and the like.

Having never sat through this kind of interview I was left with a really salty
taste for the process. If any they were looking for was me to rattle off some
pre-determined key words then what good is the interview for? I incorrectly
assumed he was gauging my familiarity with the subject rather than repeating
my 2nd year university coarse which introduced shit like data structures and
algorithms.

His smugness in the way he concluded each topic was just a giant turn off of
ever seeking further work with companies like Amazon (giant & highly
competitive software conglomerates). I feel like everyone is trying to one up
or appear to be king shit in some way, it left a bad taste. (For the record, I
did a couple interviews of this style before totally writing the experience
off. Others were better, but this experience always stuck with me)

~~~
umvi
I don't take crap like this from interviewers.

One time an interviewer asked me "how would you go about counting the ridges
of a US quarter?"

I rattled off some ideas about counting the ridges in an arc and then
multiplying to get total ridges but the interviewer kept prodding and
eventually ended the question and said he was looking for me to say "google
it" (I didn't realize it was a known, fixed number).

I just rolled my eyes and laughed and said "Huh, good one, but how would _you_
go about counting the ridges of a foreign coin assuming it's freshly minted
and the number of ridges is unknown?" The interviewer shifted uncomfortably
and just said "yeah, I'd probably do something like what you said - count the
ridges in an arc and multiply..."

(i.e. "if you are going to give me bogus lateral thinking puzzles to test my
competence I'm going to fire them back to see how you handle them")

~~~
Impossible
It's funny that his expected answer was "Google it". In most cases when people
answer with that (it could be the answer for any tech interview question...)
you get encouraged to actually do the problem, so it's a time waster. For the
interviewer it gives them no signal outside of you having the ability and
awareness of the existence of search engines, although there could be some
vague behavioral signal that shows you have a stronger urge to find existing
solutions rather than waste time creating your own. This is a really toxic
interview because you're basically expected to read the interviewer's mind.
I've had a couple of these with peak Silicon Valley companies. At pre-IPO
Zynga I was asked by a GM "what the most important number in game design is",
at River Studios (Mike Rothenberg's company...) the entire interview was
basically this style of question.

~~~
hashkb
False. We want you to be confident and admit you Google all day every day.
Simple as that. You seriously would have done all that before Googling it?

~~~
elmersglue
People assume interviews are to prove technical competence. Answering with
“Google it” is more of a test of someone’s humour. While in practice it might
be true that you’d Google it, most people have been conditioned by the
education system to answer with something more substantive and demonstrative
of their technical thinking ability.

~~~
hashkb
I'm not responsible for your conditioning. I want you to tell me the truth. If
you're playing a game in your mind that causes you to give me a more complex
answer than you need because you think that's what I want to hear, you're
going to have similar pathology as an employee and IMO this is a great screen
for exactly that!

Edit: doing any "technical" work prior to doing research is a display of
technical INcompetence.

------
roflc0ptic
Man. I interviewed somewhere last week for a Scala position, advertising
myself as a functional programmer.

In the interview, they asked me, "What's the difference between fold left and
fold right?" I said "Um, one of them starts on the left side of the data
structure, one of them starts on the right. I never remember which is which."
They said essentially: "okay. The answer I was looking for was that fold right
is not stack safe." I protested weakly, and they dug in, so I graciously let
it go.

But it's patently not true. A naive implementation of fold right in Scala
isn't stack safe, but the actual implementation is stack safe. It's been stack
safe since like 2010. So rather than interrogating my knowledge of functional
programming, they're just asking me bullshit language trivia, and dinging me
when I don't come up with their arbitrary wrong answer.

I wanted to work there before that, but the interview made me a little
ambivalent, and then they just ghosted me. So I guess I dodged a bullet. But
man, that was frustrating.

~~~
nogabebop23
you can often give a company a pass for a shitty interview, but you should
name & out them for ghosting you as that is a far more systemic problem
indicator. When I'm interviewing I want the poeple we don't hire to go away
and have good things to say about us because they will tell many people about
their experience. Companies that are disrespectful and inconsiderate to the
point of just cutting off contact should pay the price.

~~~
roflc0ptic
Yeah, I'm ambivalent about that. From a purely theoretical standpoint, sure,
bad actors should be punished. There's also slim but non-zero chance that
they'll reciprocate and attempt to harm my reputation, and we'd end up in some
dumb internecine conflict. It's good for bad actors to be punished, but
usually irrational to be the one doing the punishing.

~~~
wolco
Can you come back in a year and share?

------
jaaron
I agree. We recently got rid of our more traditional "tech screen" and
replaced it with a 90 minute realistic programming interview.

We have 3 tests we give depending on the role (game dev, backend, or SRE). The
tests replicate typical work the engineer would be doing, such as adding
functionality to a 2D game, developing out a web service for a given API, or
debugging and optimizing a linux server. We provide a development environment
remotely, or the engineer can use their own. They code/work on their own,
without needing to share their screen, though we're on the line if they have
questions or just want to chat. The interview itself takes about an hour and
we schedule in buffer time before/after to setup and to debrief.

We've designed the problems to be (a) relative, (b) scalable and (c) fun. By
scalable, I mean that the problem should have a simple, naive solution that
most engineers who work in that space should be able to solve quickly and
easily, while also having enough space for more advanced engineers to extend
the problem and show off a bit.

So far we've gotten good feedback from this approach, even for candidates who
haven't passed. I know 90 minutes is a long time, we but feel that with this
test, we get a good, realistic work sample, and we can forgo a lot of the
other less effective interviews.

(plug: we're still hiring [1])

[1]
[https://www.singularity6.com/careers](https://www.singularity6.com/careers)

~~~
lazyant
"scalable" (not sure about that name) questions or scenarios are the best to
gauge competency. I do them although it's pretty hard to come up with good
ones.

A fallback for shorter question is to ask for a something with many possible
answers, as typically somebody more experienced will have many answers besides
the most popular ones. (server A can't ping server B, what can be the
reasons?)

~~~
jaaron
Yes, scalable problems are the best, but can be difficult to devise.

A lot of folks tend to go the "optimization" route, by having a problem with
multiple ways of extracting more performance, typically by better algorithms
or data structures. These are ok, but not great. Most candidates will
reasonably start with a simple naive solution that works and then try to
optimize, but time may not allow for that and the optimization may require
significant rewriting of the solution. So unless you either start out with the
optimized solution or you have a lot of time, you're unlikely to ever see
those solutions.

I tend to prefer scaling via scope.

For example, for our game engineering test, we start with a half-finished 2D
"game" (think something like pacman). We then have a list of functionality
that can be added with increasing difficulty. This allows us to measure
"seniority" by both (a) how far down the list they get and (b) the quality of
the individual solutions.

Another example is starting with a single threaded solution and then extending
into a multi-threaded or multi-process solution.

------
globular-toast
I had the strangest technical interview recently. I didn't get an offer, but
in every case where that's happened before it's been obvious to me where my
deficiencies lie (which I then use to improve in that area). This time I
learnt nothing.

It was six individual one-to-one interviews, back to back. The first five were
an ego trip for _me_. I was able to do everything perfectly it seems: read
code, write code, talk about code. Then the sixth was this synthetic problem
involving nested boxes. I figured out it was a tree problem and started
writing code to build the tree. I had an approach in mind and asked the
interviewer if he thought that was a good approach (given that there was only
enough time for one attempt). He said no, he didn't think it would work. That
completely threw me off. Later I realised me approach would have worked
anyway.

I didn't get an offer, but what in the ever-loving fuck was the point of
putting me through 5 technical interviews only to fail the sixth? It really
felt like they were looking for that ego boost but didn't get it from me. It's
hard not to sound arrogant in this situation, but I've been humbled in the
past. This time I was just confused.

~~~
sushisource
I'd say this happens semi consistently to me when I get rejected. I did a tech
screen (of which this is the first I've ever failed). I chose to do it in Rust
as that's my main language these days. I probably should've reconsidered that
decision as Rust is notoriously difficult when it comes to dealing with trees
and I spend most of my time managing pointers. I described a solution to the
tree problem quickly, implemented it, and then dealt with the compiler for
about 15 minutes. As a result I never fully finished the task, but it was
pretty darn clear I knew what I was doing.

Same thing, they came back and said no and I really have a hard time imagining
why other than the interviewer not being familiar with Rust - but - hey, don't
tell me it's fine to use then!

That to say, rejection feedback is almost always useless.

~~~
nilkn
This is why Python is my dedicated coding interview language. You could do
something far more impressive in C++ or Rust, but if you don't quite finish
the full implementation it's an automatic fail with some interviewers even if
you had to take into account many nuances that a Python solution wouldn't.

~~~
fancyfish
Agreed - I’ve learned that interviewers care more about getting the end result
in the time window than demonstrating lower-level skills.

Choose 1) The easiest high level language you can, and 2) the language used by
the interviewer/firm.

Think of it like trying to be as much like the interviewer himself/herself, in
both coding and communication.

~~~
jaaron
That's also because in addition to testing if you can solve the problem,
they're also testing your _judgement_.

It's an interview. Just like any other engineering problem: use the right
tool.

If you go off tangent and don't solve the problem, then that raises the
question: "Ok, the engineer seems to be able to code, but they didn't finish.
Will they finish other work? Will they regularly get caught up in
irrelevancies?"

------
WrtCdEvrydy
Of course it is, it's a way to gauge whether "someone is dedicated to the job
by cramming the algorithms section they haven't touched in years"

I've done dozens of interviews and after all of it, I realized there are only
four qualities we quantify as useful: caring, ability to listen, ability to
learn.

~~~
daggerdrone
Fourth quality: ability to count

~~~
asddubs
there are four kinds of people: people who can count, people who can't, and
pedants

------
davidhyde
> “Often, I will give them a scenario where the processes are failing the team
> to find what they would do to tackle inefficiencies and if they would be
> willing to speak up.“

While the intention here is good you are unlikely to get an accurate answer
from the candidate using this method because the candidate “should” tell you
what you want to hear rather than what they would do in reality. You basically
want to find out how the developer delivers criticism. Do they bruise egos or
are they tactful or do they simply stay silent.

A better approach is allowing a candidate to demonstrate how they offer
criticism. Give them a codebase to read and make sense of and ask them to
explain it to you. Ask them to to point out parts that could be better
designed. You can gather a lot of information this way. 1\. Can the candidate
read a foreign codebase and make sense of it. 2\. Can the candidate pick up
business logic from the code. 3\. Does the candidate offer criticism that is
likely to make another developer defensive or are they more guarded with their
communication and offer higher level design alternatives.

------
bosswipe
I'm coming to the realization that there's almost no point in spending time on
a lot of the things that I love about being a developer: learning new
languages, studying best practices for your tech stack, reading software
engineering books, becoming involved in tech communities, keeping up with the
latest trends. Interviewers don't value any of that beyond lip service. The
only thing worth spending time on is leetcode grinding, it can be worth 10s of
thousands of dollars.

The attitude of the algorithm geniuses is that software engineering is easy
and anyone can learn it, which might be true, but my point is that I already
did learn it and I spent five years becoming an expert in it. That should be
valuable to your business whether you look down upon it or not.

~~~
jakearmitage
Nail tests, get offer, ask for signup bonus, drop out 3 months later. Repeat.

~~~
chrstphrknwtn
Two or three cycles in, people hiring will see serial 3 month stints as a red
flag.

------
ng12
Articles like this always underestimate how many bullshit artists there are
out there. The technical interview is not perfect but it is still far more
meritocratic than many fields.

~~~
ian-g
If you want to test somebody's ability to think a problem and not just
bullshit 100%, why not ask them questions like "Given two integer variables x
and y, write a function to swap their values without using a third variable"?

It's a pretty small problem, but it's still one that needs some thought to
get. Also doesn't weed out people who don't know technical details of a red-
black binary tree (for example) without necessarily getting rid of people who
could quickly pick up what a red-black binary tree is.

~~~
c1ccccc1
Nice puzzle. Snarky python solution:

    
    
        x, y = y, x

Legit solution (I think):

    
    
        x = x + y
        y = x - y
        x = x - y

Actually, using bitwise xor would be even easier:

    
    
        x = x ^ y
        y = x ^ y
        x = x ^ y

~~~
a_e_k
Careful there with that "legit" solution! With extreme values, it can cause
overflows and other weird behavior.

For example, in Javascript with:

    
    
        x = 2
        y = 9007199254740991
    

then:

    
    
        x = x + y // 9007199254740992
        y = x - y // 1                  (!!!)
        x = x - y // 9007199254740991
    

Or in a somewhat more sane language like C, it'll usually work but may
technically invoke undefined behavior:

    
    
        % cat test.c
        #include <stdio.h>
        int main() {
            int x = 2;
            int y = 2147483647;
            x = x + y;
            y = x - y;
            x = x - y;
            printf( "%d %d\n", x, y );
        }
        % gcc -fsanitize=undefined -O0 -g -o test test.c && ./test
        test.c:5:7: runtime error: signed integer overflow: 2 + 2147483647 cannot be represented in type 'int'
        test.c:6:7: runtime error: signed integer overflow: -2147483647 - 2147483647 cannot be represented in type 'int'
        test.c:7:7: runtime error: signed integer overflow: -2147483647 - 2 cannot be represented in type 'int'
    

And even in Python you can end up with it silently turning your ints into
longs.

------
catchmeifyoucan
This is super true. I was interviewing with a Startup once, and we had an
initial screening, and they had a lot of work to be done with AWS, some APIs
and data pipelines. My area of work. When we had a "technical" interview, it
was completely algorithms focused. And the interviewer dropped a few anchors,
which restricted my thinking, and caught me cycling. It was super obvious the
call wasn't going great. Odd enough, they acknowledged, that I was one of
their best candidates, and were surprised. I didn't get the offer. It was a
job I knew I could've aced, but the questions they asked didn't match up to
what they actually needed done :/

~~~
mixmastamyk
Reminds me of an interview a friend got me at a Spring Boot shop. Make sure
you know SB, he said. I normally do Python, so I brushed up on Java and Spring
for a month beforehand and was impressed with my progress.

Well, final technical interview wasn't done by him and was instead 100% SQL
and database theory instead. I did decently, I got about 85% of the questions
right off the top of my head. Pretty decent result for zero preparation. Well,
guess what another SQL-head did better. Was a total disaster because I was
unemployed at the time and staring down financial ruin.

------
pmiller2
> My golden rule for technical interviews is that, "Every step, conversation
> and question must be pertinent to the day-to-day of the role." While this
> may be obvious, I am sure that many hiring managers are still expecting
> candidates to arrive at technical interviews with Computer Science books
> memorized. This form of technical interviews should be made obsolete.

Here's the core of the article right here. The "regurgitate LeetCode-style
problems" interview fails to be relevant to the day to day of pretty much any
SWE job (unless, maybe, you're applying to work for LeetCode, and one of the
duties is to create solutions to problems in under 40 minutes, without outside
resources).

Take the author's golden rule and layer on a structured interview process, and
_now_ you've got an interview process that will be more predictive of whether
a candidate is a good hire than any "throw a random engineer in a room with
the candidate and have them answer random algorithm problems" type interview.
Even better, since you have an actual process, you can tweak it to be even
_more_ predictive of a good hire.

Why don't companies understand this?

------
darth_avocado
Can we also add to the list of things that we don't need 8 interviews AND a
tech screen to figure out whether a person can code?

~~~
pmiller2
I don't think I've ever done more than 5 interviews plus a phone screen in a
single loop. Who tried to put you through 8 hours of on-site interviews?

~~~
sushshshsh
Not them but for my last job at a mid tier company i did 6 hours of onsite
total, and amazon/fb both were 4 hours each not including the screen(s)

------
paxys
Is it already that time of the week again?

~~~
aphextron
We should just have a template to fill out for these posts

~~~
jameshush
I'm smelling a great "Show HN: Using GPT-2 to create comments for a post about
tech interviews" submission :)

~~~
mhh__
Wouldn't really surprise me at all. 90% of everything is crap, HN submissions
are no different - the comments are the site.

------
allenu
I really like the interview process the author lays out here. As someone who
has been working for about 20 years in the industry, this feels like a better,
more direct gauge of how well someone will fit in the role than of seeing if
they know how to invert a binary tree. I do think it's still worth doing some
sort of coding question, but it doesn't have to be some intricate algorithmic
puzzle. It can be as simple as, "How would you design X?" for design and some
data structure algorithm question, but something that does not take up the
bulk of the interview. (Perhaps one interview in the loop could be devoted to
hands-on coding.)

One of the best interviews I had, and I'm biased here since i hit out of the
park, was one where the interviewer literally gave me a laptop and told me to
code a simple iOS app. I was applying as a senior iOS developer with many
years experience, so it was totally fair to ask it. Having written several
apps on the side, I got straight to work and knew exactly how to set up data
structures, algorithms, and trade-offs. Even with my experience, I was not
able to finish the complete app in the time allotted, but I was able to breeze
through all the elements of of what go into designing an app from scratch.

I had a few more interviews and later they offered me a job, but I ended up
working elsewhere. Interestingly, the place I did take a job at had more
traditional tech interviews, which I actually found too easy compared to
larger tech companies, however there was more long-term growth available there
and the pay was much better.

------
glangdale
Ego Trip is the right phrase. A lot of the traditional algorithms puzzler
interviews amount to the material being covered in an adversarial, closed-book
fashion for the interviewee, after the interviewer has themselves gotten to
master the material in a "at your leisure" fashion with an open book.

I wouldn't mind getting asked nasty questions about red-black trees or
Krushkal vs Prim or something if I knew the person sitting across from me had
taken a "pass this test under these same conditions or you're fired" type
scenario. It wouldn't make these interviews a _good_ idea, but it's the reek
of hypocrisy about them that puts it over the top for me.

I still contend these interviews - in any form - are a hazing exercise
designed to convince you that your own expertise doesn't really matter. You
may think of yourself as a accomplished professional developer but to BigCo
you are a Smart Person (?) Grade N to be slotted into an arbitrary role. What
better way to convey this message than put you through an interview that you
would have been best equipped to pass straight out of university or grad
school? I suspect my peak "pass the tech interview" would have been straight
out of the core courses mid-PhD and my ability to do this has since gone down
every year.

~~~
commandlinefan
> Ego Trip is the right phrase

Well, here's the thing about that, though... somebody _does_ eventually pass
these interviews. It may be a tough blow to your own ego to realize that you
actually weren't the best candidate out there, or that somebody more qualified
than you would be willing to accept a position that you yourself are just
qualified enough for, but probing the competence of the candidate is entirely
the point of a job interview. This is doubly important for a technical
position where a false positive is orders of magnitude more damaging than a
false negative.

~~~
glangdale
I like how you are assuming that I'm writing this out of sour grapes. I've
never failed a technical interview. As always, there are an ample supply of
folks (of, ahem, rather _varying_ achievement levels) on Hacker News who
always seem to fondly imagine themselves on peering dubiously over their
glasses at my while I supplicate for a job. :-)

Maybe you could try to apply the supposed Hacker News rule of not assuming the
person you are responding to is a complete idiot? I'm startled to think that
you assume that I wouldn't understand that interviews are typically
competitive processes where some people get hired in the end and (at
sufficiently desirable jobs) most people don't.

Instead, you could maybe think through whether "competence" == "ability to
pass typical BigCo coding interviews" and my actual point? Really, basically
any of my points? I have met, and worked with, people in all 4 quadrants of
that particular pair of qualities.

------
uxenthusiast
I'm doing a lot of interview as an interviewer these days mostly with junior
candidate.

The guy in charge of those before me was the kind that use aha question with
no relevance whatsoever. Pure ego trip. If that guy had interviewe me I would
have said "I don't know" a few times and eventually get up and leave.

For my candidates, I tried a few things. Now I've got it down to explain to me
your last project. I ask questions until I've understood every little detail
of the project. Then we code a few simple "exercises" with increasing
"difficulty". The candidate is allowed google, documentation, questions,
anything. Then we _read_ code. A piece of code with a "bug" or a feature to
add.

The key is to make them talk about concept from impérative, fonctionnal and
object paradigm and interact like a junior and senior dev would in a dev team.

I found that junior candidates react pretty well to these. Some of them thank
me for having had the opportunity to learn about new things like functionnal
programming. It's pretty cool and I feel that make them want to join us most
of the time.

------
x87678r
One issue is very few people get interview training. I have interviewed maybe
100 people but had to figure it out for myself what works. I wish I could
apologize to the first few dozen.

~~~
leafboi
Another thing to consider is even if you interviewed that many people there's
really know way to evaluate your interview accuracy and performance unless you
work with all 100 people.

------
wwarner
Look, you have to do technical interviews. You don't have to be a bully, but
you have to find a way to probe the candidate's ability to solve technical
problems and code.

Pick a question that tests the skills you're looking for, but not too closely
related to the problems you encounter every day, as that will introduce really
strong bias. Pick a question that can be answered in 10 or 20 minutes on a
white board. The question should seem really easy, so prepare a follow up
question (or two) that adds difficulty for the candidate that needs the
challenge.

But here's the most important part: use the same question in at least 10
interviews. Test your questions by using them on many candidates. Don't
introduce uncertainty by playing a different role in every interview. You'll
get much better results.

~~~
sg47
45 minutes - write a simple API matching the spec in one of the 3 languages on
your/our laptop. Use Google if you have to. Someone will be in the room to
help answer questions. API should be functional. Returning fake data is fine
(or provide data in a sqlite db)

45 minutes - do code review of this extremely buggy code like you'd review a
coworker's code

45 minutes - presentation on a technical topic to one or more members

45 minutes - behavioral. Let's talk about failures, conflicts in your career.
Who are your role models? What do they do well? Leadership abilities, career
progression

45 minutes - troubleshooting. Here's a docker container. Make this thing work.

Rate all these on a scale of 1 to 10. Sum up the scores. Keep calibrating
across all your candidates.

------
vasu_man
"Every step, conversation and question must be pertinent to the day-to-day of
the role"

While I agree with the author's 'golden rule', I believe the complex data
structure questions are just a way to filter interviewing candidates in a
highly competitive job market. It's akin to the highly competitive Indian
Joint Entrance Examination (JEE) where hundreds of thousands of students solve
complex problems in Math, Physics, and Chemistry to get into premiere
institutions with few thousand seats, most of whom do not pursue a career in
sciences.

~~~
ozim
I think that biggest issue for me is when some small startup acts like
"premier institution". If you need to sling out cookie cutter code to deliver
stuff to your customers don't pretend you are going to change the world.

I just rejected one company because they had 4 pages of NDA and were small
company.

------
rehman
Problem solving skill is a must. Not saying to cram the algorithms. But using
those in your approach shows the ability of the candidate's efficiency and
quickness in solving them.

------
dmurray
There's so much hate for "whiteboard interviews" and "interviewers focusing on
themselves rather than the candidate" and all that on HN, but what if...this
is actually what works for some companies?

Some people want to work on super challenging problems with technically
brilliant coworkers. Some people treat a poor performance not as a
humiliation, but as an opportunity to understand how much they do not yet
know.

What if you want to attract candidates like that? Ask them tough questions,
don't tailor the questions to their strengths, and have the interviewers show
off how smart they are (even if they're not, it's easy to appear smart when
you have all the answers). Pay good money and have high prestige so that you
get plenty of quality applicants for every role, because you're going to miss
out on many of the good ones, but you will attract some of the brightest and
most driven people.

------
nojvek
Ha! Zoox (the self driving car company) out of the 5 hours, 2 hours were math
problems. Couldn’t google. Couldn’t use a calculator. No notepad. Had to use a
zoom virtual whiteboard.

What’s the area of an equilateral triangle ? Volume of a sphere? Sorry.
Haven’t needed to use that in eons. I usually just google it.

~~~
oblio
I'm guessing they were looking for game engine developers or 3D modelling
engine developers, which probably know those by heart.

------
sleepysysadmin
Most technical interviews aren't technical. You are expected to know
irrelevant trivia like which port does ICMP use? There's literally no job on
earth where that matters.

So when I did technical interviews; I had a demo domain controller vm. I
printed out 5 steps they need to do. dcpromo, slave domain.local to the dc,
install wsus. pretty boring stuff that much candidates know how to do. My
trick, there's lots of tiny details like did you get the server's name instead
of SERVER-1897237534

Oh and I'll be talking about video games, tv and movies distracting you as
much as possible during the testing. I just sit there asking them question
after question about hobbies. Really really distracting.

------
px1999
As an interviewer and decision maker around hiring engineers, there is zero
legitimate reason to make the candidate feel like an idiot for not knowing
something. It's easy enough to clarify what they're saying, and if there's a
miss to just say "ok cool" and to ask the next question.

------
fatjokes
Unpopular opinion: I like technical interviews. They at least enforce _some_
form of a standard hiring bar.

I feel this way because I've seen hiring for non-technical roles, e.g.,
project management, etc. They basically end up being friends hiring friends,
with minimal domain expertise.

~~~
mixmastamyk
A bad hiring bar can be worse than random for hiring good candidates.

------
ricardobeat
Sadly there is another side to this - by not doing any kind of technical
assessment you expose yourself to fraud. I would have never expected that in
the past, but after nearing a hundred interviews I saw a few cases of a
candidate's skills as judged by code samples looking _completely different_
once they were writing code on the spot. The exercises were all related to
real tasks. I don't think we'd have caught on through product or problem-
solving questions.

~~~
leafboi
There's a real performance downgrade when performing in front of people. To
add more accuracy to your assessment I would give these people the opportunity
to perform in a room without someone watching.

------
hanoz
So I've always wondered about these leetcode interviews, having never suffered
one myself, if you're given one you've seen before, are you still supposed to
pretend you're working it out from first principles?

~~~
pkaye
Long time ago I go the "Why is a manhole cover round?" at an interview. I
prefaced that I heard this question before and followed up with 3-4 possible
answers. The interviewer was still impressed.

~~~
daniellarusso
I have started asking this, since I have not heard it asked in awhile (like
almost 2 decades), and it is interesting to hear the responses.

~~~
wyclif
It's clichéd question, but in my opinion it's a very good one and would still
be useful if it wasn't so overused. The reason why is because there's one big
reason why manhole covers are round and maybe 3-4 subsidiary and less
important reasons why. A person who can 1/ identify that there's more than one
reason, name them all _and_ 2/ sort and rank the reasons correctly in order of
importance reveals a person's clarity of thought and reasoning process.

~~~
daniellarusso
My initial intent, because I thought it was so clichéd, was just to get a
laugh.

But, I would say the majority had not heard the question before.

This is a younger cohort.

------
pstrateman
Sometimes your job is just to make the button bigger.

That job is not called software engineer, that job is called junior code
monkey and pays $25k/yr.

------
Google234
I want to work with engineers that know their basic algorithms. Sorry, but
complicated projects require smart solutions. If you don’t know the basics,
you won’t be able to solve difficult problems efficiently.

------
sushshshsh
idk i do well in them

------
pictur
Sad but true

------
LordHumungous
Oh I see it's time for this blog post again.

------
TheOtherHobbes
YC2025 - "home.ly" \- we aim to disrupt the remote technical interview process
by replacing capricious human interviewers with the latest conversational AI
leet-bots...

------
hashkb
If we aren't complaining about interviews where we got the offer and turned it
down, there's a serious risk we're experiencing "sour grapes". Every interview
I failed was an opportunity to get better. If it feels arbitrary and you don't
get the job... you may just be below the bar. No shame in that... buy there's
definitely shame in this sadly common framing attack on the concept of the
tech screen.

