
How not to hire a software engineer - kiyanwang
http://tonsky.me/blog/hiring/
======
kristopolous
I look to see if I can trust them to not do dumb things. That's really it.

What's the ego, arrogance, competence, willingness to ask questions,
interrogate things, redefine problems to be less work (or none at all).

Do you see what's not there? Programming language competency. Database
knowledge. Things like that.

I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for
mainframes in the 90s - I had never seen a mainframe. I was told about 20
years ago to write a program in perl, my boss gave me a perl book with the
assignment because I didn't know perl and I did it.

This is not a bad way to go about work. Every codebase is new. Every job has a
steep learning curve. Every requirement is a conversation which may only be
internal, but has to always happen. Every programmer you work with is someone
whose preferences, strengths, styles, and weaknesses you need to have
intuition on. People good at those things are what make good programmers.

That's why general competency, ability to learn, not to create a mess and not
to waste time on stupid things are the only things I care about. That's really
it.

Preexisting technical skills aren't as important as how dynamically you can
apply new ones.

~~~
TallGuyShort
I interview quite a lot, and one of the things I try to do in an interview is
work through a problem that I _almost_ certainly understand more deeply than
any of the candidates (both because it's my niche and because I've worked
through the exact problem with hundreds of candidates before). There's a
certain minimum bar that I expect any educated and intelligent individual to
achieve if they're a good match for the job, but then I take it really far
beyond what I actually expect them to know, to the point where a lot of the
details are unknown, and the details matter a lot in determining what kinds of
solutions will be successful. Do they start BS'ing me? Do they confidently
walk into really nasty parts of the problem without recognizing the pitfalls?
Or do they tell me they're a little stuck? Do they ask which trade-offs to
make? Do they ask if they can do some Googling for prior research on the
problem? Do they explain what they would try and what pitfalls they would
watch our for, or how they would validate their idea? Do they ask if they can
make some simplifying assumptions for practical purposes? There's a lot of
right and wrong answers but really I want to see their attitude and
communication.

My first couple of hires before I did this were a brilliant computer scientist
and a guy with a business degree and some coding background. I was surprised
to see the guy with the business degree excel because we weren't doing many
CS-hard problems, and an ability to manage time, talk about the problem, and
navigate the project life cycle were far more important than classic algorithm
knowledge. He needed to know how to code and debug, for sure, but like most
software jobs, his soft skills were a force multiplier.

I'm pretty sure this has been done with me - I was given a problem and told to
come up with something like an O(n log n) solution, and I honestly couldn't do
it. I tried a few different approaches but I could think of really bad
pathological cases for all of them. The interviewer gave me a few suggestions
which I explored and I kept exploring them and then admitted I didn't see a
way forward. I thought I was bombing and then he told me I did really well. I
looked up the problem and found out he had done Ph.D. research in that area,
and there was no general O(n log n) solution - only solutions that could do
that in most practical cases.

~~~
kristopolous
If I smell any bs then I immediately change tactics and make sure I put them
deep over their head. For example, "what are the strengths and weaknesses of
classifying grammars via the Chomsky hierarchy?"

There's 3 ways to answer these kinds of questions and it exposes you as either
a genius (or in this case a linguist), a non-genius (real geniuses are as
common as 7.5 ft tall people) or a bullshitter trying to look like a genius.*

I've never met an actual genius in an interview so let me address the other
two. That third group is a nonstarter. I've known the person for 10 minutes
and they're already trying to deceive me. How the hell am I going to build a
product with them?

Kim Scott, some SV big wig wrote an entire book on this called Radical Candor.
Essentially it's "don't bullshit people (and know where your taking the
relationship when you use that rule)"

I strongly believe companies work best with the smallest bullshit quotient
possible. They may sell more or be more profitable with certain flavors of
bullshit, but things are easier and more stuff gets done without it.

At the end I would have rather actually made something than duped people with
sham products sold on dreams

\---

* I actually can't answer that question but I could probably identify the neighborhood of a real answer (...something something limitations of the von nuemann model restricting the constructions of parsing systems something something...). The point isn't to answer it, although that would be quite impressive; it's to see how far someone digs into their own BS.

~~~
mjcohen
For Chomsky, I would hazard finite state automata, BNF systems, and Turing
machines. I might then mumble about number of tapes and time to recognize, and
then stop.

~~~
JustSomeNobody
Type 0, Type 1, Type 2 and Type 3 (aka: Type K grammars).

Type 0 is an unrestricted grammar.

Type 1 is a context sensitive grammar.

Type 2 is a context free grammar.

Type 3 is a regular grammar.

For our (CS) purposes we typically use Type 2 and 3.

------
externalreality
All the things most programmers do these days are pretty mundane and the only
thing you need to ascertain is if they are familiar with the technologies that
are being used. "Can you show you know sufficient SQL? Did you write
applications before using Rails/Django what have you? Distributed this, Web
that - OK, jobs is yours." After all that the productivity of the programmer
is solely based on the work environment and how motivated you can keep a
developer who is becoming depressingly convinced that his calling in life is
to write web handlers and optimize queries to a bloated database schema and
watch the guy whose been on the job too long walk around like he's some fusion
of John Carmack and Elon Musk.

Why these interview processes act as if candidates are going to be designing
graphics engines from scratch for graphics hardware extracted fr om a downed
alien spacecraftis beyond me. We just really be testing their ability to sort
through a bunch of legacy OOP designed by people who are so board with the
project domain that made of bunch of bad abstractions and used every new OOD
technique in the books when a handful few procedural functions would have
sufficed.

~~~
shapiro92
> All the things most programmers do these days are pretty mundane and the
> only thing you need to ascertain is if they are familiar with the
> technologies that are being used.

this is exactly the company/boss i would not want to work for. It is exactly
the opposite. You should not care if the person if familiar with the tech you
use. Who cares if you do php or c#? Does it REALLY make any difference when it
comes to taking the business logic and adapting it into MVC/API?

~~~
LandR
Yes.

Because if they don't have a deepish understand of the language and framework
IME they tend to write crap code.

If someone is being hired to write C# /.NET all day every day I don't want to
have to spend time teaching them C# or .NET

Especially not how to write good C# / .NET.

~~~
metric10
Wasn't part of the point of C#'s syntax was that it was easy for C++ and Java
programmers to learn? Would any real C# advocate really tell me it would take
months of manager supervised learning to pickup?

I've been writing code for a long time in many languages and I do my best to
write "good" code. The principles that make code "good" in one language appear
to apply equally to other languages...

~~~
externalreality
I would argue that what makes code "good" is completely subjective which is
why I don't spend too much time thinking about it.

The only criteria I have for good code these days is "Does it work", "Can I
understand it". Everything else is a good IDE's command away for being willed
into reality. So I really don't spend too much time on the "good" code debate
like I did as a teen reading "Clean Code" and GOF books. I actually wish I
could have that time back, I would have read, in their place, books on type
theory and OS design, Posix, in other words things that actually help me build
stuff and get things done and that I subsequently had to read later. Undo the
damage done by the "good code" people that have me thinking about stuff that
nobody cares about. Take a month off, read a book on game design in opengl,
and write a cool robot simulation or something and remember how much more
gratifying that is than writing a small do-nothing program just to try out
some useless design pattern that doesn't scale beyond micro-examples.

There is so much varying lit out there on how to write good code that I am
surprised that I am surprised if even 2 programmers can truly agree on what
good code is. So Again, I'll say that "good" when it comes to code should be
equivalent to "easy to understand" and "does the flow of text match the flow
of program execution" in other words "is it easy to understand given I am
familiar with the problem domain".

~~~
jimbokun
"The only criteria I have for good code these days is "Does it work", "Can I
understand it"."

Which of course, are not trivial to achieve by any means.

Maybe also add "Can my coworkers understand it?" Which might be a very
different metric.

"I would have read, in their place, books on type theory and OS design, Posix,
in other words things that actually help me build stuff and get things done
and that I subsequently had to read later."

If you want to get very far with any of those, you will need to write "good
code", as you have defined it. So maybe a better way to understand good code
would be to read the code of large projects implementing the things you want
to learn about?

~~~
externalreality
I don't know. Procedural code in Golang is pretty trivial - you basic
constructs are regular in the selection, iteration, and sequence sense with a
sprinkle of interfaces and some CSP constructs for concurrent design. That
covers like 99% of what you need to write good code. I'd say pattern matching
is pretty helpful Ala ML, Haskell, Rust. Beyond that all the GOF and Solid and
all that jazz seems to do way more harm than good IMHO.

> If you want to get very far with any of those, you will need to write "good
> code"

If you have ever looked at the code of the most successful programs the code
is anything but "good". Have you glanced at the Linux Kernel code lately? But
again, "good" is very subjective. The Linux Kernel works well enough to server
the purpose of millions of users and enough people understand it. Its good
code!

------
nsb1
I don't ask brain-teasers during an interview, but time and time again the
value of a simple coding assignment has proven its worth. It is simply amazing
to me how many candidates seem to lack the basic ability to code a couple of
nested for loops, and weeding those candidates out early streamlines the whole
interview process.

I will typically do this on a phone screen, having informed the candidate
beforehand that they need to be near a computer with an internet connection
during the call. Typically this will be after business hours, so they're at
home where they're comfortable, and on their own machine, whatever it is.

I use a site called rextester to administer the test. I've been using it for
years, and it's fantastic.

[https://rextester.com/runcode](https://rextester.com/runcode)

As the tester, you go to the site, choose the language, and click 'live
cooperation' at the bottom. Then you email or tell the candiate the link to
follow, and both of you click on it to go to the shared coding editor. You can
now see the candidate type and talk about how they're solving the problem,
editing yourself to give hints/clarity if need be. To save time, you can have
some code handy to paste in and pre-seed the problem if you choose (like a
list of data to sort, etc.)

This tool has proven immensely useful in my interview process, and beats the
hell out of whiteboard coding in person, IMHO.

[edit - spelling]

~~~
qudat
I think you're testing for someone who can think on the spot with a person
watching every keystroke which would be rare in an actual work environment.
For a lot of programmers, they spend most of their time in their own head
thinking through a problem, trying things, removing things, etc. To accomplish
what I think you are trying to select for would be a take-home assignment. The
interviewee can work through problems in a more natural way without someone
watching intently on every keystroke.

~~~
sgillen
I think that asking really simple fizz buzz style questions in this context is
probably fine. The whole point I think is to screen out candidates who can't
do these sorts of assignments in ~5-20 minutes or whatever. With a take home
assignment you'll get people who spend two hours or on your 15 minute problem
which is the kind of person who I think OP is trying to filter out.

I think even if you're not the kind of person who can think on the spot with
someone watching you well, you should be able to knock out fizz buzz style
question in that setting quickly.

------
morkfromork
Lately I have done a few at home code challenges for companies. They usually
take several hours. They are perfectly functional and use minimal code but,
the only feedback I receive is: "we're not moving forward". They won't discuss
anything with me. The only impression I get is that your company is terrible
and I will never respond to your recruiters again.

~~~
yitchelle
For me, honest and accurate feedback is the one thing that is missing.

When I get rejected, the response is usually "You are not a good match to our
company culture". What I would appreciate would be "Your lack of experience in
managing remote teams is a gap for us."

I feel that quality to the pool of candidates will increase once this feedback
loop problem is fixed.

~~~
gota
I'm not sure this is true but I've heard people who work in 'hiring' say so:
from the company's point of view there is almost no upside to providing
insightful and useful feedback, and there's always a chance that feedback will
be used to sue for discrimination, or ridicule the company online, etc. Best
to be generic and forgotten about by the candidate as soon as possible

~~~
geomark
Mostly this. I was a hiring manager at a big company where HR made it very
clear we cannot give specific feedback to applicants. We also could not give
references for the same reason; fear of being sued. But after a while you
learn to speak in code for those cases where you really feel you need to
provide meaningful information.

The last time I was asked for a reference I was contacted by a hiring manager
who said they were about to make an offer and just needed a couple references.
It was a previous employee who had been a particularly low performer. My
response was "Company policy prevents me from providing any references.
However, (pregnant pause) you should always be very careful and selective in
your hiring process." The hiring manager asking for the reference was baffled.
She must have been new and had not yet learned the code. Later I bumped into
her at some industry event and she thanked me profusely because my non-
reference prompted her to do more digging and she learned just how bad that
candidate was.

Moral of the story: learn the code (strikes me as kinda funny on HN where the
usual advice is learn _to_ code)

~~~
jahrule
wtf. what you are describing is something that i would say is suable. and
should be.

you basically said dont hire that person to someone. because of your bad
experience with that ex-colleague ?. you are denying that person a chance. how
come ?

what are you going to do next time someone calls for reference ? the same ?

immature, questionable, discriminating practices...

~~~
rightbyte
Strange. Where I live it's common practice to ask former employers about a
persons performance. I you have no prior work experience they would want to
call your math theacher or army drill instructor.

In the US it's illegal? It's discrimation yes but isn't that the whole point
of a recruitment process?

~~~
cr0sh
It's illegal in the US for the company or anyone representing the company to
say anything more than that they worked for the company, and what they worked
on.

They can't tell the person that the employee was fired, or anything like that.

But as noted - there are ways used to get around such things (that is, the
laws of our country). Those laws exist because people were wrongly
discriminated against by using such "references".

But if you have a reference to someone you worked with, and they are no longer
employed by that company - then I'm pretty sure they can answer anything they
wanted too (unless there's some kind of NDA they are still under after leaving
the company). Because they don't represent the employer any longer, and are a
personal reference - things become more casual.

~~~
infinite8s
That's not illegal. HR/legal just usually prohibits it because negative
feedback could potentially be used in a discrimination lawsuit.

------
ankit219
A perspective from the interviewer's side. Since I run a small startup, when
hiring, my first thing to determine was that whether I would be able to work
with the candidate. Hence, I would come up with a puzzle, a maths problem, or
even a guesstimate, just to see the thought process and that whether there is
any "gelling". Things to evaluate are, original thinking, how well the
candidate puts his perspective forward, how well he takes suggestions, how
quickly he reaches the crux of the problem etc. If there is a face to face
interview, the general assumption is that the candidate is talented, more
important is that whether he can work with others in the company. If I am
hiring someone who will work alone, without anyone's inputs, I might change
the process (something like an integration or SSIS workflow) but have not
needed to encounter that as of yet.

I usually go through the resume, and have interviewed enough coders to
understand that they would know about what is written on the resume. Hence,
knowing the background is good enough for evaluation, but feels repetitive
during the interview. (Also, if you have had 4-5 years of experience, and 2-3
jobs, you can only stay for long if you had good skillset)

~~~
gwbas1c
I usually give my disclaimer: "These aren't real world problems. Some
questions involve code that we wouldn't write in the real world. We only have
45 minutes. The goal is to have a conversation about code."

And then I point out that "it's not practical to spend 2-3 days on-boarding
you for a job interview. Thus, these questions are contrived. The best way to
succeed is to have a conversation about code, and sometimes you need to play a
little bit of the 'tell me what I want to hear' game".

And then, for one question, I need to point out that, "I once had a candidate
say, 'I like JSON better then XML. XML's outdated.' This question is to
discuss concepts that are easy to discuss with C#'s XML APIs, because chances
are, you've used them." (And if the candidate tells me that they don't have a
lot of XML experience, it's okay.

------
zensavona
Interestingly in the last 6 months I’ve been on both sides of this: being
hired and hiring others. It was really cool because it allowed me to
understand what is actually good and useful in the hiring process from both
ends.

While hiring (only 2 people, one junior and one senior, both fully remote) I
just had a ~45-60min chat about technical and non-technical things (e.g. what
do you think about functional programming/rails/deployment/ops/whatever, what
does <something> mean to you, how do you feel about <some workplace practice>)
and then gave them a small paid project to work on our actual codebase -
something like implementing a small, self contained feature or writing some
tests for a particular piece of code. I found this to be a really good way to
find out if I’ll like working with someone and if they are a good fit on a
technical level.

~~~
lucbocahut
I second this. I freelance as a part time CTO and this has been my favorite
appproach to hiring devs. A paid project goes a long way to establishing a
good work relationship and gives both sides most of what they need to decide
if it’s a good fit longer term. I also always offer my clients to start with a
small contained project to see if we’re a fit. This ends up saving a lot of
time: the risk is low for the employer, and the developer gets paid their
market rate and has a chance to show that they are worth it. It’s then really
easy to decide if we should continue working together or not.

~~~
jahrule
>freelance as parttime CTO

job title inflation bingo !!! ;)

------
wink
On the plus side: I wholeheartedly agree with all those points.

On the contra side: Nothing of this really felt like it helped me. I found
interviewing people absolutely horrible and almost never had a good feeling.
People who seemed like they may have been a good fit didn't get offers for one
reason or another, some people seemed awesome in the interview and then
weren't. Overall I've been happy with the decisions I personally made (not all
that the team/higher-ups then made) but even with the best of intentions..
it's hard. But it was a small company so maybe it was already a problem of not
looking very interesting to some.

It still amazes me that some people seem to be utterly disinterested in what
your company does or how they will work in a team, asking basically zero
questions besides "how much money?" and "which language?".

~~~
r_smart
At my last employer, I sat in on an interview for a co-op with my boss. After
asking the interviewee some questions the conversation went basically like
this:

Boss: Do you have any questions for me?

Co-op: No

Boss: Would you like to know about the company? What we do?

Co-op: No

I couldn't help myself from laughing. I know he's just a student, but he's
still a 20 something adult. No interest at all, just looking to check another
box on his list of credentials. At least fake it!

~~~
watwut
I just don't really get this attitude. What exactly you want me to ask
assuming I know salary and position? General information about company is
usually right there on the website. I am really not sure what exactly the
hiring manager is supposed to be asked at that moment, especially by someone
young who does not have enough experience to distinguish between lying hiring
manager and the one that tells the truth.

I could see meaningful questions about vacation policy and overtimes and such,
but that comes with experience and a.) youngsters wants pretend how they don't
care bout weekends in work b.) companies lie about that sort of thing.

I know that this attitude exist so I will ask something, it is not about that.
But, the exercise is mostly empty for someone who is inexperienced and does
not fully know yet what are situations where he fit vs where he does not fit.

~~~
jimbokun
"What exactly you want me to ask assuming I know salary and position?"

"Who are your most important customers?"

"What is your monthly recurring revenue?"

"What is your best selling product?"

"What's one thing you like about working here?"

"What's one thing you don't like about working here?"

This isn't very difficult. Just requires a slight interest in the industry you
plan to work in.

~~~
watwut
None of them is useful for anything. They are just questions that you ask to
fulfill the "must ask question" requirement. Generally, product is on company
main page. Asking that one likely shows you did not seen it.

Moreover, they are unlikely to tell you monthly recurring revenue. That is
just odd question. Our company would not definitely.

Hiring manager will not tell you what he does not like about working there -
for the same reason why you are not truthful about why you left previous
place. Seriously. I would not ask the like dislike question for similar reason
- it strikes me as odd and possibly would mark me as someone with low social
skills. But the risk there is not too high.

~~~
wsy
If you read the company's web site, and are a curious and interested person,
then you should pretty quickly stumble upon things you would like to know
which aren't written there. So if you come up empty, either you are not
interested in that company at all, or your curiosity is so easily satisfied
that a plain web site can answer all your questions. Both is not a great sign
for a prospective employee.

Even suppose you apply to a straightforward company with an extremely detailed
web site, so that all your questions have been answered already, then this is
still a test if you can meet social expectations. You are indeed expected to
have questions, and if you don't even follow this simple convention because
you think you know everything already, then your social skills are probably
underdeveloped.

Finally, even you already know much about the company (e.g., about the most
important product), asking about things you know already and comparing this
with what you are told in the application talk will give you additional
valuable information. Are they excited about their product? Are they
exaggerating? Are they bored when answering? Do they know the basic
information on their own web site? If you don't use the opportunity to extract
as much information as you can, it's simply not smart.

~~~
watwut
It just sounds like complete rationalization. That is not how humans work nor
how companies work. That is not how interest in things work especially not in
work or position.

Yes, it is test of whether you know that social thing. So, if the company is
treating it as the test of that, then it is fine. Instead, the parent was
almost offended over that "No interest at all, just looking to check another
box on his list of credentials. At least fake it!".

> Are they excited about their product? Are they exaggerating? Are they bored
> when answering? Do they know the basic information on their own web site?

Christ, you are talking with hiring manager at that point. I would not mind
him not knowing company web site. Most employees don't actually go there all
that often. That person might not even work on that product. Unless we are
talking about very small company, people do their small parts of the larger
whole.

You are hiring tech person and while cooperation, ability to express oneself
clearly and without pointless insults, ability to listen and such are
important, ability to guess excitement from someone they don't know much less
so. It is not sales position.

~~~
itronitron
I generally agree with your view, an experienced candidate will be able to
figure out a lot of the work environment during the interviews before meeting
with the hiring manager. Although I generally have a few softball questions
that I ask as either filler or to see how much thought they have given to how
their development teams work.

------
ordinaryperson
Agree with everything the OP said but I'd add: when hiring for senior
engineers, this process is even more absurd because the real skill of senior
engineers is not how much horizontal knowledge they've acquired (knowing web
frameworks, Linux guts, databases, distributed systems, etc) or vertical
knowledge (being a domain expert in X) but their soft skills -- how good are
they at convincing other people of something in a meeting?

A real example: a product person once asked a team I was on for a feature
that'd be difficult and time-consuming to program, probably taking the better
part of a year. My teammates said no. Not, "We want to ship this software soon
and we don't think that's an acceptable tradeoff," they just said no. Product
became furious (not knowing how hard it'd be, since the engineers hadn't
explained it) and it hurt those developers.

Knowing how to invert a b-tree doesn't help you solve situations like those,
which are far more common than 99% of fake problems presented in programming
interviews.

When I interview a candidate I ask them to tell me about projects they worked
on and poke and prod about real-world stuff they actually did, not converting
a singly linked list into a circular linked list.

Ideally people would be offered the choice of an in-person or take-home to
satisfy both those who feel like they shouldn't have to spend their free time
on homework and those who don't like being forced to instantly come up with
solutions to fake problems.

I blame Google for introducing this scourge, hopefully it lifts before the
next time I do a job search.

My favorite example of this is Google turning down Max Howell for a job:
[https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768)

------
etxm
I like giving coding “tests” but I prefer to let the candidate pick an issue
from an open source project ahead of time. I want to be on as close to the
same footing as the interviewee.

I like to see them work in as comfortable and nerve free environment as
possible.

And in the event that the person doesn’t get hired, they have a commit on
their GitHub and maybe added some value to a project.

~~~
qudat
> they have a commit on their GitHub

Maybe I'm applying to the wrong places but virtually no one cares about my
Github. It's really sad to see so many potential employers ignore one of the
best pieces of information for a candidate. For reference, my github is filled
with maintained projects and OSS with people using them, submitting issues,
prs, etc. It's like the employer's process is set in stone and since a lot of
people don't have active githubs, it cannot be used as a comparison.

I think the places that do look at github profiles are great, but then I fear
they end up looking for massive OSS projects for it to bear any weight.

------
tuco86
I really liked what my last interviewer did. He did not think of an abstract
quiz to test some abstract skills. He took a Problem they where fighting with
for some time and we just had a conversation about it.

When can you start?.. Tomorrow.. See you then.

Find someone you can work with on the actual problems you face: work with them
during the interview. Just struck me as genius.

I was nervous about my CV not looking too good, he didn't even bother to look
at it.

~~~
cr0sh
It does sound like a good way to interview a candidate.

But I can see from the company's side it being a bit of a potential legal
challenge issue. Depending on what the problem is and how deep it goes into
the codebase or whatever, you might get into proprietary process information
that someone outside the company shouldn't have access to, possible IP access
violations, etc.

If it can be done in such a way to avoid those pitfalls, then it might be ok.
But I bet it's a tricky challenge, and may be why it isn't done often?

------
Adamantcheese
I suppose I'll be the first to say that yellow as a background color is a
horrible design choice. And it's not even using the background color CSS
option alone, it's got some weird tiled single pixel yellow image on top of
it! What??

~~~
deadbunny
Firefox > Reader View

Save your eyes.

------
ignoramous
I think the crux of the problem is... Everyone knows what to expect in a SAT
exam, and still if one complains that they didn't bother preparing for it
'cause they do not have enough time... That excuse is not getting them an
admission to top institutions, which admittedly have no short supply of folks
willing to prepare and go through the grind.

It is sad that interviews in tech have been reduced to a process that
resembles SAT-esque entrance exams. And now, there's an entire industry around
prepping candidates for the interviews.

That said, I like the approach tptacek wrote about: Give the candidate a book
or two, and when they are ready, interview them on it instead of interviewing
on algorithms and data structures regardless of the position/industry [0].

I'm not so sure about Stripe's process as well [1], because one might have
been effective because of the team and setup they are comfortable with in a
given setting that isn't replicatable in an interview setting. No amount of
'bring your own laptop' to the interviews is going to make it work for the
interviewee. You need to test the interviewee on the basis of their strengths.
Not arbitrary measure of strength. Gosh, this is a hard problem.

There was an article on techcrunch about interviewing in tech and how it
breeds ageism [2]. The premise was that it is simply not possible that most
folks with X yrs of experience at a software shop are all secretly terrible
that they can't get past your interview process.

Either you are part of an exclusive network to get on a rocket ship of a
startup [3], or slog it out like everyone else: I remember how tough it was to
get a job at Facebook in 2009 or Google in 2005 with ACM ICPC finalists and
TopCoders as your interviewers.

[0] [https://sockpuppet.org/blog/2015/03/06/the-hiring-
post/](https://sockpuppet.org/blog/2015/03/06/the-hiring-post/)

[1] [https://www.quora.com/Stripe-company/What-is-the-
engineering...](https://www.quora.com/Stripe-company/What-is-the-engineering-
interview-process-like-at-Stripe?share=1)

[2]
[https://news.ycombinator.com/item?id=9166501](https://news.ycombinator.com/item?id=9166501)
(on secretly terrible engineers).

[3] [https://a16z.com/about/](https://a16z.com/about/)

~~~
ummonk
>It is sad that interviews in tech have been reduced to a process that
resembles SAT-esque entrance exams. And now, there's an entire industry around
prepping candidates for the interviews.

I'm not sure why that is bad. The more standardized the interview process is,
the more consistently people can prepare for interviews and know what to
expect. The interview process doesn't have to represent actual work, as long
as preparing for and performing well on the interview requires the same skills
used to learn and work with a new software feature / language / problem.

>The premise was that it is simply not possible that most folks with X yrs of
experience at a software shop are all secretly terrible that they can't get
past your interview process.

That's an obviously false premise.

~~~
ignoramous
> I'm not sure why that is bad. The more standardized the interview process
> is, the more consistently people can prepare for interviews and know what to
> expect.

Yep, agree. You tend to then hire folks who are good at interviewing and not
at getting the job done. I think there is no right answer but multiple right
answers. Provide three or four different interview loops and let the candidate
choose which one they want to opt for: for instance, one loop is the standard
algorithms/data-structure, the other loop is a take-home problem, the third
could be tptacek-style, the fourth could be stripe-style, and so on...

> That's an obviously false premise.

Sorry, I didn't get. The article argues that obviously that many folks with
that much amt of work experience can't all be secretly terrible that we
continue to find it hard to hire and so the current interview process needs an
overhaul.

------
bryanrasmussen
#1 thing for me - don't ask me to be a salesperson. In relation to this post -
[https://news.ycombinator.com/item?id=19534772](https://news.ycombinator.com/item?id=19534772)
I was recently at an interview and the interviewer was a technical guy who had
recently been promoted and he had a checklist of 10-15 things he wanted to
achieve in the next half year, all really good reasonable things and then he
said 'Now I just want you to tell me why you are the best person to do this'.

I finally had to give up and say hey lots of people can do what you want, I
can do it and I can give you a list of people who can do it, I don't
understand this "best" thing you want from me?

~~~
mlthoughts2018
I actively say things similar to what you said. For example, if I’m ever asked
why I want the job or why I’d be a good match at the company, I will always
say I don’t know. I’ll always say I’m not trying to be facetious or dodge the
question, but with limited information from a job listing, maybe a few phone
calls, and a day of small 1-hour interviews (that are mostly made up of coding
questions with no time for me to ask questions), then it’s just not possible
to give a sincere answer that has any more depth than a rehearsed answer based
on LinkedIn advice listicles or something.

~~~
bryanrasmussen
It is very difficult for me not to say I want the job because I sell my skills
for money, if you are willing to pay the price I want then I am willing to
provide the product you need.

~~~
weka
"because money can be exchanged for goods and or services."

Interviewer didn't like that answer too much, heh.

------
keithnz
Best way to hire programmers is to hire them without getting them to code.

Before anyone burns me at the stake...It's not really the "best" but it can
work. I was a coding interview advocate for a long time. I changed it from
solving puzzles, to solving real problems taken from the domain they were
interviewing for. In the early years I was a bit surprised by who struggled
with coding, but I noticed a trend after a while, I could mostly tell how well
someone was going to do from the preliminary discussions about software /
design / experience / tradeoffs / etc. So I actually learn a lot more about
the developer from that discussion and have tried to get better at that to
explore more things. I like to focus on the nitty gritty of real problems,
hand ow to approach architecting a piece of software from all angles. I do
still use coding where I think it might help, with grads, I mostly do coding
as its a good icebreaker into general conversation, and intermediates where
their experience is still limited, I like to set problems that test peoples
ability to keep their code tidy and modular, to see if they have developed any
coding discipline, but sometimes from the initial conversation I will already
know. But most often I already have a good idea.

~~~
sokoloff
While a lot of what you say is true, that hiring pattern leaves you exposed to
the bullshit artists.

I always want to see some kind of code from someone for whom coding ability
matters at all. Doesn’t need to be extensive, tricky, or even written live in
front of us, but when the job is more than talking, I want to see more than
just talking to evaluate.

~~~
keithnz
I've seen the bullshit artists. When I was early on in interviewing people (
I've been coding just less than 40 years and hiring people ~20 years ), they
did surprise me when it came to coding, though I never came close to hiring
one. But it turns out, I just wasn't asking the right kinds of questions to
pickup on bullshit, or I would let things slide without question where they
seem to have glossed over things. But like I say, code isn't out of the
question, if I end up with doubts, usually because I can't get super concrete
details out of someone, then code is a good way to go.

~~~
0x445442
I've been responsible for hiring 10 or so engineers in my career and everyone
of them turned out to be a good hire from the company's perspective. I was
always able to smell the BS pretty quickly during interviews and it's always
surprised me that this seems to be such a difficult thing for some
interviewers to recognize. The BS is exposed when asking for more and more
detail about prior work and projects. What was the last project you worked on?
What was your role specifically? Were you responsible for selecting any
portions of the tech stack? If so, how did you make those decisions? What were
the determining factors? And on and on. As an interviewer, if I could not get
a good read on one's abilities in this way I'd question my qualifications to
be conducting the interview.

~~~
sokoloff
The BS artists might be 1 in 250 to 1 in 1000 candidates, so give it time and
you'll run into a skilled one sooner or later.

I have made several bad hires over 25 years and probably 100 direct hires and
500 total hires where I was on the panel. It happens. Most would have been
difficult to ferret out in an interview, because an interview is an inherently
spotty/lossy process.

The worst hire I ever made had, in retrospect, been given the (business case)
question ahead of time and had pre-written notes in his notepad. He
theatrically took careful notes while I was stating the business case problem,
asked if it was OK if he did some computations and composed his thoughts in
his notebook before presenting the case at the whiteboard. He did just that
and stood to deliver literally the most polished presentation on the case that
I have ever experienced. 5/5 definitely hire.

Shows up to the job and couldn't get water out of a boot if told the
instructions were printed on the bottom. Flames out in a few months and moves
on to his next gig. It was only after playing things back that I realized the
only way he could have pulled that off was to have pre-seeded his notebook
with the solution to the business case.

------
tzs
If I had to interview someone for a programming job, I think I'd try using
LeetCode problems, but _NOT_ as coding challenges. I'd pick a few problems
that the candidate and I both find somewhat interesting, and then for each do
three things.

First, we'd both read the problem, and talk about our understanding of what it
is asking for.

Second, we'd talk about algorithms to solve it, probably at a whiteboard. No
need for actual code, or even pseudocode. Anything that gets the ideas across
would be fine. Somewhere in here we'd also talk about what cases are tricky
and what we would need to do to make sure any test input we were to write
would cover them. I'd try to let the candidate drive this, but would provide
sufficient hints and nudges to get to a solution and not count needing that
against them--this is really just setup for the third part, which is the most
important part.

Finally, and most importantly, we'd go to the LeetCode discussion area for
that problem and look at solutions people have posted and review them
together. Many of the solutions will have mistakes, ranging from minor to
major, and trying to spot those together and talking about how to fix them
would, I think, give good insights into both the candidate's technical
abilities and how they work with others.

~~~
sethammons
I have seen my fair share of candidates who can talk just like you suggested,
but literally cannot put even simple solutions into code. Like, can't write a
for loop or an if-condition but could walk through a problem like you describe
and can even talk about tech trends.

~~~
ozzyman700
Personally I get intense panic seeing a person's face looking at me while I
try to avoid off by one errors.

It's all in the experience but that might be the other side to the situation
you are describing.

I am practicing a lot to be more comfortable but I still feel bad for those
people who interviewed me and ended up disappointed.

------
reallydontask
I'm currently working on revamping the way we do the first interview, which is
nothing more than a filter.

We currently ask mainly, let's face it, poor theoretical questions.

I want to ask more experience based questions.

so instead of:

Explain what a database index is

Ask:

Can you give us an example of a time you used a database index? What were you
trying to achieve? Could there have been a different solution to reach the
same outcome?

If the candidate doesn't have experience with databases that's fine we just
ignore this question, at least that's what I would like to do, whether I can
sell this is another story.

To be sure if the candidate has no database experience, no cloud experience
and no backend development experience then it's probably not going to work out
but we can try to be flexible about candidate's experience.

It's easy enough to learn what SOLID means but a lot harder to know when it's
a bad idea to use it or when it might be a good idea to compromise.

~~~
seanmcdirmid
I’ve been asked these kind of questions before....for a compiler job. I mean,
you can clearly see on my CV that I don’t do backend, cloud, or database, the
hiring manager is not interested in me for those things, yet their interview
process is so inflexible that these are the only questions that can be asked
during the interview (....and not one compiler question either).

~~~
reallydontask
The key is flexibility. As you say, there is little point in asking somebody
who is going to be working with compilers the best way of doing something with
React or Angular.

A guy I used to work with would walk through the technical skills section on
candidate's CV asking for knowledge level out of 10 and then ask questions
accordingly but that is trickier to do on an online platform (at least as far
as I'm aware)

~~~
pickle-wizard
I recently had a job interview where I was asked about skills on my resume.
Except on every question the scale would change.

For example. On a scale on 1 to 7 how do you rate your self on Linux Then, On
a scale of 1 to 9 how do you rate your self on AWS.

It was maddening and I could couldn't give an honest answer as I kept getting
confused. That is one of the many reasons I declined a second interview with
that company.

~~~
reallydontask
Why change the scale? that would've confused me too

I guess the interviewer thought the scale change would make you think harder
about your skill level ...

------
mountainofdeath
Everyone is forgetting why big companies do interviewing the way they do. It's
the same reason the entrance criteria to elite universities are they way they
are.

Last I read, Google has something like a thousand applicants for each
position, each level of filtering reduces the amount by an order of magnitude
for a position they may or may not fill so it becomes statistically harder
than being accepted to Harvard.

Likewise, people practice for these interviews harder than they do for college
entrance exams and work on saying the exact things the interviewers want to
hear. In essence, the filter is on this particular kind of "grinding" work
ethic.

------
jillesvangurp
As somebody hiring more regularly now, I can sympathize. I'm usually operating
on the notion that interviews are demonstrably not a very good way to select
people. They are pretty random. I tend to embrace this and focus on the big
picture: which is do I want to hire them.

So I have only two big topics in my head.

1) Verify that this person is competent by getting to talk about anything
remotely relevant. The job here is listening; not asking. If buzzwords come
up, ask follow up questions. If someone is a bull-shitter, it will show in
minutes. I have some generic questions that I can put in to keep the
conversation going but usually, I just focus on stuff on their CV that
interests me. Tell me more. Anything. What do you want in a job? Why?

2) Establishing whether I like the person enough for further collaboration.
Yes, this is super subjective. But the way this business works is that anyone
passing #1 you basically should hire unless you have a good reason not to. Not
liking them would be a red flag.

Most of the rest of the interview is selling them on the job and figuring out
whether that even remotely aligns with their expectations. This is a sales
pitch. As an interviewer, your job is getting the candidate enthusiastic about
working with you. If they are good, they'll have other offers lined up. In
other words, it is you the interviewer that needs to be nervous about whether
they will say yes; not the other way around.

This is the most important step in the interview and this is where you either
get somebody enthusiastic about working for you or disengaged. If that's the
case, don't hire but if they show eagerness, interest, etc. you basically try
to hire them.

It's not like we have a long list of candidates typically. So, decide quickly
and act with a sense of urgency.

When I'm interviewed, I think of it as a privilege for the wannabe employer.
You successfully got introduced to me by somebody I trust. We talked and I
liked you somehow. Now we are talking shop. Your job is to make me want to
work for you. Sell it to me. Make an effort. Don't waste my time with
bullshit. I'll talk to your HR after you convince me I'm not wasting my time;
not before.

------
jrjarrett
So these kinds of posts keep showing up.

How are interviews for not-software-engineers conducted? ie. how do you
interview for a business analyst role, or a sales and marketing role? I have
to assume that those roles suffer from the same sorts of issues a SE job does
-- that someone can talk a good game but not be able to perform in the role.

~~~
gwbas1c
Doctors have to go through a rather grueling licensing process. The job
interview is mostly about determining mutual interest.

Doctors also need to go through periodic re-credentialing.

To put it bluntly, when a doctor has credentials, you at least know that
they're competent; and more competent than 2-4 1-hour quizzes.

~~~
kod
Speaking as a licensed attorney, passing the bar does not mean that you're
competent.

~~~
jimbokun
Then how would you go about identifying a competent attorney?

~~~
kod
References and talking to them.

------
tombert
Years ago, I was interviewing, and they asked me a fairly typical "Design
Twitter" question.

I always hate these kinds of questions because it took Twitter 10 years to get
to where it is, and I'm certain they didn't design all of it in 15 minutes on
a whiteboard.

Anyway, I'm drawing little boxes and arrows, and when the subject of a DB
comes up, I ask "do you want availability or consistency", because I figured
that CAP theorem was part of the "gotchas" on this. The interviewer said "I
want both", to which I replied, kind of sheepishly, that you cannot have both.
We go back and forth, and eventually I pull up the CAP theorem wiki page on my
phone and he had to concede the point.

This is rare; usually when I know more than the interviewer, they double down
on their wrong ideas. I have several stories like that.

~~~
dennisgorelik
Did that interviewer hire you after admitting that you were right in pointing
out his mistake?

~~~
tombert
The company made me an offer, which I didn't accept, though for different
reasons, mostly with me having skepticism on the sustainability of the
company.

Joke's on me, I think; looks like the company is doing better than before, the
stock package they had might have made me about $400k.

------
jondubois
I think the point is that big corporations don't believe in the value and
depth of talent. They're not trying to find the world's top software
engineers; they just want to find enough good engineers to fill their quota.
What that means is that they don't care about depth. They don't care if the
candidate is a genius in their domain; they just want to hire people who can
reliably solve coding problems; that's it.

It's quantitative, not qualitative; it's not about how well the candidate can
solve problems - The 'if' is much more important to them than the 'how'.
Unfortunately, not many people have the ability to objectively measure the
quality of a technical solution, that's why they don't bother at all with the
'how'.

------
Nursie
Honestly these days I'm thinking that the best interview is going to be about
people's attitudes and opinions. e.g. I usually ask things like what's your
favourite source control system, branch technique etc? Why?

There's no right answer here, other than to show thought and understanding of
the engineering problems this is seeking to address.

Obviously there should be some domain/framework/language specific things in
here too. But the object is to gauge competence and experience level, and
thoughtfulness vs doctrine.

The 'practical' should take place on the job, give them a week and if they
aren't up to the task(s) at hand, say goodbye and move on.

------
metalgearsolid
I've helped hire 3 software engineers to both work with me and mentor me and
they were all failures.

First two hires quit after only a few weeks.

Third hire was temporarily successful. He eventually revealed himself to be
both a jerk and not very technically skilled, so I spoke to higher-ups to get
him removed.

My hiring strategy was designed to be simple and respectful. A simple, 20
minute assignment completed between phone screening and on-site. And 2 on-site
interviews. Despite the 3 failures, I still feel like it's a good strategy.
But evidence says otherwise!

~~~
esturk
You didn't even mention what those 3 interview questions are like which is the
whole point of this discussion. You made the conclusion with 3 data points. I
could just as easily make a conclusion about the common denominator of all
this which would t be fair to you.

~~~
metalgearsolid
I'm unsure why you think my anecdotes of failures hiring software engineers is
not relevant to a discussion on how to not hire software engineers. I think
you misread my comment, because drawing a conclusion on my hiring process from
3 data points is exactly what I'm _not_ doing.

------
codeulike
Get them to ask a question on stackoverflow without it being closed or put on
hold or marked as a duplicate.

~~~
collyw
While that is probably useful in its own way I doubt it would show whether
someone can write decent code or not.

~~~
codeulike
If they can pass this test they can solve any problem

------
jfasi
> How to check if a linked list has a loop? Does one N-dimensional box fit
> into another N-dimensional box? Can you swap two variables without a third
> one? How to find the shortest distance between two moving ships? Find all
> permutations of N elements doing only N-1 swaps?

> Those puzzles are fun to talk about and solutions to them can be very
> insightful. I used to enjoy lots of them reading Mathematical Recreations
> and Essays as a kid. Don’t take me wrong, they are fun.

> However, no matter how fun they are, they are merely anecdotes. The property
> of a puzzle is that you either know the answer to it or you don’t.

I disagree with how the author lumps these questions together. Questions like
"Find all permutations of N elements doing only N-1 swaps" are actual brain-
teasers and typically require a flash of insight and creativity beyond what
most people can do within a 45 minute interview. Questions like "Does one
N-dimensional box fit into another N-dimensional box" are algorithmically
challenging and can be approached from first principles and solved within an
interview. One question does not carry signal, the other does not, and by
categorizing them together the author suggests that neither are useful.

------
Lxr
Now I really want to know how I save myself before the candle burns through
the rope.

~~~
natosaichek
Spit on the candle. Grab the rope in your teeth and just hang on until rescue
comes. Lure another animal over with mating calls to distract / feed the lion.
Swing back and forth by wiggling your feet and neck at the appropriate rate to
swing yourself up onto the branch.

*note that it sorta doesn't matter because cats are notoriously good at climbing trees and likely wouldn't wait for you to fall.

------
brianpgordon
> The property of a puzzle is that you either know the answer to it or you
> don’t. It doesn’t tell you anything else. It has nothing to do with future
> performance, being smart, capable or anything else whatsoever. Knowing a
> particular answer does not mean you have an apparatus to solve real problems
> in a generic and predictable way. The only thing it tells you is that the
> person has been in a situation when someone shared a solution with him.
> Nothing more, nothing less. Just stop already.

Oh come on. It's true that people seeing the problem before is a major
confounding factor, but it sounds like the author is saying that _nobody ever_
solves the puzzle in the interview and it's a pure coin flip. That is
obviously not true.

The puzzle type questions probably aren't a great fit for startups, but
they're not meant to be. Big tech can afford the vast numbers of false
negatives that they produce. In return, they're able to effectively conduct IQ
tests of candidates without running afoul of the law.

------
autotune
As a recent candidate I've set my LinkedIn profile to actively searching and
have a highly in demand skill set in the SRE space with a decent amount of
experience in a booming city, so not technically full blown software engineer
but similar enough. Having gone through maybe 5 or 6 interviews in last couple
weeks of those interviews, _one_ company, just _one_ has had what I would
consider a reasonable interview process:

1) Take home assignment with extremely clear instructions directly related to
the job.

2) Discusses the results of the take home assignment over video conference
call, and/or in person, and actually asks specific details about it.

That is all I ask. Most of the other interviews either are all conversational
in nature, white boarding, or don't actually evaluate the take home when you
are done with it. My conclusion is nobody knows how to hire and maybe I should
switch to becoming a starving musician full time instead.

------
gwbas1c
Honestly, this article sounds like a rant.

Hiring is hard. A lot of interviewers aren't good at it. Every technique that
gets promoted has flaws.

We could be like doctors and have a grueling licensing process, and then
interviews that are mostly about finding mutual interest. But, I don't think
most of us like the idea of a licensing process.

------
dblooman
What i've noticed recently with interviewing candidates is some lack the
ability to work outside the way they work normally, especially in practical
tests.

Things like, "I usually work from home, so its too difficult to concentrate in
this meeting room", "I use Windows, so writing code on a Mac is really hard"
and the most common for some reason for why the technical exercise isn't
working "Intellij usually saves the file for me"

Practical interviews are difficult to get right on both sides, but from the
side of the candidate, I feel there has to be some ability to handle those
situations, under pressure, with confidence.

~~~
falsedan
Unless the IDE you use everyday is the whiteboard, these are all fine and
valid criticisms of your hiring tests. If you want to see real-world results,
give candidates real-world conditions (including their preferred
OS/IDE/workspace environment).

> _under pressure_

is this a common occurrence in your company? people expected to code well
under direct supervision and a strict short time limit?

~~~
ozzyman700
Hackerrank interviews done with video chat literally have a person's face
watching their screen which updates as you type. I had an hour to write a few
functions and the person interviewing had the ability to run the tests

~~~
vips7L
I hate hackerrank. The experience writing the code is terrible. You have to
scroll up and down the page to remember what they want you to do. It's
_barely_ a text editor and slows down how fast you can actually write the code
they want under the timelimit.

------
ticmasta
We ask a programming question that's harder than fizz buzz but not terribly
difficult. There's an opportunity to get the gist, but miss some edge cases
which leads to good conversations. When I go in to discuss the solution, I ask
how it went and we end up with three scenarios:

1) candidate is modest (it was pretty tricky but I think I got it) and they
did a good job

2) candidate is modest (it was tough I think I screwed X up..) and they made
some major mistakes

3) candidate says it was easy and totally blew it.

I've yet to have a candidate who said it was a breeze actually ace it.

------
johneke
Thank you for writing this. I really hope common sense prevails soon. I have
no idea how we got to the point where the "test" for a job has nothing to do
with the job. I think senior engineers and tech leads need to actively work to
kill this culture. I personally will never interview someone for my team by
using some random questions from the internet that have nothing to do with
what the candidate will work on. Again, great post

------
dvfjsdhgfv
So, how do you save yourself before candle burns the rope?

~~~
falsedan
sing Happy Birthday to the lion

~~~
codesnik
You're hired!

------
genezeta
Here's an idea for how to actually do a technical test (if you do want to do
one).

1\. You bring the candidate in to your office. You have their future desk
already available with computer and development environment already
functional. Pick a somewhat standard environment configuration.

2\. Have an exercise already prepared. Best option is not a "build this from
scratch" but have something that already works and needs some additional
feature. Something small that could be done in, at most, an hour. Another
option is two or three smaller tasks that together would take as long.

3\. You give the candidate _incomplete information_. You describe the task
clearly and in a mostly complete way, but leave out a number of details.

4\. Very clearly explain these things. One: You won't be on them; this is not
pair programming and they should feel at ease and free to do however they
want. But you _will_ be sitting in the next desk and you will be doing
something unimportant so they can -and should- ask you anything and all they
want. They can also use S.O. or whatever search service they want but you'd
prefer that they asked you first. Two: You won't be looking at their code
unless they want to show you. Three: they have _around_ one hour, but time
doesn't matter that much. If giving out more than a single task, indicate that
they won't be judged by how many they manage to finish.

5\. During that time, you focus on the questions they ask you. What they ask,
how they ask them, which problems they face, what things they do or don't
understand. This _is_ the key. This is what will tell you about how they
think, what things they know and which ones they don't. Keep an eye on them,
if they seem too quiet you can interrupt them with simple "how's it going?" or
"something wrong?", but don't push it too much so that you don't stress them.
You may even suggest a 5 minute break for a coffee/water half-way through if
you feel they might need it.

6\. The whole idea is to get them to do some task but more importantly to get
them to _talk_ about it. When they are done, or when enough time has gone by,
_don 't_ go over their code. Instead, ask them how it went, what they managed
to do, if they got stuck. If they got it running, they can run it. If they
want, they can show you the code or part of it. but you don't need to focus on
that. Focus on their talk.

7\. Finally, do offer them the _option_ of showing the code. But then, get
them to show it and explain it. Don't just go over it yourself.

8\. The task(s) should be adequate and reasonable for the role, of course. But
try to lean on the easier side more than on the harder one. And remember: do
leave _some_ information out. The task should be clearly understood but not
finely detailed so that they will need to ask and maybe even make some
decisions. (You can make them have to decide something by giving them more
than one option as answer to some question.)

~~~
zimpenfish
In all my years of interviewing (~25), I've only had this happen once - I got
sat in front of an internet connected laptop, given a perfectly sensible task,
and left alone for half an hour.

Most of the time it's "solve this already thoroughly solved problem in your
own time but with {one hand in a blender, whilst you're on fire, without using
any variables}" or some such bullshit.

~~~
arethuza
About the same - I had one 'interview' where I had to write a client and
server in C++ that would allow clients to register network MAC addresses with
the server along with some associated data and then retrieve it at a later
time.

Took me a couple of hours, interviewer said my code wasn't particularly
"object oriented" but I got the job.

The irony of this was it was for a Director of Engineering job where I didn't
do any coding! :-)

------
tfont
I agree and disagree with a lot of points.

Most importantly, writing programs on whiteboards. I hate this, but it's an
insightful way to measure the individuals thinking processing, decision-making
skills, and communications skills.

Expect them to fail and see how they handle the situation and themselves.

------
revskill
To me, a good software engineer is the one who could figure out the issues. In
most of case, it's not about the solution. It's about identifying the issue is
the hardest part of the job.

------
blackbrokkoli
Maybe of topic, but: I find it interesting that the author lists user
experience in his "what I would like to talk about" list yet uses super bright
yellow as _background_.

~~~
theelous3
Read it on mobile, found it surprisingly nice. On a large monitor I can see it
being a bit annoying.

------
Circuits
At my company we don't bother with specific problems. When we ask a candidate:
"If you were asked to build x program how would you go about it", the answer
we are looking for is along these lines: "I would go online and find someone
who has already done the problem and replicate/alter it to fit my needs". The
majority of the questions we ask are like: "Where do you see yourself in 5
years.", "What does our company do?", "Present us with a time when you had to
overcome a challenge and failed.". If your going to work with someone then its
best you know that they are capable of learning. After all, a degree isn't
about proving you know something, it's about proving you have the ability to
learn and fight for that knowledge when necessary. It proves you have drive
and direction in your life; important qualities in a candidate.

~~~
PopeDotNinja
I just started using an ToDo app called "Remember The Milk", and it works for
me so far. The next time I get an interview question that asks me to make a
ToDo app, I'll be tempted to respond with "I already have one that I like. Why
don't you try it, and if you don't like it, tell me why." I doubt that would
go over well, but maybe it would. Who knows!

~~~
Circuits
It depends on how the question is phrased. If they hand you a white board and
say: "Show us the code" then you are going to have to build something.
However, if they ask you something like: "If we asked you to build a ToDo app
that solves x problem, how would you do it?" Then it's reasonable to assume
they are open to more solutions than you jumping up and grabbing a marker.
Being able to distinguish those differences is also important.

