
“But didn't you write an embedded OS?” - jimmies
http://www.tnhh.net/posts/but-didnt-you-write-an-embedded-os.html
======
rambossa
I hate the Cracking the Coding Interview/Leetcode style... studying for these
type of interviews is annoying. Trying to find a good video on youtube, where
they aren't just naively coding up the bruteForce->optimal possible solutions,
especially is irritating. It is literally a landscape of college kids with
thousands of viewers who treat these interviews like a standardized test (SAT,
GMAT). Even the author of the book produces videos with very little insight or
meaningful content.

"Find all the subsets in a set that add up to sum" \-- "Okay for this we will
use the sliding window technique and here is how it is done" \-- WTF is this.
I get that they want to see problem-solving skills, but this is on a different
level requiring the interviewee to have studied and knowledge of the
technique, otherwise we are basically trying to develop efficient algorithms
from scratch and in little time. --This makes sense for college interviewees
who have only studied the past 4 years, but for a professional with
experience, why is this adequate??

Does algorithmic programming matter?-- still yes. But the way it is
interviewed is absurd and inadequate. I had a production service centered
around the stable-roommate-problem. It took me a week or two (mostly research)
to develop something out and fit it into our codebase. It then took 1-3 more
weeks to actually make it work for us and cover edge cases (i.e. Irving's algo
quits after instability -- this isnt an option in the real-world). I read much
material on the subject, other's code, had many deep-thinking sessions where I
was mostly in my head, wrote unreadable scratch on paper, collab-whiteboarded
(sometimes arguing), tested&failed PoCs, and had many breaks in-between it
all. How successful was that project?--very, did I need to know and study
techniques with lacking/meaningless basis to do it--no.

~~~
zawerf
Recall when you first learned how to program. Something as trivial as
iterating through a list requires some thought. What is the syntax for a "for"
loop? Do you start with i = 0 or i = 1? Should you end at i < n or i <= n? At
some point you stop thinking about it and write "for (int i = 0; i < n; i++)"
instinctively. You can now solve harder problems that require iterating
through a list without thinking about it.

All of algorithms and programming is like this. You unlock harder problems as
you learn more problem solving building blocks (whether it's an algorithm, a
software design pattern, or some API call). A programmer is someone who can
learn these on the fly for any problem of any domain. An effective programmer
is someone who has a large cache preloaded with these building blocks already.

In that sense I find leetcode style problems to be very fair. They are meant
to be solvable in under an hour without thinking once cached into muscle
memory. All it is testing is whether you're _capable_ of becoming an effective
programmer in some agnostic domain. All you need to do is warm your cache with
a small number of standard patterns (which might even be useful for real
work). It does suck that even the good programmers need a few weeks to warm
their cache. But it weeds out the fakers who can't do it given any amount of
time.

~~~
pavlov
_> In that sense I find leetcode style problems to be very fair. [...] It does
suck that even the good programmers need a few weeks to warm their cache. But
it weeds out the fakers who can't do it given any amount of time._

It also weeds out people who have better things to do than cram two weeks for
your pretend-meritocratic little exam.

How about requiring that candidates comment their code using quotes from
Classical Chinese poetry? They are proven timeless classics that an
intelligent person can apply to any situation. This test would weed out the
fakers who can't refresh their caches while also honoring an ancient tradition
of stupid job interviews, the Chinese imperial examination.

~~~
jaredklewis
> It also weeds out people who have better things to do than cram two weeks
> for your pretend-meritocratic little exam.

All interviewing techniques have to make precision-recall style trade offs.
The mere fact that an interview method has false negatives surely doesn't
disqualify it. It has to be compared against the available alternatives. What
are the alternatives?

\- White boarding? Algorithmic knowledge is often tangential to the actual
job.

\- Take home assignments/mini projects? High relevance to job, but in my
experience takes the most time for the candidate.

\- Trial period? Most people can't just drop everything they are doing to come
hang out at your company.

\- Conversational interview. Like white-boarding, tangential to actual job. My
experience on the interviewing side is that it is often hard to learn much
about the candidate.

\- Read their code on github / blog. Lots of candidates don't have the time or
inclination to code outside of work.

\- Something else?

So what's your preference? I've done them all and find them all to be lacking
in different ways.

> How about requiring that candiates comment their code using quotes from
> Classical Chinese poetry? They are proven timeless classics that an
> intelligent person can apply to any situation. This test would weed out the
> fakers who can't refresh their caches while also honoring an ancient
> tradition of stupid job interviews, the Chinese imperial examination.

This seems like the fallacy of grey to me [1]. When hiring, for example, a web
developer, yes, algorithmic knowledge is a somewhat arbitrary indicator to
use, but it is not completely arbitrary. Not all things are equally unlike.

If I were hiring for a basketball team, and had to choose between two
candidates neither of whom had experience playing basketball and were alike in
all ways except that one was an avid soccer player and one was equally fervent
about pottery, I would choose the soccer player. The logic of course being
basketball and soccer have more in common (athleticism at the least) than
basketball and pottery.

Likewise, algorithmic thinking shares some common points with almost any kind
of engineering task.

Interviewing is just a hard problem where you are trying to predict future
performance based on a few hours worth of data. I don't think most of the
popular the techniques we have are obviously stupid. Companies have strong
incentives to make hiring efficient, but there just isn't a lot of low hanging
fruit. Of course there are the occasional ego maniac interviewers, but an ego-
maniac is going to be able to ruin any type of interview. Let't not throw out
the baby with the bathwater.

1\. [https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-
fallac...](https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallacy-of-
gray)

~~~
pavlov
_> If I were hiring for a basketball team, and had to choose between two
candidates neither of whom had experience playing basketball and were alike in
all ways except that one was an avid soccer player and one was equally fervent
about pottery, I would choose the soccer player._

That’s not at all what happens in programming interviews that use algorithmic
puzzles.

You have candidates who already have a professional track record in
basketball, and instead of focusing on that profile and whether it’s a good
fit for your team, you give them a timed soccer workout because it’s somehow a
more objective measure of athletic ability.

Any basketball team that hires like that wouldn’t survive for long. The quiz
interview format in the tech industry is a form of “anti-Moneyball”. It works
for the SV giants because they have an enormous supply of candidates and they
need generic competence that can be shuffled around. Smaller companies would
do much better to hire for the actual role, not for “Cracking the code
interview” memorization performance.

~~~
jaredklewis
The basketball was just a metaphor to explain relative similarity. Obviously
hiring for an actual basketball team is a very different set of challenges as
they literally have hundreds of hours of video taped performance history to
evaluate before the candidate even walks in the door, and at lower levels,
asking candidates to spend several days “trying out” is not considered
onerous. But I would still argue that performance on programming puzzles much
more closely correlates to programming job performance than knowledge of
Chinese poetry.

As for hiring people based on their experience profile, it’s great of course
in the case of candidates with lots of open source contributions and such, but
this has the issue of ignoring the majority of candidates which don’t
contribute to open source. Should being an os contributor be a hard
requirement?

But if you are suggesting that a resume with the words “5 years experience web
development at company x” means anything, I’m a little incredulous. I worked
with people that claimed to have far more experience than that and struggled
horribly with even the most basic tasks.

Finally, a little tangential, but memorization gets a lot of flack for being a
“stupid” skill. My experience is that it is nearly impossible for adults to
memorize something like Chinese by poetry “by rote.” Indeed if you try
memorizing some poetry I think you’ll find that it really is a very fulfilling
and creative process.

------
humanrebar
> And I see the same trend in Machine learning, Big data, AI, Cryptocurrency,
> Internet of Things, Social networks, Decentralized networks, etc. Everything
> in life, however trivial or hard, is a nail that can be solved with those
> fancy hammers. So we can have a tablet juxtaposed on a fridge, a bluetooth
> speaker integrated to a salt shaker, a subscription model for juicers, and
> machine learning for all kinds of social problems.

I'm frustrated by this as well. I see these days, especially, junior engineers
excited about machine learning analyzing data sets that could be tackled
easily with learning the problem space and excel or a jupyter notebook. 90% of
the work in analysis problem is, usually, identifying data sources and
possibly curating the records to a workable data set. So it really doesn't
help much to apply ML off the bat. If normal regression and human inspection
don't help, maybe then you can iterate on the problem and try some ML
approaches.

So why are junior engineers trained to think this way? Are their professors
and guest lecturers excited about these approaches and teaching the students
about their favorite hammers?

~~~
currymj
they want to get well-paid, high prestige jobs using machine learning.

whereas doing the exact same task with a regression in Excel turns it into
low-prestige clerical work.

i think they’re acting pretty rationally once you consider their own
incentives. (plus of course, the general cultural perception that machine
learning is cool, smart, and cutting edge must rub off on them too and how
they perceive themselves.)

~~~
gaius
I am not looking to move right now but I still have a couple of job searches
saved from before and _everything_ it seems is data science, machine learning,
big data etc now. Even jobs that are very obviously Excel or similar and
paying accordingly.

~~~
rjsw
It is also difficult to get any funding or interest in what I would call
"medium data".

~~~
gaius
I suspect a smart engineer can make the vast majority of big data problems fit
in memory by appropriate filtering and pre-processing but you’d never get your
purchase order for that 200-node Hadoop cluster approved if you admitted it...

~~~
currymj
“It takes a big man to admit his data is small.”

------
zdw
Reminds me of this article, which recounts a book by Knuth where the reviewer
comes up with an 6 command shell pipeline equivalent to one of the multi-page
examples:

[http://www.leancrew.com/all-this/2011/12/more-shell-less-
egg...](http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/)

~~~
samatman
That exchange never sat right with me. I feel, and I hope Dr. Knuth would
agree, that literate programming is a good choice for writing `uniq`, that the
problem domain was chosen for didactic reasons.

In effect, he chose to show off parts of several programs, rather than
finishing one. The intention was to teach.

That shell script was a tour de force at the time, showing off the Unix Way of
small, sharp, composable tools. What Dr. Knuth was (and is) saying: write
those small, sharp tools in a literate manner. A real missed opportunity.

~~~
svat
Indeed, yes exactly. And in fact, later Knuth wrote `wc` (one of the shell
programs in the pipeline) as a literate program, and showed that it was better
as a result than the one that came with Unix.

------
bluedino
How’s the old interview question go?

 _Using the programming language of your choice, sort the strings in this file
and remove duplicates. You have 30 minutes._

    
    
        sort foo | uniq

~~~
flatline
I always give props to people who give a solution like this because sometimes
that is the right thing to do and it acknowledges that we are dealing with a
toy problem with a ready solution. And I think that’s what the interviewer in
this post failed to do. But in reality we may have a not-dissimilar problem
that doeasnt deal with strings and is just a bit more complicated so you can’t
just take a bash command or genetic function off the shelf and have it work.
You’re going to have to write some code, it’s going to take a little thought,
and your solution can’t be O(n^2) when we throw ten million elements at it.

I’ve worked with engineers who are competent programmers but just can’t handle
these problems when they come up in practice. If the job _actually requires_
it, I don’t know of a better way in the context of an interview to determine
if a person is that type of programmer than with a few toy problems and a
solution in code. You may miss some good people because the format is
suboptimal, but you _will_ weed out the people who just don’t have the
theoretical and practical background to solve this particular type of problem.

~~~
new299
I'm not certain that it's true that you "will weed out the people" who can't
solve algorithmic problems. There are a relatively small number of algorithmic
problems, that are simplest enough to be asked and solved in an interview
context. People now study these types of problems for months when preparing
for interviews...

I think there are better ways of doing things than the standard X interviews
of 1 hour. One method that works well is hiring people for short term
contracts (few days) and seeing how they work with the team on real problems.

~~~
hn_throwaway_99
> One method that works well is hiring people for short term contracts (few
> days) and seeing how they work with the team on real problems.

The problem is that most really great people, who are in high demand, won't
put up with this because they know they can get someone else to hire them with
less hassle. Your approach ends up weeding out your best candidates.

~~~
new299
Google and Amazon (and I assume Facebook) interviews are already a large and
uncompensated investment of time for the interviewee (up to several days). So
I don't see it has much different.

I can see that there are scenarios where it might not work, for example if
non-competes are in place and the industry is similar. But in most cases I
think there's enough flexibility to make it practical.

------
bsenftner
For those of us who have written an embedded OS in C, the situation is no
different. The white board questions are crap like "How is React different
from other JS frameworks?" Whaaaaat?

~~~
bartread
To me those sorts of questions are terrible interview questions. I'm looking
for a few things when I hire:

\- What are you like as a human being? Can we work together?

\- Can you code? [1]

\- Are you willing, in fact keen, and able to learn?

\- Can you see beyond the technical issues?

 _[1] This tends to be frowned on in some circles, but given the bi-modal
distribution of developer skill, leading to plenty of smart people who aren 't
good programmers, in my view it's of critical importance. Generally asking
somebody to solve a relatively simple problem in a language they're
comfortable with and that is also similar to something we use, or pairing
together on a problem, works well here. What I don't care about is
understanding of specific frameworks or technologies: if you're a good dev you
can learn those, and we're happy to invest and give you the time to do so._

~~~
justherefortart
I just ask them to talk about the projects they've worked on recently and any
issues that arose, and how they dealt with them.

If they can communicate clearly what happened. I've never had that fail me as
far as them being "technical enough" for the position as no one knows
everything, can you figure it out is the bigger issue.

Then I typically just have them tell me about what they liked and disliked at
prior jobs and what environment they would like to work in.

After that, what are their goals for their career and how can we help them
achieve them.

If the interviewee can demonstrate they have anything in those areas, I've
never had an issue with someone I've hired. I don't care if you can program
everything walking in the door. If you've got a can-do attitude, we can work
together to get you up to speed on our crap code and the whys behind it.

------
im_down_w_otp
Given how much of software development itself is often little more than cargo
culting w/ strong doses of guess & check stirred in, I suppose it makes sense
that hiring/interview practices would mirror that, but it's still depressing
everytime I come across stories like this one.

It doesn't have to be like this.

I don't hire people this way because I've never seen it produce good results,
and I have to hire esoteric skillsets for a challenging problem, and without
the time or budget that will forgive making bad hires.

------
_Donny
I understand that the article is about how many developers are inclined to use
wrong "hammers" for certain tasks.

However, it also makes me think about how we actually code. At my university,
we learn to sort files, parse data-structures, model various data formats,
etc.

But in most UNIX systems, we already have the basic building blocks in the
form of simple programs that do one thing, very well. Will programming ever
evolve from programming languages to more complex building blocks in the form
of programs combined with pipes in the bash terminal?

~~~
TeMPOraL
> _Will programming ever evolve from programming languages to more complex
> building blocks in the form of programs combined with pipes in the bash
> terminal?_

Fundamentally, UNIX "programs combined with pipes" are equivalent to function
calls.

    
    
      sort foo | uniq
    

is equivalent to

    
    
      uniq(sort(foo));
    

Shell is nothing but a programming language/environment optimized for fast
input and immediate, stateful execution. If you seek evolution of programming
to higher levels of abstraction, this isn't the place. Command line interfaces
work at the same abstraction level as regular programming in a high-level
language.

------
andrewstuart
The only sound recruiting advice is Joel's, which remains true today:

Hire people who are smart and get things done.

The interview questions to determine that go something like:

"List out your top achievements in programming"

"Explain each of them to us in as much detail as you possibly can"

I'd look for enthusiasm for this particular job too, assuming they have had
time to fully understand it and give it some thought.

------
jernfrost
Sitting on the other side of an interview, I was so annoyed with the guy I was
doing the interview with because he insisted on these algorithm challenges. I
told him these tasks are bullshit, because the job we do doesn't involve
coding algorithms EVER.

I wanted to focus on the ability to read messed up code and figure out what it
roughly does and how to improve it.

Turned out we were both kind of wrong, although I would claim my co-worker was
way more wrong than me. Our candidates pretty much failed all these algorithm
questions. And when my co-worker tried to help it turned out that he didn't
have a proper grasp of the problems we presented either.

My reading code test didn't work very well either, because these test subjects
were fresh out of college and had little experience in reading larger code
bases, refactoring and dealing with software engineering problems. Like most
people in college they had mostly dealt with toy sized programs.

So in the end what proved the best guide was plain old boring interview
questions. Our interview was largely a failure but we hired the programmer on
a hunch anyway based on her explanation of some theoretical subjects.

It turned out that she worked out just fine despite failing pretty much all
the tests we had made. That is because a lot of development these days is more
about persistence, motivation and ability to google. She was practical, eager
to find solutions and eager to google and that made her get stuff done.

~~~
bsder
> That is because a lot of development these days is more about persistence

This is true of most technical endeavors ...

------
jknoepfler
I'm honestly tired of programmers complaining about interviews. I don't think
the whiteboard blitz is a good gauge of an employee, either, but I don't know
of any good "test" of a potential coworker other than working with them.

One thing I think people wildly underestimate is how aware the interviewer is
of the inadequacies of parts of the process. I will ask basic programming
questions for the same reason I write unit tests. Weed out obviously broken
candidates with really easy questions. But beyond that, I need people with
common sense and a strong sense of professional ownership. I need engineers
with spines. I need people who tell me what they think needs to be done, not
people who are going to sit in their cubical complaining about how crappy the
interview process is. I need people who learn quickly, not people who will be
paralyzed by code smell or new tech. I need people who can jump into
management roles to fill in gaps because they get how things work and want the
team to get shit done.

If you don't like the process, fix it yourself on your team. Do better. Teach
others. Believe it or not, lots of people have gone down the same rabbit hole,
and your "crappy interviewer" is likely one of them.

~~~
scarface74
_I 'm honestly tired of programmers complaining about interviews. I don't
think the whiteboard blitz is a good gauge of an employee, either, but I don't
know of any good "test" of a potential coworker other than working with them_

That's the answer - "you work with them".

I create a simple version of a real world class that we have worked on. Each
method has comments on what the code is suppose to do and a bunch of failing
unit tests and we pair program.

The first set of unit tests are relatively easy. I then add a second set of
requirements with a second set of unit tests. They have to modify the code to
pass the 2nd set of unit tests without breaking the first.

But as far as "going down the rabbit hole", I've never gone down that rabbit
hole of algorithm type tests. I was drilled on C in an interview in 1999
because they were doing a lot of hard core C work (I stayed on that job until
2008). But since then, most of my interviews have either consisted of the
sitting down at a computer and solving problems type or just drawing on the
board and explaining architecture.

Even though I'm very much hands on, at this point most companies hire me more
to help them with architectural issues than just as another coder. My salary
requirements filter the just another developer type roles out.

No, I'm not bragging about how much I make. I'm still only making the median
for a senior software Engineer/architect for my market - if the salary surveys
and my anecdotal experience is accurate.

------
twblalock
In defense of the interviewer, if somebody told me they wrote an OS for the
Raspberry Pi I would assume they wrote it mostly in C, not mostly in Bash.

~~~
aw3c2
> I made an distro for the Raspberry Pi called Crankshaft

Someone who picks up that info and turns it into interview material should be
well aware about the difference between making a distribution and writing an
OS!

~~~
PrimHelios
Not to mention that since the interviewer now has a name for said distro, they
should have looked it up and found what language it was written in.

------
mmjaa
I think that whats missing in this assessment of HR these days, is that
interviews are just as much an opportunity for the prospective employee to
evaluate their potential new employer, as it is the other way around - only,
we're seriously NOT used to thinking in these kinds of terms.

I've been programming since the 70's, and have built systems and subsystems
that are still up and running around the world. If you logged onto an ISP in
the 90's and early 00's, chances are you were going through a code-path that I
was responsible for .. if you took a train in any one of 38 different
countries in the world, in the last 15 years, chances are your life is being
protected by code for which I was once responsible. I've done a lot of crazy
shit; I've done a lot of cool stuff... I say this only to indicate that I'm no
newbie when it comes to software systems engineering, and all it entails: I've
shipped to tens of millions of people, and I've shipped to a small, localised
group. Point is, I've shipped, yo.

A few years ago I went to a job interview at a local game development company,
since I have a high interest in game engines and have even built a few of them
myself, as well as published a few games over the years. I thought the
interview was going well, and at first I hit it off just great with the guys
doing the interview .. but then as they started pulling in more and more other
engineers to meet and greet, and ask questions, I started to get a feel that I
really didn't want to work at this place.

Mid-interview, I felt like I should just stand up, say "sorry guys, you're not
a good fit for me", and left... but instead I decided to sit through the
interview. This was a big mistake - they came with the inevitable whiteboard
questions, and so on. So, I flunked them all - not because I couldn't work out
the A* algorithm on the board, but because I really lost interest mid-
interview.

It was only a day or so afterwards, having a bit of retrospective rumination
time, that I realised that I just really didn't want to work with those guys.
They rubbed me up the wrong way, and there was just something about their
culture that I didn't feel for .. well, I should've just said something. I
should've said "well, you guys have a great company (it seems), but I'm seeing
all sorts of warning signs in this interview, so I think I'll just pass on
this opportunity - and thanks!".

But instead, I stuck around and ended up just degrading myself with stupid
responses to their requests. I didn't really feel like I was in power, or had
any control - but honestly, I did. I really could have just stood up and said
"well, that last guy you brought in was a bit of a wanker, and I don't want to
work in an environment of wankers, so thanks for the opportunity but no
thanks"..

I think this is a real cultural dilemma. We, builders of technology, should
really acknowledge our value, and place it a lot higher than the current HR-
infected job market implies. Its a double-edged sword of course - nobody wants
to be known as the guy who shits on this interview companies - but on the
other hand, why do we put up with such imbalance?

EDIT: Just wanted to add that this particular line of the article resonated
with me: _' He asked, "But didn't you write an embedded OS?".'_. That, right
there, is a sign that the interviewer has a very, very poor understanding of
the subject, and the talent should just get up and leave. I wonder how many of
us overlook this fact in our interviews, out of desperation?

~~~
inetsee
I interviewed once for a job with a defense contractor. Mid-way through the
interview I was told that if they decided to give me the job I could expect to
work 60 hours a week for the next 18 months without getting paid any overtime.
I didn't come out and say so, but I'm sure the interviewer could tell that I
wouldn't accept an offer if it was forthcoming.

In retrospect, I think I should have said "Thank you for spending the time to
talk to me, I don't want to waste any more of our time", and left.

~~~
gaius
_I was told that if they decided to give me the job I could expect to work 60
hours a week for the next 18 months without getting paid any overtime_

I’ll wager whoever said that was a decent guy who liked you and decided to do
you a favour.

------
103e
"Invert a binary tree on a whiteboard" I wonder if you get any points for
turning the board upside down.

------
HumanDrivenDev
> If his tech model turns out to be relatively successful, a medium-sized
> company in tech will be able to easily copy his model and out-compete him

Does this happen all the time and we don't realise it due to survivorship
bias? And if so, how do we account for the successful stories that started
from the bottom up and became medium-sized companies themselves?

------
a1369209993
> "I can do it in two commands chained by a pipe in bash."

> any programming language I like

I choose Bash.

~~~
paulddraper
Probably depends on what the "commands" are.

You could also do it with two Node.js functions (from npm packages).

The presumption is that the available library is limited, though exactly how
limited depends on the interviewer.

Plenty of times I've chosen a language because of a particular function in its
standard library, only to be told that function can't be used.

------
lucio
>I don't intend to write this post to bash the interviewer

pun, intended?

------
daixtr
So I said, iL call the snmp API to read the data. Then he said, "no, you need
to read the bin file to read the data". I thought, what an idiot he is. I lost
respect, lost faith. Little knowledge is a dangerous thing.

