GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-26) - page 1 of 10
 
___________________________________________________________________
Technical and non-technical tips for rocking your coding interview
124 points by duck
https://github.com/yangshun/tech-interview-handbook?utm_campaign...
___________________________________________________________________
 
Waterluvian - 2 hours ago
What I'd love tips for, is how to politely and professionally
protest certain interview styles. I want to know how to say, "sure
here's how to implement foo but I also want to express that a focus
on this coding trivia is distracting from the skills I feel make me
an asset..."Maybe what I'm asking is tips on how to steer an
interview.  One of the reasons I wouldn't even consider a tech
giant interview is that I feel like I'm just one of many cattle
being processed through a long gauntlet of nonsense that distils me
down to quantifiable traits rather than who I am.
 
  watwut - 2 hours ago
  It is only after you worked with someone lazy or barely capable
  of foo who charizma-around-company-pong-table his way to staying
  in company and being treated as genius by those who don't work
  directly with him that you appreciate those simple exercises.
 
  IncRnd - 28 minutes ago
  How to steer the interview is to be honest and to talk."That's a
  cool problem.  I'm curious though - I didn't see that on the job
  description.  I'm not expert on that, and I didn't bone up on
  that last night. (ha ha everyone laughs)I can step through it if
  you want, but it would help me if I knew why you asked about
  this.  If you're looking to understand how I solve problems,
  that's okay, I'll muddle my way through it and ask if I need any
  clarifications."They'll tell you.  Interviewers often hold
  similar views to the candidates, but may be asking for a
  different reason than you think.
 
  SomeStupidPoint - 2 hours ago
  An approach is to proactively bring up interesting aspects of the
  problem yourself -- eg, the last time I was writing example code
  on the board, I spent most of the time talking about where hooks
  to add more features would go or algorithmic complexity/edge
  cases I encounter as I try to implement a solution.If you're
  focusing on the trivia, you're probably too focused on the code
  and not on solving the problem -- my experience tends to be that
  there's at least one or two interesting edge cases you encounter
  if you try the naive approach, and those are generally what the
  interviewer wants to discuss. The reason is that discovering edge
  cases in requirements and solving them is what a lot of the job
  is, and so how you approach that matters (and to an extent, more
  than if your code on the board is "correct").Another approach is
  to extend the problem by asking clarifying questions -- if
  there's something unspecified that might influence your design,
  ask about it and tell the interviewer why it matters. Again, this
  generally is more what they care about than the details of the
  coding.Finally, if those skills make you an asset -- why not
  apply them to the question? Even tangentially by talking about
  how you would (if you had more time/were doing a real
  assignment).Coding on the white board is more about the journey
  than the coding, assuming you can write vaguely correct code.
  (Though writing on a whiteboard is definitely a skill you have to
  practice.)
 
  ebiester - 2 hours ago
  In our interview, we have people from 4 different departments who
  will talk with the candidate, as well as the team (who is there
  for the coding portion.)I honestly don't want to have to test if
  someone can handle a simple algorithm. (I'm not talking about
  anything crazy here, mind you.) Can they read code? Can they
  think about how to test?I've seen faked code samples, and our
  test has a half dozen answers on github.I want to just assume
  that anybody with five years of programming experience can code,
  but I've worked alongside enough counterexamples that I know I
  can't assume that.That said, I'd really rather not have to deal
  with it as a candidate or as an interviewer.
 
    [deleted]
 
  misanthropic - 2 hours ago
  Well you can always say that you're not comfortable coding during
  interview, and propose to look at your github instead...
 
  pklausler - 2 hours ago
  When I ask a straightforward problem during a technical
  interview, I'm trying to ensure that the human before me is
  actually capable of solving the straightforward problem.  You're
  free to respond any way that you like, but if your response
  doesn't actually include a solution that demonstrates the
  capability I'm testing for, I'm not sure that I'm going to be
  able to distinguish you from the ~50% of interview subjects that
  HR puts before me that have no idea whatsoever how to program a
  computer.I don't even ask softball questions.  Mine are more like
  tee-ball questions.  Too often, the tee pitches a perfect game.
 
    rurounijones - 1 hours ago
    Out of curiosity. Would you still ask these questions if the
    candidate has a github/gotlab/whatever profile with X
    repositories where they are the main / only contributor? Could
    you explain why yes / no and what the specifics would be?
    (Volume? Complexity? Commit history? )
 
      Jach - 1 hours ago
      I wish more interviewers would look at helpfully included
      links to public code... Didn't happen (or at least wasn't
      brought up) last time I applied at places. On the other side
      as an interviewer, I'm lucky that I haven't yet done a phone
      screen with an outright failure of my tee-ball question
      (returning true if input positive int is even), though when I
      see if they can do it in different ways there have been
      flounders, but I still ask it independent of public code
      since I hear so many stories like parent's of utter failure.
      Depending on the contents of the public code (not so much its
      size) I may then drop some followup sections (I do a slight
      variant of https://sites.google.com/site/steveyegge2/five-
      essential-pho... to mainly test presence of areas of
      knowledge, details can be googled) and make things more
      informal with some time to make sure they actually wrote
      their public code.
 
      pklausler - 1 hours ago
      I absolutely do.  I can't assume that the person before me is
      the person who actually wrote the code on github.
 
        [deleted]
 
        Vendan - 59 minutes ago
        I think you'd get more value out of talking with them about
        those repos, and the process of building them, design
        choices, then any silly question like "how would you design
        a database".  Of course, that would also mean you'd have to
        actually put more then a few minutes into prep for the
        candidate's interview...
 
          rabidrat - 18 minutes ago
          While I agree with you for the most part, many companies
          want a "standardized" interview process, for both
          diversity and CYA reasons.  Tailoring the interview to
          the candidate is actually illegal in certain
          organizations (like government), as it has large
          potential for abuse.
 
  [deleted]
 
  sabman83 - 2 hours ago
  A somewhat related experience I had with a company that
  advertised proudly that they don't do live coding tests. They had
  a take-home exercise which I did very well and I was scheduled
  for a phone interview later. I was expecting it to be more around
  system design, behavioral questions but to my surprise it was a
  live coding test.After the interview was done I questioned the
  person why have another coding test. He said it was to test on
  different areas of programming. I later messaged the VP/CTO who
  wrote the blog post on not having live coding test. The person
  apologized for the experience and said that the team I
  interviewed for did not come under engineering org. It was a
  frustrating experience but at least the person responded
  positively.
 
  mylons - 1 hours ago
  steering an interview is all about steering the human(s) giving
  the interview.real life example: an MIT PhD in distributed
  computing walks into the room, looking extremely tired from
  interviewing people like me. I can tell this is going to be rough
  unless I'm controlling the conversation and we have a good
  rapport.He's wearing a Fender shirt. I have played guitar a bit.
  After he introduces himself and I myself I open with, "Oh nice
  shirt. I assume you play some guitar?" and there goes 20 minutes
  of the interview talking about guitars.So long as I don't
  completely bomb the technical aspect I've left this person with a
  positive and relatable experience.
 
  thesmallestcat - 2 hours ago
  A warning: If you take this approach, you'd better be a
  programming god, because you're going to be the guy who was too
  good to knock out a simple coding problem. Every off-by-one error
  you commit on the job will raise an eyebrow. People will wonder,
  does this guy want to be an engineer or something else? Why
  couldn't he rip through that problem and teach _us_ a thing or
  two on the way? Another thing is you're basically coming in and
  saying "your interview process is wrong". If you're being
  interviewed as a manager or a lead, you can afford that risk. If
  not, be careful, because many people, myself included, don't want
  to work with somebody who cannot focus on the task at hand and
  feels the need to question things that have clearly been thought
  out ahead of time.
 
    Swizec - 1 hours ago
    > feels the need to question thingsCall me old fashioned, but I
    thought that was my job as an engineer. To question things and
    find ways to fix/improve them.Am I wrong?
 
    programmarchy - 2 hours ago
    > don't want to work with somebody who cannot focus on the task
    at hand and feels the need to question things that have clearly
    been thought out ahead of timeThis seems a little too general
    to me. Many things are not clearly thought out, and I'd rather
    work with people who can recognize when that is the case and
    communicate well enough to correct the course. A big part of
    successful development in my experience is knowing when not to
    implement things, or having foresight to implement things in a
    better way. Working with people who just do what they're told
    is often a huge waste of time.
 
    Karunamon - 57 minutes ago
    >...and feels the need to question things that have clearly
    been thought out ahead of time.I only take issue with this.
    Many things in organizations that have been through explosive
    growth (and sometimes others) are that way because for no
    reason in particular and amount to bandaids upon bandaids
    because nobody's ever had a chance to actually look at the
    process. It very well might suck. Questioning it is the first
    step in making it not suck.That said, as an interviewee is
    probably not the right time to do so. You're an outsider, you
    have very little rapport or relatability compared to the people
    that already work there. Even if you can point to something and
    unambiguously prove that They're Doing It Wrong, your advice
    isn't in a position to be heeded.
 
      [deleted]
 
      thesmallestcat - 40 minutes ago
      Thank you, your second paragraph is exactly my point, and I
      didn't appreciate everybody else dressing it down in
      isolation. Of course I don't want to work with a bunch of
      robots. But there's a time and place, and please don't throw
      a wrench in the interview process to prove how smart you are:
      I want to work with people who pursue their initiatives
      tactfully.
 
        majormajor - 4 minutes ago
        I think you'd find more tact with a less combative-sounding
        opener than "If you take this approach, you'd better be a
        programming god, because you're going to be the guy who was
        too good to knock out a simple coding problem."Moving the
        bit about the scope of the role (jr vs sr vs lead) up to
        preface the rest of the comment would've toned it down a
        bit, but even there I disagree with the "taking a risk"
        part -  a senior candidate shouldn't feel like it's risky
        to offer alternative perspectives. If I got the impression
        that the hiring manager thought asking questions would
        likely be a sign of "cannot focus on the task at hand,"
        that's going to set off my own flags a bit.If you're
        married to your interview process I'm worried you'd be even
        more married to your day-to-day process, and I haven't met
        a perfect company yet, so I consider being overly adherent
        to process instead of results a warning sign.
 
    irq11 - 54 minutes ago
    ?If you take this approach, you'd better be a programming god,
    because you're going to be the guy who was too good to knock
    out a simple coding problem. Every off-by-one error you commit
    on the job will raise an eyebrow. People will wonder, does this
    guy want to be an engineer or something else??And those people
    are what we call ?assholes?.Everyone makes mistakes. If you
    make a habit of questioning people?s competence because they
    make mistakes, and didn?t ace your whiteboard coding tests
    beforehand, you are 100% the source of the problem in this
    industry.
 
    majormajor - 1 hours ago
    I think it's fair for non-simple coding problems.If someone
    asked me a problem that basically reduced to a textbook case of
    something in the middle, difficulty wise, like reservoir
    sampling, and I said "oh, nifty, resevoir sampling, what do you
    use that for in your stack?" and they said "nothing, I just
    want to make sure you can code," then depending on how my
    experience to that point in the process had been going I might
    challenge them on that to some extent, a la "do you find this
    more useful than questions that are more representative of the
    work you're expecting me to do?" If the loop had been going
    particularly robotically, this might find stronger forms - I've
    walked out on a mismanaged interview before, though it was way
    worse than this (and way worse in a very different way - they
    just weren't at all prepared and the tooling they wanted me to
    use wasn't actually functional).Or they might answer something
    more like "we use it to select test cases from our logs to
    ensure that we're adequately testing against real behavior with
    proper weights" (or whatever?it's been a while since I actually
    did this in a past job :) ) in which case I'd still try to have
    what I consider a more "real" conversation ("what primary
    problem are we trying to solve, and what else might be options
    to consider"), but in that case at least they had a good answer
    to the question and I'd be happy to write the code too.But
    lastly, frankly, as a hiring manager I absolutely want to hire
    people who are willing to "not focus on the task at hand" and
    question things. I don't want people who just blindly do what I
    tell them to, I want people I can trust to disagree with me and
    be able to make a case for why they disagree. Being a manager
    doesn't mean my instincts are 100% and theirs are 0%.
 
gameguy43 - 1 hours ago
A piece focused on non-technical tips:
https://www.interviewcake.com/coding-interview-tips (Full
disclosure: I wrote it)
 
10-6 - 2 hours ago
For those of you who like solving coding challenges online either
for fun, practice, or to prepare for interviews, here's a list of
popular sites:https://medium.freecodecamp.org/the-10-most-popular-
coding-c...I also recently put this list of resources together
about Algorithms practice which I think can help out anyone who's
preparing for an interview soon:https://medium.com/coderbyte/how-
to-get-good-at-algorithms-d...
 
kafkaesq - 2 hours ago
2. What happens between you typing a URL into your browser address
bar, hitting enter and seeing a web page?"What happens when I'm
asked a question like X?  I spout a mutated form of some canned
response I cribbed from a list I found on HN a while back.  Because
I hear that's how you're supposed to 'rock your coding interview',
these days."3. What are the things you should consider if you were
writing your own database server?"Look, you know as well as I that
this job has nothing -- as in, nothing whatsoever -- to do with
actually building production-grade database servers.  Or anything
even remotely analogous to it.  Debugging that tangled mess of
poorly conceived, never-reviewed JSON APIs left behind by the other
developer (while you were pestering them about 'disruption' and
'just needing to get this thing to market') is more like it.""But
hey, since you're playing that game, I can play too:  here's a
bunch of catchphrases like 'non-blocking I/O, sharding, blah blah.'
Because I hear that's the killer answer to give to questions like
these.  And BTW, if you really think that people Michael Widenius
or Salvatore Sanfilippo would be interviewing for this job, then
your problems are way bigger than I could ever hope to help you
with."
 
  neeleshs - 1 minutes ago
  #2 is a great filter question. You'll be surprised how many
  people don't have a clue on this. I'm more than willing to answer
  that question. It tells the interviewer I have a basic
  understanding and can expand on it later
 
  gwbas1c - 34 minutes ago
  (Downvoted)That's a really nasty attitude to take when someone is
  trying to evaluate paying you a large sum of money for many years
  of work.Considering that I've run a ton of technical interviews,
  there's no good way to evaluate someone for competency without
  these kind of hypothetical questions. (This is how I screen out
  the morons who don't know how to use a database.) It's a two-way
  street, though. You can learn a lot about an organization by the
  kinds of questions they ask and the direction they send you down.
 
  wh-uws - 33 minutes ago
  Some permutation of this comment is made litterally everytime any
  coding interview resource is posted.I'm sorry man no cares that
  you and everyone who upvoted this comment are Super God
  programmers with 30 offers everytime they say they are looking
  who can afford to tell every company where they can stuff their
  interview.Us mere mortals are willing to do whatever it takes to
  get our dream gigs.These guides are largely targeted are getting
  into the some of the best, thus pickiest and most selective
  companies, in the world.And if getting on means being a dsalgo
  monkey in front of a whiteboard for a few hours so be it.Let us
  share interview tips in peace please.This "hurr durr technical
  interviews suck" but I have no real alternative and have never
  built a company nor seen any really flourish at the top without
  this is monotonous.Put your money where your mouth is and start
  and only support companies that skip these kinds of
  interviews.Like these fine peoplehttps://github.com/poteto
  /hiring-without-whiteboardsBut the snarky comments are beyond
  annoying.
 
  matthewmacleod - 1 hours ago
  I'm not quite sure what you're complaining about.What happens
  between you typing a URL into your browser address bar? isn't a
  question that requires a canned response to be parroted back ?
  it's a starting point for a conversation about your knowledge of
  the web technology stack. It's not at all like there is a
  'correct' answer, but demonstrating that you have a vague idea of
  how parts work, can identify gaps in your own knowledge, and make
  reasonable choices about how you might fill them.Maybe what are
  the things you should consider if you were writing your own
  database server? is somewhat less directly applicable to most
  jobs, but I'd argue much the same sort of thing applies ? it's a
  kicking-off point for a conversation about systems that you
  should have at least rudimentary knowledge about.I'm curious as
  to what you would prefer in a technical interview - more directly
  relevant questions about the specific systems you would be
  working on?
 
  ptero - 1 hours ago
  I think many technical interviews are simply trying to assess
  whether the candidate has his head screwed on straight and the
  ability to do basic engineering. As such, the specific topics are
  practically irrelevant.At least that's what I try to do when I
  end up interviewing someone. For example, can he suggest what
  sensors would be good for a Lego robot that would knock a tennis
  ball off the ping pong table without itself falling off? Can he
  describe the logic? How would he test this? How long, on average,
  would it take? What position of robot and ball would give the
  worst case performance (success or time)? His job will not
  involve Lego robots, but IME the person who can give sane answers
  on those would do a lot better than a coder who knows one toolkit
  well and nothing else.
 
    [deleted]
 
    majormajor - 1 hours ago
    FWIW, though I'm just one datapoint, if I'm going to have a
    "this isn't the day to day job" question thrown at me, I'd
    rather it be something more off the wall like this than most of
    the "do you remember this from your textbook/reference
    materials" style of trivia. Then I feel like approaching it
    from first principles is what's desired, and free to bounce
    ideas around, rather than being expected to remember the
    optimal log(n) "right" answer.
 
    gumby - 1 hours ago
    I agree these kinds of open ended questions are good since they
    can go in lots of different useful directions (specs,
    performance, algorithms, generality) and give you some idea
    what it's like to work with this person (and for them to get an
    idea if you're jerks or not).
 
    brian-armstrong - 43 minutes ago
    He?
 
  _jordan - 1 hours ago
  regarding the database question:I hear it as:"Tell me how
  detailed your understanding is of database internals in a
  conversational format; here is a talking prompt to
  help..."regarding typing in the url question:"Tell me the level
  in which you understand networking protocols"In the real world I
  would hope these questions would be more of a discussion; "ah,
  you mention ACID, what kind of pattern can you employ to help
  implement that", "MVCC" etc..This format of interview is hard to
  pass on simply regurgitation alone and does a pretty decent job
  of vetting technical understanding in a natural, conversational
  way.
 
    SilasX - moments ago
    This happens every time the question comes up:1) Everyone
    swears up and down that it's an absolutely vital, fair
    question.2) Everyone justifies 1) by giving conflicting (to
    others' answers) criteria they're judging it by, such that no
    answer could possibly satisfy them all, except by saying
    something smart that impresses the interviewer and might not
    correspond to rigorous judgment criteria.
 
    eradicatethots - 1 hours ago
    Could you not just ask the direct question? Eliminate the
    nonsense..
 
      IncRnd - 41 minutes ago
      Of course, but that isn't always as efficient.  Candidates
      bone up on canned responses the weekend prior, and it's also
      good to see which candidates are independent learners.You'd
      be surprised how many senior developers freeze when they are
      asked to reverse a list using any language of choice.
 
    methodover - 1 hours ago
    The URL question is a really good one though. You should
    absolutely understand every step of that process if you're
    working on web applications. The database one is weird. You
    don't need to know how to create a good database system
    yourself in order to effectively use one, I think. Neither do
    you need to know how to make a web browser to know how HTTP
    requests work.
 
      aidos - 1 hours ago
      While that's mostly true, to use a db efficiently you need to
      have a bit of an idea of what it does inside.I don't see that
      question as being any different really. They're both just
      ways of guiding a conversation around the area we work in to
      gauge what candidates know / are interested in.Personally,
      I've poked around in Postgres a bit because I find it
      interesting. And having deeper knowledge means that when
      you're about about to add a new not null column with a
      default value to a massive table you can stop and reason
      through how you're about to shoot yourself in the face :-)
 
        kafkaesq - 21 minutes ago
        To use a db efficiently you need to have a bit of an idea
        of what it does inside.You need to have a bit of an idea,
        sure.But in order to give any kind of a meaningful answer
        to the question, you need to have not just a "bit of" an
        idea, but in act, a deeply solid and intuitive idea.
        Either that or -- crib the answer from websites like these,
        know that it's one of the top 30 questions you're likely to
        be asked.Which, very sadly, is exactly what the modern
        interview process (greatly) incentives people to do, these
        days.
 
      majormajor - 1 hours ago
      Every step? Keyboard interrupts and the browser going from
      DOM to OS drawing APIs included? ;)Many of these questions
      are very vaguely scoped which gives the confident and
      familiar plenty of room to show how clever they are, but also
      makes it more intimidating for those who haven't seen them
      before.Or, to put it another way, the linked site looks like
      a great way to make yourself look like you have a junior-to-
      mid-level understanding of a lot of different areas. But the
      process it's optimizing for starts to break down the more
      senior a developer you either (a) are or (b) are trying to
      hire.
 
        IncRnd - 43 minutes ago
        If it's a job to work on a haptic feedback system, they may
        very well want to plumb your understanding of when
        interrupts fire, without prompting for canned answers.If
        you're interviewing for a front end position, you can make
        a nod to interrupts and continue on with BGP, ARP, DNS,
        TCP, IP, routers, etc.  If you want to show your knowledge
        of security you could mention heartbleed, poodle, or even
        say why this isn't vulnerable to shellshock.  An overview
        will take a minute, and the interviewer will follow up with
        more targeted questions if needed.  It's a chance for the
        candidate to shine.
 
          majormajor - 23 minutes ago
          I think it's worth being aware that the more open-ended
          you make the question, the more you might freeze a less-
          practiced-at-interviewing candidate on not knowing where
          to start.I'm always ready when asking something very open
          ended to follow up after 15 seconds or so to say "let's
          talk about [area X] first." For URLs, maybe this is
          "let's talk about what the actual network request, if you
          sniffed the traffic, looks like."
 
      kafkaesq - 9 minutes ago
      You should absolutely understand every step of that process
      if you're working on web applications."Every step?"  Not at
      all true, in my experience.What you need is a reasonable
      sense for the breadth and depth of the topic -- which quickly
      reveals itself to be far broader and deeper than what most
      engineers (including many very capable people I know) can
      hope to "absolutely understand every step of".  And the
      ability to drill down (and go down rabbit holes) when needed.
      Combined with the experience of actually having gone down
      more than a few (and having from relatively unscathed,
      eventually).
 
  methodover - 1 hours ago
  > What are the things you should consider if you were writing
  your own database server?"How did I get to this situation? Why am
  I here? Why am I writing my own database system instead of using
  an existing one? Where should I leave my resignation letter?
  Should I give them two weeks notice or just quit right now?"
 
  IncRnd - 1 hours ago
  These types of questions aren't about playing a game of
  catchphrases but  are meant to let the candidate shine through
  demonstrating their thought processes.  They are also used as
  behavioral questions to assess how a candidate deals with
  situations in which they are not familiar, even if the task
  itself is incredibly easy or not directly applicable to the
  job.You'd be surprised how many people freeze when they are asked
  to reverse a list of elements.Another reason to ask fundamental
  questions is to ensure that an otherwise fit candidate
  understands the tradeoffs involved.
 
jv22222 - 56 minutes ago
I had an idea for a startup that I think could be a much better
solution than code interviews.It hinges on the fact you can get a
much better sense of a developer after you've worked with her for a
few weeks.So, here's the startup idea:Hire a group of developers to
to work with you on a small project for a few weeks. They come in
as a (virtual or real world) team and build something you've been
meaning to do, but it's on your low priority stack.All of the
developers in that group are actually looking for a full time job.
As you work with them during those 2 weeks you can see which dev
you gel with best and offer them a job.In the mean time, all the
devs get paid for doing useful work for you for a short period of
time, even if they don't get hired.So... the startup is a central
agency that engages developers looking for a full time job and then
hires them out as a group to help clients do a small project, with
a view to picking one or more of the developers for full time
work.This is a win for the agency because they have to do less work
to convince a client about a candidate. It's a win for developers
because they get paid to be on job interviews. And it's a win for
the client because they get to try before they buy and as a result
will make much higher quality hires.Possible brand name:
TeamHireEdit: If you like this please feel free to take it and run
with it :)
 
  ramphastidae - 51 minutes ago
  Is your idea limited to developers who do not already have a job?
  How would someone with a job use this?
 
    jv22222 - 49 minutes ago
    I think you could do something like night or weekend teams.
    They could work in a virtual capacity in a hangout, or they
    could come in if they were close by.
 
      Epenthesis - 33 minutes ago
      But why would I as a person looking for a job want to commit
      a week or more of my free time to do something like
      this?Especially since the current job market gives me plenty
      of much lower time investment options?
 
        jv22222 - 31 minutes ago
        > Why would I, as a person looking for a job, want to
        commit a week or more of my free time to do something like
        this?Well, for one thing it would probably be a fun
        hackathon type team experience.It would also be good for
        growing your professional network and increasing your luck
        surface area.
 
      [deleted]
 
  IncRnd - 48 minutes ago
  Contract to hire is done quite frequently.  Is that what you
  mean?
 
    jv22222 - 41 minutes ago
    Yes, but a web platform that is specifically geared to setting
    that up. Something like hired.com but just for this.
 
      IncRnd - 35 minutes ago
      Hmmm.  By Devs.  For Business.  Buy a Dev.Seriously, though,
      that's not a bad idea.  I've seen similar startups that pre-
      interview a bunch of candidates (instead of farming them out
      for small jobs), so this is a different take to solve the
      same issue.  Both sides get a chance to win, either way.
 
  gwbas1c - 38 minutes ago
  This already (somewhat) exists with contracting firms. My team is
  mostly people hired this way.The problem is that the contracting
  firms still want to stuff your office full of their workers, so
  we still need to run diligent interviews. (This means making sure
  that they don't coach the candidates through the interview,
  because once the candidates are coached, we can't really evaluate
  them.)The good news, though, is that we get much better results
  working with a firm like this. Most of the people we interview we
  hire, unlike in the past, where most of the people we interviewed
  were straight up morons.
 
    jv22222 - 35 minutes ago
    I think, with the right platform (ie like hired.com), you could
    automate much of that initial process of deciding who you
    wanted to be part of your team.
 
  hysan - 38 minutes ago
  Getting deja vu reading this several years ago. I think someone,
  maybe Stack Overflow, actually did this as part of their hiring
  process. I think the devs that were brought in were even paid for
  their work during this time.
 
Clubber - 1 hours ago
So I wonder. If someone memorized all that trivia, do you think
they can code?
 
partycoder - 2 hours ago
I think that competitive programming, the kind of programming done
at IEEE / ACM competitions as well as interviews, is very different
from actual day to day programming.It tells you the person
understands data structures and some aspects of programming, but
translating that to productivity/success is questionable.In
addition to competitive programming you've got "collaborative
programming". Programming for maintainability, growth, construction
for verification, good practices, etc.A good programmer has a
balanced combination of both.
 
  MartinCron - 50 minutes ago
  I like to make the distinction between being a good "programmer"
  and being a good "professional software developer". Lots of good
  programmers aren't necessarily good professional software
  developers.I usually make it a policy not to bad-mouth my fellow
  coders, but I once worked with a BRILLIANT developer, knew all
  the trivia, rocked his interview, impressed the hell out of all
  of us.He then spent two solid weeks building an email address
  validation micro-service. It was perhaps the most exquisite and
  technically correct email address validation micro-service ever
  built, but was that really what the business needed?
 
aith - 1 hours ago
This has a bit of a web front end slant. Check out
https://www.acefrontend.com for another good source of practical
front end challenges
 
westurner - 1 hours ago
This is also a great resource, if you're into studying
yourself:"Coding Interview University" https://github.com/jwasham
/coding-interview-university
 
pfarnsworth - 14 minutes ago
The only answer is: memorize all the leetcode answers perfectly,
and pretend you don't know the answer but that you're "working
through it".At places like Facebook, I heard that you're given
several interviews with 2 coding questions to answer perfectly in
45 mins.  It's basically luck of the draw whether or not you know
the answer, and the best way to game it is by memorizing as many
answers as possible.  I know this is possible because I have
friends that have gotten offers from Facebook and Google by doing
exactly this.All this does, of course, is create an arms race where
interviewers ask harder and harder questions.  It's frankly
ridiculous unless we start taking the algorithmic portion away from
the interview.
 
rickthegeek - 2 hours ago
We wrote a post around this too if anyone is interested -
https://geektastic.com/blog/five-killer-interview-questions-...