26 ms·

How to pass a programming interview (2016)

282 points by davidjnelson 8y ago

frfl 8y ago
A recent experience I've had with programming screens, not whiteboard interviews specifically, is the lack of feedback. I'm given a programming problem (or a set of problem), given about 2 hours to do it, I do it in the allotted time, check my code, verify to the best of my ability that what I've come up with in the limited time is correct, I verify I'm passing the provided test cases and some test cases I come up with. Then it's basically a coin flip whether anyone follows up. No feedback, no reason why they're not moving forward besides maybe some generic HR response about my qualifications or 'decided to go in another direction'. Quite annoying and a waste of time on my end. Is this it? Is this really the best way to filter down the pool of resumes? Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge).
- Novashi 8y ago
  >Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge). It is, I wouldn't entertain companies that do this unless you really need a position. This is the trifecta of bad interviewing tests: - No compensation - Stupidly restrictive time limit - High chance of not getting feedback Personally I would turn them down and then explain these three things. There are plenty of companies with less annoying hoops.
  - eikenberry 8y ago
    > - Stupidly restrictive time limit This one kills the chance of my applying by itself. Turns what could be a interesting coding challenge into an exam, ruining the fun of it. I could see junior devs going through this to get some experience but why would anyone past that point in their career bother when there are so many options?
    - dajohnson89 8y ago
      Because the companies that do the coding exams pay well, have high prestige, use tech that he likes, etc. It's not always so simple to just refuse to go through an annoying interview process, even if it sucks.
      - eikenberry 8y ago
        Of course there will be exceptions to any rule. But in general it is still a good rule.
  - sys_64738 8y ago
    > - No compensation Curious if anybody has ever billed the interviewing company for their time if they didn't get the job.
    - _asummers 8y ago
      Not the same thing but I’ve read that Square pays people for coming to their on site interview because it’s a full day. Unsure if that is still the case.
- bitwize 8y ago
  As a rule, do not expect feedback from companies. On the company's end, it's just not worth the risk of opening themselves up to potential legal liability to provide detailed feedback to any candidate. The new standard for responding to a rejected candidate is ghosting. The company has extended you a profound courtesy by bothering to respond at all.
  - drunkpotato 8y ago
    Everything about this response is a poisonous and stupid lie. Detailed feedback is fine. There is no legal liability if you’re not discriminating against a protected class. Companies and individuals that behave this way are poisonous and stupid and best avoided.
    - chrisbennet 8y ago
      Maybe you wish this was so, but it does not appear to be in practice. https://www.quora.com/Why-dont-companies-give-interview-feedback https://www.quora.com/Why-dont-companies-give-interview-feed...
    - standardUser 8y ago
      Sure, and since companies aren't paranoid about discrimination lawsuits... oh wait.
- vilifiedtwin 8y ago
  You get feedback - either they liked you or not. If you need any more than that then it means you need to learn more.
- chrisseaton 8y ago
  I've gotten feedback, and even more frustrating than no feedback is demonstrably false feedback. Google said I should try contributing to an open source project to improve my resume... when I had literally a million lines of code in a major open source project, and that was written on my resume. Was it a mistake? Was there a mixup and had they interviewed me thinking I was someone else? Did they have a corrupt copy of my resume? More likely was it a throwaway comment from someone just saying something to be polite? No idea, but it's more frustrating than just 'no thanks' because it didn't even make any sense. Imagine if you tried to improve yourself based on that feedback, applied again, and then they overlooked it again and gave you the same feedback!
  - badfrog 8y ago
    How do you get to a million lines of code on an open source project? At my full time job, 5k lines in a week would be a lot, and even at that fast pace it would take four years of full time work to get to a million.
    - chrisseaton 8y ago
      A million lines diff yeah, not standing code, over a few years of basically full time as my PhD on a fast moving greenfield project. A lot of refactoring causes churn.
  - frfl 8y ago
    I could see how this might be an issue with someone early in their career who has a low-profile project or two, but your resume would stand out very quickly among the rest so for this to happen is alarming. Feels like a very similar occurrence to what happened to the homebrew dev who got reject by google (albeit different circumstance to your false feedback)
    - deleted 8y ago
      [deleted]
    - tom_ 8y ago
      The homebrew guy was subsequently hired by Apple, but later left, saying in a (now deleted) tweet that big company life wasn't his bag. Link from around that time: https://news.ycombinator.com/item?id=12276219 https://news.ycombinator.com/item?id=12276219 There's a non-zero chance that the Google interviewers were able to pick up on this. Those of us not directly involved only ever got one side of this particular story.
- wwweston 8y ago
  There's not much you can do about the fact that most prospective employers won't have a particularly good idea how to optimize the hiring process and even if they did, their incentives wouldn't always be aligned with applicants when it comes to questions of investing time. But in a market like the current one, many developers can do some filtering of their own. When I'm asked to complete a test or exercise, over time I've made it a habit to ask questions like these: - Do you have reference solutions that someone at the company completed on company time? - Exactly how long did it take them? - Do you have a rubric for evaluating submitted solutions? - Will you share the reference solutions and/or rubric once I've submitted mine? I don't need 100% positive/detailed answers to each one of these -- I know from the other side why they're not always there -- but how people respond seems to improve my early feel for (a) how the organization approaches process and problem-solving and (b) whether my solutions are likely to get a serious examination and useful feedback, which I can then use to inform my choice about whether putting in the time is worth it.
- hermitdev 8y ago
  I recently went through interviewing at a number of companies. One had a hackerrank problem to solve. I was fine with it, took me a couple of hours to complete. What frustrated me is that my solution passed all of the disclosed scenarios, but failed about half of the non disclosed. Neither the input nor output was disclosed. How do you expect someone to solve a problem when you dont disclose either the inputs or the expected output?
acconrad 8y ago
For anyone interested, I took notes on The Algorithm Design Manual for JavaScript if you are studying chapters 3 through 5 like the blog post suggested: https://userinterfacing.com/tag/algorithms https://userinterfacing.com/tag/algorithms
- rhizome 8y ago
  Thank you!
basementcat 8y ago
<irrelevant comment deleted>
- znpy 8y ago
  you probably wanted to comment on https://news.ycombinator.com/item?id=19344146 https://news.ycombinator.com/item?id=19344146
draw_down 8y ago
I give a particular programming interview that reduces to sorting a list by a simple criterion and then returning the first item in the list. Unfortunately people can tie themselves into some serious knots trying to solve this pretty simple problem. I agree with the article that performing well in this style of interview is a separate skill from being a productive programmer. I also think there is value in being able to write some code pretty quickly, while making it correct and readable. The enthusiasm and interaction stuff is another matter, that's definitely hard to muster while you're a) nervous and b) simultaneously trying to solve a problem.
crb002 8y ago
Triplebyte/HackerRank etc is a great filter for companies that view their developers so low they would subject them to such pre-employment screens that no other employees in the organization must jump through.
- ball_of_lint 8y ago
  I dislike most competitive programming sites as a hiring method, but Triplebyte works more like a recruiting firm. They do their own phone interviews that cover a large breadth of programming topics including a number of things that are often missing from whiteboard interviews, such as parallel programming. Out of the many times I've been interviewed my Triplebyte interview is in the top 3 that best represented my skills.
- cbetti 8y ago
  I really enjoyed triplebyte's online software engineering challenge. One of their ads caught my eye about nine months ago, so I gave it a shot. I thought the challenges covered topics concerning software maintainability, implementation time trade-offs, investment value judgement calls, interface design, separation of concerns, etc. very nicely. I'd never thought to interview on some of the topics presented until I took the quiz. Worthwhile Saturday evening accompanied by a beer or two.
- iratewizard 8y ago
  I took their test once for fun once a few years ago. A few months ago they suddenly added me to their "newsletter". Every week I would unsubscribe and the next week I would receive their spam like clockwork. I complained that they need to fix the unsubscribe link. Two months later some hapless customer support person gave me a very informative email about clicking the unsubscribe link at the bottom of their emails. Not a company that has things together to say the least.
  - ttsda 8y ago
    Same experience here, did their challenge once, only feedback they will give you about your performance is something like "exceptional" and then they keep spamming you every day even if you said in the questionnaire you aren't interested in a new job.
daxfohl 8y ago
I'd say rather than practicing interview questions, work on a side project that really stretches your technical ability. And a hard project, something that you don't even know where to start, not just "I'm going to rewrite this todo app in vue.js". I think that gives your brain more of a workout than droning through interview questions day after day. Even though you could say "you don't run marathons to practice for a sprint", just in my experience it works better. The interview practice websites are too easy to get distracted from, or look up the answer, or whatever, and your brain really doesn't get the workout that a solid long-term low level project gives it. Plus, at the end, at least you have a project you've done.
- lucasmullens 8y ago
  I'd agree that doing projects is a better way to learn in general, but some level of practicing interview questions is needed when applying to companies that do whiteboard interviews. Projects can boost your resume and get you in the door, but they're not a huge help in passing some algorithm question.
- bradlys 8y ago
  Unfortunately, this doesn't translate to interviewing in silicon valley. It's a completely separate skill unless your job is explaining out loud various algorithms and data structures to other people to solve a variety of contrived problems. I'll admit I've done things that are close to this for real world situations but it's maybe once every month or 3. Not a situation for /most/ of us on a regular basis.
  - daxfohl 8y ago
    No, not a work project. Agree most of our jobs are pretty banal, figure out how to get this css to center correctly in IE6. Rather, selectively choose a side project to do that likely will involve some interesting data structures and algorithms. That will give your brain a really deep workout and it'll be more prepared to go through silly interview questions.
- badfrog 8y ago
  Sadly there tends not to be much correlation between real life programming and interview programming. Most of the software engineers at my company feel that we couldn't pass our company's interviews because we're out of practice.
joeax 8y ago
They eat large sprawling problems for breakfast, but they balk at 45-min algorithm challenges. If a candidate can solve large, complex problems but bombs your interview, the problem is your interview. TripleByte should focus on this problem and educate these companies on effective interviewing techniques. For example, if your interview overemphasizes coding challenges, puzzles, quizzes, or otherwise feels more like being on Jeopardy than real-world applicable, you're doing it wrong. Candidates should be focused on their skill set and filling in gaps (i.e. I've toyed with Python but I see it being in demand so let me get better at syntax, packages, thinking in pythonic way).
- LanguageGamer 8y ago
  Okay, but the problem is, 45-60 minutes is usually all hiring managers have to assess a candidate. What can you do in that amount of time to assess someone‘s real world performance? Having a high level conversation about technology and problem solving approach helps but often doesn’t translate into writing code. Tech-stack specific challenges are no good because general programming ability is more important, you can learn a new language on the job. Algorithm puzzle problems aren’t great because then we’re selecting for people who spend a lot of time on hackerrank or whatever. Maybe effective programmer hiring is just an unsolved problem.
  - asark 8y ago
    What's so friggin' different about hiring software developers that we've gotta get all weird about it and come up with some brand new thing? What's the hiring process like for other office workers? How about for other technical or specialist roles that are somewhat similar to software developer? Engineers of various sorts, maybe? Accountants? Hell, lawyers even? There's got to be some set of existing practices that'll fit this just fine. It's simply not. That. Special.
    - dilyevsky 8y ago
      It kind of is tho. Also you should research what kind of shit accountants have to go through to get hired at big 4 for instance. And lawyers have to pass bar.
tickthokk 8y ago
> These are concepts that are far more common in interviews than they are in production web programming So of course let's talk about a dozen different types of them! Welcome to Ford! To be considered for this position, please list every GM Model from 1983 to 1987.
cooooooffffeeee 8y ago
foo bar
dang 8y ago
Big discussion at the time: https://news.ycombinator.com/item?id=11246917 https://news.ycombinator.com/item?id=11246917.
elteto 8y ago
Funny, I just went through a pre-screen assessment for one of the big ones and it was not one but _two_ DP problems. I could have probably come up with a slow solution using recursion and a bit more of time, but was given only 90 minutes. And I thought to myself, what exactly did they learn about _me_ after this exercise? Absolutely nothing, except that I can't solve DP problems on the spot. What a waste of time. And the funny thing is, I work as an embedded developer and actually have to look up a topic or two from CLR at least once a year for work stuff (which is not very common). But DP? I've never needed it or used it. Why the emphasis in it then? It feels a lot like software interviewing is just a bunch of rain dances and cargo culting and those that know the dance get through the hoop. I guess I'll have to order Elements of Rain Dancing from Amazon and get to practicing.
- glangdale 8y ago
  I feel your pain. I did exactly one dynamic programming algorithm (in the string matcher for Hyperscan) and was pretty inordinately pleased with myself for doing it, but we built dozens of algorithms in that project and that was the only case of DP that I recall. But I expect to go into interviews and have people demand a different rain dance, now that everyone is talking about DP. They like mugging people with 'so big it has to be out of core' stuff, which is a good way of finding out who went to the right grad school algorithms course. :-)
  - vkazanov 8y ago
    I think I only saw DP-based algorithms 3 times in 12 years of working and reading open source code. Two of them were boring textbook-based implementations. One algorithm was original, and came from 80s - it's from Emacs source code, with comments like "do not touch", "here be dragons", etc.
    - glangdale 8y ago
      Yes, the code involving the DP algorithm I put in had a bug in it - not from the DP algorithm itself but the assumptions that fed into it - which went undetected for some time because of how complex the DP algorithm was and how hard it was to evaluate. It only caused a minor performance quirk (not a actual semantic error) so was hard to find. A cautionary tale about being overly clever-clever I suppose.
deleted 8y ago
[deleted]
akhilcacharya 8y ago
Is there any evidence that coding interviews aren’t just tests for 1) general fluid intelligence or 2) memorization?
aphextron 8y ago
The best part about these types of interviews is how they don't even treat you like a human being. There's absolutely zero interest in you whatsoever, and moreso every single word that comes out of your mouth is by default treated as a lie until they've had you submit to their Leetcode questions and determined you to be worthy of even speaking to. It's why I've become so incredulous at even being asked anything in the first round; anything I have to say here is completely meaningless and has no bearing whatsoever on any kind of hiring decision until that test has been passed. The utterly degrading inhumanity of this process had driven me to an emotional breaking point until I started interviewing outside the bay area. And what do you know? It's a completely different world. To anyone else stuck in this nightmare, just leave. Another 20% take home pay is simply not worth your sanity.
- frfl 8y ago
  When you say outside the bay area, do you also mean companies are not 'tech-first' type companies? (companies that hire devs, but their primary domain is not just some app/website/saas) I've applied to many jobs in Canada, but I've still noticed a large tendency for companies to put you through a screen even before they speak to you.
- skinnymuch 8y ago
  Does interviewing outside the Bay Area mean interviewing in places still around north Cali? Or going away from that region entirely? I know SF, Bay Area, and SV are different, but i have them all sort of confused and lumped together.
fma 8y ago
#1 on that list is enthusiasm for the company. Really...? So, you gotta be a good bullsh!tter? I can see this for small startups, because passion will take you to places. But for large companies, their software products are so diverse. I work for a manufacturing company and my application space has nothing to do with manufacturing. Every space has their challenges and pitfalls. As long as you have good tech, good people, and aren't doing anything unethical, I'll want to work for you. Also, I've thought about the interviewing problem a bit. I don't do the interview for my team...but if I have the opportunity to interview and was given free range, I think I would create a small application using our tech stack. Put some bugs in there, put some bad practices, and let the interviewee fix it. Talk about the tech stack, how to scale it, design trade offs, etc. IMHO reading code and maintaining code is more important than knowing bfs and dfs by heart.
- rayvy 8y ago
  This is a decent start, but then again remember you only have 60 minutes. And what might seem relatively easy to you, might not be so easy to someone with a time limit (60 mins), and pressure (trying to get a job you want).
magnetic 8y ago
(I think I made a similar comment to a similar submission a while back) I suggest this type of interview: Both the interviewer and interviewee get a problem to solve and they work together to solve it. It should be new to both of them, so the interviewer can better assess its level of difficulty without the bias of knowing the solution beforehand. This will enable natural empathy for the candidate. It also shows how interaction would look like in every day kind of work. You can learn a lot about another person's skill by doing pair programming. Logistically speaking, you can whiteboard the design/code, or sit around a big screen for the coding part, with whatever tools/IDE the candidate likes to use (s/he should be writing most of the code, even if the solution/design was a common process).
mgkimsal 8y ago
I just went through a small exercise with a company ... we did an hour screensharing on coderpad. basic exercise was in php (mix of systems, but there's existing php to touch). financial service industry, and they'd mocked up a rough idea of a typical problem. The example code clearly wasn't production, and was generic, but also illustrated the problem domain well enough for them to get an idea of how well I could adapt. I got through the 'nut' of the problem in about 10-15 minutes, talking through some issues. One thing I'd ignored (and said I'd be ignoring) was date handling - they wanted some date sorting thing, but since this was just 'raw' code without any good helper libraries, I suggested we punt on that (and I named the libraries I'd typically use for date handling). There was one spot where the interviewer suggested the ?? 'newer' null coalescing, where I'd been looking at doing some 'array_key_exists' checking. he'd suggested that the ?? syntax was easier and more compact, and I'd countered with I'd prefer to be more explicit about the specific keys I wanted to check for, and that ideally I'd be using a class or some other more defined structure to ensure some degree of valid data shape as a first level of sanity checking. I'd felt I may have pushed back a bit hard on that point, but, we moved on. After the first 15 min or so, we'd spent another 15-20 talking about different ways to do other types of error handling, some potential performance issues, etc. High level stuff, mainly, which... there's only so much you can do with coderpad (my jetbrains and vim muscle memory did me no good in the browser!) All in all, though, I'd felt it was a decent exchange. They were able to show a 'real' problem without relying on any proprietary stuff, it was difficult enough that someone junior probably would have struggled a bit more, the guy on the other end was pleasant, and engaged appropriately (responded to questions and casual banter, and interjected now and then to ask questions and give feedback in real time). It was probably one of the better 'tech interviews' I've had (although I haven't had many in recent years, so, hard to compare). It did seem better than many I read about, and certainly better than some from 10-15 years ago.
- akanet 8y ago
  I'm the CoderPad guy dropping in to mention you can switch to vi keybindings in CoderPad settings!
  - mgkimsal 8y ago
expopinions 8y ago
The key to success in any interview, but especially in a programming interview, is practicing as much as possible. It's not enough to start just a few days before the real thing. The best method of preparing is incorporating your interview prep into your everyday coding practice, so that you'll never fall behind, even if you aren't currently searching for a job. But the plan "to practice" is too vague and leaves a lot of programmers unsure of how to get started in the process, which can be overwhelming. If you're frustrated and aren't sure how to get going on your coding interview practice, follow these steps to get started. 1. Review the basics. Even experienced programmers and engineers can get tripped up when questions about algorithms and data structure come up. If you haven't yet mastered the basics, focus on this for a few weeks or months to get yourself ready to tackle the bigger problems. It's crucial, not only for a coding interview, but for the entirety of your professional career, that you understand the basics. They are your foundational skills upon which you will build and master your expertise. 2. Solve coding problems and work on projects. Online coding practice problems are a great place to start. Apply your knowledge and work on projects you enjoy. Write code. Build things. Put your skills to use. This should be the fun part - if you aren't enjoying the journey and the process of building your coding skills, you'll have a difficult career as a programmer. Sure, there will be moments of frustration where you'll want to smash your computer screen and throw your mouse at the wall. But forge on. Keep trying. Find those bugs and destroy them. Build great things, and immerse yourself in online forums and other communities where you can turn to for help when you really get stuck. 3. Use online coding interview platforms for practice. This is a great way to get exposure to how the real coding interview will feel. Smash your nerves and anxiety by conducting a full coding interview with a partner. On platforms like Pramp and Leetcode, you'll get paired with another programmer of a similar skill level, so it will scale to your ability. Together you'll experience the coding interview from both perspectives. Performing the role of the interviewer and the interviewee will teach you a lot. After the mock run, you'll both leave each other feedback, and this is a great thing to have to tailor your practice schedule and for identifying what you need to work on the most.
randompi 8y ago
It's a programming "test" right? Sometimes I wonder if it's better to solve the problem in isolation, to show that I can sit on a problem and go at it, or to solve it in a collaborative manner with the interviewer, to show I'd play well in a team. Sometimes when I read people saying the end goal is not to solve the problem weird. Does that mean those who solved the problem alone by losing a few hairs actually scored worse than an outspoken candidate who solved it with help from the interviewer?
- viraptor 8y ago
  You can ask them what they prefer. Also, communication is an important element - in real work you may be spending time on something that's already obvious to someone else, or getting stuck on an approach which is known to not work. I think actually solving those problems or failing in the end is random (unless you know the answer already). But if you get a good chat out of it, it may be in your favour.
- mandelbrotwurst 8y ago
  Yes.
manish_gill 8y ago
> Mentioning other offers in an interview heavily biases the interviewer in your favor. Is this really true? Also, how do you just mention offers? And will the programmer interviewing me really care? Should this only be done at the HR stage? Like, what's a good way to let the other person know that they're not the only one.
balls187 8y ago
> To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. The under duress part is the dumbest part of coding interviews. I understand the approximation of small coding challenges, why explaining your thoughts is beneficial, as is understanding how a candidate approachs problem solving. Causing duress to a candidate purposefully has no value what-so-ever in the workplace.
- bootlooped 8y ago
  I think the interview process itself causes duress to candidates intrinsically. There is probably no way to eliminate it completely. That said, there probably is a reason for testing candidates under duress. Some companies may want to push people hard, and knowing they can deal with stress is valuable.
  - balls187 8y ago
    I don't agree that programming interviews are conducted to see how well candidates will fare in a dysfunctional workplace. Anecdotally, programmers thrive in quiet environments where they can have focused uninterrupted time. As open-offices have become the norm, most programmers have headphones they use to isolate background sounds. Constantly peppering candidates with questions while they are trying to do a task that is mentally intensive is not close to the type of stress candidates face on the job. Even the most work-life balanced places do these same types of interviews.
_robbywashere 8y ago
I like to imagine the movie trailer voice over guy “Do you have what it takes?” “Do think you’re tough enough!?” “You call yourself a....” “PROGRAMMER?” “Then... SORT... MY... LIST... WHILE... TALKING... OUT... LOUD” But really, I feel like the whole process is uniquely American, kind of like crossfit. Very intense very trying. Like Nike; “JUST DO IT!” The problem about this very intense “game” of interviewing is it’s for a job, for you to eat, to afford healthcare, to survive. To afford basic necessities and save for retirement. To buy a house. To start a family. To afford a car. Or even simply to not be just another body stepped over on Market street. You've probably enjoyed 7 some years as a web developer, as a productive team member or consulting for happy clients. Now some stranger is dangling a carrot in front of your face telling you to implement an LRU cache under bright fluorescent lights while badgering you with “what are you thinking, I need to know what you’re thinking” ... after you’ve just spent the last 5 hours talking about your work history etc
Adamantcheese 8y ago
Is it just me, or does this read like a massive farce? That everything that Triplebyte is trying to solve they just... can't?
Mc91 8y ago
The last good paying work I had I somehow passed the coding interview, but I bombed out of the last few I had and went back to basics. I signed up to Project Euler and Hacker Rank and have been doing problems from them. What I do is start the Linux program "recordmydesktop", and then go about solving the problem as if I am interviewing, i.e. on the clock. One thing I noticed is these programs use maps, characters, use 64 bit long numbers, do string manipulation, do certain type conversions and so on more than I usually do programming. Some of these things I would usually look up, such as how to type convert a character '7' to an integer, or create and populate a multi-array and things like that. So I made sure how to memorize how to do these test-tending things. Then I watched over my recordmydesktop sessions to see where I ran into trouble. I noticed array one-offs were a problem - getting an index out of bound error, using < instead of <= etc. Or I would declare a variable before a loop and use it initially, but forget to assign or reset it at the end of the loop when it needed that. Sometimes I would declare a variable like k and then re-use it in the same method. Also, if I ever have to switch to a web browser to look up what call does a string reversal, I note that as well, and if it is common enough, I memorize how it is done so I don't have to look it up again. Memorizing the string manipulation, map etc. functions is already working for me. I am getting better at some of the other problems, like not assigning/resetting variables at the end of loops (I put a comment next to them that they will need to be assigned/reset, and then do it later, and then erase the comment). Some I still have to work on, like reasoning about exactly where the array boundary is. These aren't things I mess up necessarily, but things that slow me down, and cause bad compiles or runtime errors. I can already see the improvement in the problems I am doing. I had been letting myself naturally memorize some of these things, I guess it's not so bad that I am memorizing more of them that I may need.
wodenokoto 8y ago
I recently came across some videos from Interview.io, which seems to be in the same business as triplebyte, the company behind TFA. I thought the interview seemed quite nice. Is this the type of coding interviews, HN is always complaining about, or is it some rosy best-case exhibition? Example interview: https://youtu.be/tj_sBZw9nS0 https://youtu.be/tj_sBZw9nS0
jonaf 8y ago
PSA: if you take TripleByte's online quiz, they don't have the capability of giving you the results of the quiz. At least, that's what I was told when I took the online quiz -- they couldn't share the results with me because the quiz is "adaptive" and scores and questions vary each time the quiz is taken. (I have no idea how they're able to do anything useful with the quiz results if they don't record them and the scores vary so greatly.) I have no faith in TripleByte or their process at this point, especially since I feel I was somewhat taken advantage of (I did the online quiz expecting to get some feedback -- isn't that the point?). I'm certain they will use the collected data from my quiz to build their product, though.
- bootlooped 8y ago
  I did it within the last week and got scored in 6 areas. It's just a whole number out of 5 points in each area, no further info. I did the 2hr phone interview later and received my interviewer's notes on my performance, which were more detailed and helpful.
royosherove 8y ago
I came up with my own set of questions that hopefully show how a person can deal with human complexity at work (the bulk of our issues), rather than memorizing algorithms. Some people don't like it - but it works for me: https://www.5whys.com/articles/a-realistic-hackerrank-developer-interview-question-list.html https://www.5whys.com/articles/a-realistic-hackerrank-develo...

282 points by davidjnelson 8y ago

frfl 8y ago

A recent experience I've had with programming screens, not whiteboard interviews specifically, is the lack of feedback. I'm given a programming problem (or a set of problem), given about 2 hours to do it, I do it in the allotted time, check my code, verify to the best of my ability that what I've come up with in the limited time is correct, I verify I'm passing the provided test cases and some test cases I come up with. Then it's basically a coin flip whether anyone follows up. No feedback, no reason why they're not moving forward besides maybe some generic HR response about my qualifications or 'decided to go in another direction'. Quite annoying and a waste of time on my end. Is this it? Is this really the best way to filter down the pool of resumes? Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge).

Novashi 8y ago
>Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge). It is, I wouldn't entertain companies that do this unless you really need a position. This is the trifecta of bad interviewing tests: - No compensation - Stupidly restrictive time limit - High chance of not getting feedback Personally I would turn them down and then explain these three things. There are plenty of companies with less annoying hoops.
- eikenberry 8y ago
  > - Stupidly restrictive time limit This one kills the chance of my applying by itself. Turns what could be a interesting coding challenge into an exam, ruining the fun of it. I could see junior devs going through this to get some experience but why would anyone past that point in their career bother when there are so many options?
  - dajohnson89 8y ago
    Because the companies that do the coding exams pay well, have high prestige, use tech that he likes, etc. It's not always so simple to just refuse to go through an annoying interview process, even if it sucks.
    - eikenberry 8y ago
      Of course there will be exceptions to any rule. But in general it is still a good rule.
- sys_64738 8y ago
  > - No compensation Curious if anybody has ever billed the interviewing company for their time if they didn't get the job.
  - _asummers 8y ago
    Not the same thing but I’ve read that Square pays people for coming to their on site interview because it’s a full day. Unsure if that is still the case.
bitwize 8y ago
As a rule, do not expect feedback from companies. On the company's end, it's just not worth the risk of opening themselves up to potential legal liability to provide detailed feedback to any candidate. The new standard for responding to a rejected candidate is ghosting. The company has extended you a profound courtesy by bothering to respond at all.
- drunkpotato 8y ago
  Everything about this response is a poisonous and stupid lie. Detailed feedback is fine. There is no legal liability if you’re not discriminating against a protected class. Companies and individuals that behave this way are poisonous and stupid and best avoided.
  - chrisbennet 8y ago
    Maybe you wish this was so, but it does not appear to be in practice. https://www.quora.com/Why-dont-companies-give-interview-feedback https://www.quora.com/Why-dont-companies-give-interview-feed...
  - standardUser 8y ago
    Sure, and since companies aren't paranoid about discrimination lawsuits... oh wait.
vilifiedtwin 8y ago
You get feedback - either they liked you or not. If you need any more than that then it means you need to learn more.
chrisseaton 8y ago
I've gotten feedback, and even more frustrating than no feedback is demonstrably false feedback. Google said I should try contributing to an open source project to improve my resume... when I had literally a million lines of code in a major open source project, and that was written on my resume. Was it a mistake? Was there a mixup and had they interviewed me thinking I was someone else? Did they have a corrupt copy of my resume? More likely was it a throwaway comment from someone just saying something to be polite? No idea, but it's more frustrating than just 'no thanks' because it didn't even make any sense. Imagine if you tried to improve yourself based on that feedback, applied again, and then they overlooked it again and gave you the same feedback!
- badfrog 8y ago
  How do you get to a million lines of code on an open source project? At my full time job, 5k lines in a week would be a lot, and even at that fast pace it would take four years of full time work to get to a million.
  - chrisseaton 8y ago
    A million lines diff yeah, not standing code, over a few years of basically full time as my PhD on a fast moving greenfield project. A lot of refactoring causes churn.
- frfl 8y ago
  I could see how this might be an issue with someone early in their career who has a low-profile project or two, but your resume would stand out very quickly among the rest so for this to happen is alarming. Feels like a very similar occurrence to what happened to the homebrew dev who got reject by google (albeit different circumstance to your false feedback)
  - deleted 8y ago
    [deleted]
  - tom_ 8y ago
    The homebrew guy was subsequently hired by Apple, but later left, saying in a (now deleted) tweet that big company life wasn't his bag. Link from around that time: https://news.ycombinator.com/item?id=12276219 https://news.ycombinator.com/item?id=12276219 There's a non-zero chance that the Google interviewers were able to pick up on this. Those of us not directly involved only ever got one side of this particular story.
wwweston 8y ago
There's not much you can do about the fact that most prospective employers won't have a particularly good idea how to optimize the hiring process and even if they did, their incentives wouldn't always be aligned with applicants when it comes to questions of investing time. But in a market like the current one, many developers can do some filtering of their own. When I'm asked to complete a test or exercise, over time I've made it a habit to ask questions like these: - Do you have reference solutions that someone at the company completed on company time? - Exactly how long did it take them? - Do you have a rubric for evaluating submitted solutions? - Will you share the reference solutions and/or rubric once I've submitted mine? I don't need 100% positive/detailed answers to each one of these -- I know from the other side why they're not always there -- but how people respond seems to improve my early feel for (a) how the organization approaches process and problem-solving and (b) whether my solutions are likely to get a serious examination and useful feedback, which I can then use to inform my choice about whether putting in the time is worth it.
hermitdev 8y ago
I recently went through interviewing at a number of companies. One had a hackerrank problem to solve. I was fine with it, took me a couple of hours to complete. What frustrated me is that my solution passed all of the disclosed scenarios, but failed about half of the non disclosed. Neither the input nor output was disclosed. How do you expect someone to solve a problem when you dont disclose either the inputs or the expected output?

acconrad 8y ago

For anyone interested, I took notes on The Algorithm Design Manual for JavaScript if you are studying chapters 3 through 5 like the blog post suggested: https://userinterfacing.com/tag/algorithms https://userinterfacing.com/tag/algorithms

rhizome 8y ago
Thank you!

basementcat 8y ago

znpy 8y ago
you probably wanted to comment on https://news.ycombinator.com/item?id=19344146 https://news.ycombinator.com/item?id=19344146

draw_down 8y ago

I give a particular programming interview that reduces to sorting a list by a simple criterion and then returning the first item in the list. Unfortunately people can tie themselves into some serious knots trying to solve this pretty simple problem. I agree with the article that performing well in this style of interview is a separate skill from being a productive programmer. I also think there is value in being able to write some code pretty quickly, while making it correct and readable. The enthusiasm and interaction stuff is another matter, that's definitely hard to muster while you're a) nervous and b) simultaneously trying to solve a problem.

crb002 8y ago

Triplebyte/HackerRank etc is a great filter for companies that view their developers so low they would subject them to such pre-employment screens that no other employees in the organization must jump through.

ball_of_lint 8y ago
I dislike most competitive programming sites as a hiring method, but Triplebyte works more like a recruiting firm. They do their own phone interviews that cover a large breadth of programming topics including a number of things that are often missing from whiteboard interviews, such as parallel programming. Out of the many times I've been interviewed my Triplebyte interview is in the top 3 that best represented my skills.
cbetti 8y ago
I really enjoyed triplebyte's online software engineering challenge. One of their ads caught my eye about nine months ago, so I gave it a shot. I thought the challenges covered topics concerning software maintainability, implementation time trade-offs, investment value judgement calls, interface design, separation of concerns, etc. very nicely. I'd never thought to interview on some of the topics presented until I took the quiz. Worthwhile Saturday evening accompanied by a beer or two.
iratewizard 8y ago
I took their test once for fun once a few years ago. A few months ago they suddenly added me to their "newsletter". Every week I would unsubscribe and the next week I would receive their spam like clockwork. I complained that they need to fix the unsubscribe link. Two months later some hapless customer support person gave me a very informative email about clicking the unsubscribe link at the bottom of their emails. Not a company that has things together to say the least.
- ttsda 8y ago
  Same experience here, did their challenge once, only feedback they will give you about your performance is something like "exceptional" and then they keep spamming you every day even if you said in the questionnaire you aren't interested in a new job.

daxfohl 8y ago

I'd say rather than practicing interview questions, work on a side project that really stretches your technical ability. And a hard project, something that you don't even know where to start, not just "I'm going to rewrite this todo app in vue.js". I think that gives your brain more of a workout than droning through interview questions day after day. Even though you could say "you don't run marathons to practice for a sprint", just in my experience it works better. The interview practice websites are too easy to get distracted from, or look up the answer, or whatever, and your brain really doesn't get the workout that a solid long-term low level project gives it. Plus, at the end, at least you have a project you've done.

lucasmullens 8y ago
I'd agree that doing projects is a better way to learn in general, but some level of practicing interview questions is needed when applying to companies that do whiteboard interviews. Projects can boost your resume and get you in the door, but they're not a huge help in passing some algorithm question.
bradlys 8y ago
Unfortunately, this doesn't translate to interviewing in silicon valley. It's a completely separate skill unless your job is explaining out loud various algorithms and data structures to other people to solve a variety of contrived problems. I'll admit I've done things that are close to this for real world situations but it's maybe once every month or 3. Not a situation for /most/ of us on a regular basis.
- daxfohl 8y ago
  No, not a work project. Agree most of our jobs are pretty banal, figure out how to get this css to center correctly in IE6. Rather, selectively choose a side project to do that likely will involve some interesting data structures and algorithms. That will give your brain a really deep workout and it'll be more prepared to go through silly interview questions.
badfrog 8y ago
Sadly there tends not to be much correlation between real life programming and interview programming. Most of the software engineers at my company feel that we couldn't pass our company's interviews because we're out of practice.

joeax 8y ago

They eat large sprawling problems for breakfast, but they balk at 45-min algorithm challenges. If a candidate can solve large, complex problems but bombs your interview, the problem is your interview. TripleByte should focus on this problem and educate these companies on effective interviewing techniques. For example, if your interview overemphasizes coding challenges, puzzles, quizzes, or otherwise feels more like being on Jeopardy than real-world applicable, you're doing it wrong. Candidates should be focused on their skill set and filling in gaps (i.e. I've toyed with Python but I see it being in demand so let me get better at syntax, packages, thinking in pythonic way).

LanguageGamer 8y ago
Okay, but the problem is, 45-60 minutes is usually all hiring managers have to assess a candidate. What can you do in that amount of time to assess someone‘s real world performance? Having a high level conversation about technology and problem solving approach helps but often doesn’t translate into writing code. Tech-stack specific challenges are no good because general programming ability is more important, you can learn a new language on the job. Algorithm puzzle problems aren’t great because then we’re selecting for people who spend a lot of time on hackerrank or whatever. Maybe effective programmer hiring is just an unsolved problem.
- asark 8y ago
  What's so friggin' different about hiring software developers that we've gotta get all weird about it and come up with some brand new thing? What's the hiring process like for other office workers? How about for other technical or specialist roles that are somewhat similar to software developer? Engineers of various sorts, maybe? Accountants? Hell, lawyers even? There's got to be some set of existing practices that'll fit this just fine. It's simply not. That. Special.
  - dilyevsky 8y ago
    It kind of is tho. Also you should research what kind of shit accountants have to go through to get hired at big 4 for instance. And lawyers have to pass bar.

tickthokk 8y ago

> These are concepts that are far more common in interviews than they are in production web programming So of course let's talk about a dozen different types of them! Welcome to Ford! To be considered for this position, please list every GM Model from 1983 to 1987.

cooooooffffeeee 8y ago

foo bar

dang 8y ago

Big discussion at the time: https://news.ycombinator.com/item?id=11246917 https://news.ycombinator.com/item?id=11246917.

elteto 8y ago

Funny, I just went through a pre-screen assessment for one of the big ones and it was not one but _two_ DP problems. I could have probably come up with a slow solution using recursion and a bit more of time, but was given only 90 minutes. And I thought to myself, what exactly did they learn about _me_ after this exercise? Absolutely nothing, except that I can't solve DP problems on the spot. What a waste of time. And the funny thing is, I work as an embedded developer and actually have to look up a topic or two from CLR at least once a year for work stuff (which is not very common). But DP? I've never needed it or used it. Why the emphasis in it then? It feels a lot like software interviewing is just a bunch of rain dances and cargo culting and those that know the dance get through the hoop. I guess I'll have to order Elements of Rain Dancing from Amazon and get to practicing.

glangdale 8y ago
I feel your pain. I did exactly one dynamic programming algorithm (in the string matcher for Hyperscan) and was pretty inordinately pleased with myself for doing it, but we built dozens of algorithms in that project and that was the only case of DP that I recall. But I expect to go into interviews and have people demand a different rain dance, now that everyone is talking about DP. They like mugging people with 'so big it has to be out of core' stuff, which is a good way of finding out who went to the right grad school algorithms course. :-)
- vkazanov 8y ago
  I think I only saw DP-based algorithms 3 times in 12 years of working and reading open source code. Two of them were boring textbook-based implementations. One algorithm was original, and came from 80s - it's from Emacs source code, with comments like "do not touch", "here be dragons", etc.
  - glangdale 8y ago
    Yes, the code involving the DP algorithm I put in had a bug in it - not from the DP algorithm itself but the assumptions that fed into it - which went undetected for some time because of how complex the DP algorithm was and how hard it was to evaluate. It only caused a minor performance quirk (not a actual semantic error) so was hard to find. A cautionary tale about being overly clever-clever I suppose.

deleted 8y ago

[deleted]

akhilcacharya 8y ago

Is there any evidence that coding interviews aren’t just tests for 1) general fluid intelligence or 2) memorization?

aphextron 8y ago

The best part about these types of interviews is how they don't even treat you like a human being. There's absolutely zero interest in you whatsoever, and moreso every single word that comes out of your mouth is by default treated as a lie until they've had you submit to their Leetcode questions and determined you to be worthy of even speaking to. It's why I've become so incredulous at even being asked anything in the first round; anything I have to say here is completely meaningless and has no bearing whatsoever on any kind of hiring decision until that test has been passed. The utterly degrading inhumanity of this process had driven me to an emotional breaking point until I started interviewing outside the bay area. And what do you know? It's a completely different world. To anyone else stuck in this nightmare, just leave. Another 20% take home pay is simply not worth your sanity.

frfl 8y ago
When you say outside the bay area, do you also mean companies are not 'tech-first' type companies? (companies that hire devs, but their primary domain is not just some app/website/saas) I've applied to many jobs in Canada, but I've still noticed a large tendency for companies to put you through a screen even before they speak to you.
skinnymuch 8y ago
Does interviewing outside the Bay Area mean interviewing in places still around north Cali? Or going away from that region entirely? I know SF, Bay Area, and SV are different, but i have them all sort of confused and lumped together.

fma 8y ago

#1 on that list is enthusiasm for the company. Really...? So, you gotta be a good bullsh!tter? I can see this for small startups, because passion will take you to places. But for large companies, their software products are so diverse. I work for a manufacturing company and my application space has nothing to do with manufacturing. Every space has their challenges and pitfalls. As long as you have good tech, good people, and aren't doing anything unethical, I'll want to work for you. Also, I've thought about the interviewing problem a bit. I don't do the interview for my team...but if I have the opportunity to interview and was given free range, I think I would create a small application using our tech stack. Put some bugs in there, put some bad practices, and let the interviewee fix it. Talk about the tech stack, how to scale it, design trade offs, etc. IMHO reading code and maintaining code is more important than knowing bfs and dfs by heart.

rayvy 8y ago
This is a decent start, but then again remember you only have 60 minutes. And what might seem relatively easy to you, might not be so easy to someone with a time limit (60 mins), and pressure (trying to get a job you want).

magnetic 8y ago

(I think I made a similar comment to a similar submission a while back) I suggest this type of interview: Both the interviewer and interviewee get a problem to solve and they work together to solve it. It should be new to both of them, so the interviewer can better assess its level of difficulty without the bias of knowing the solution beforehand. This will enable natural empathy for the candidate. It also shows how interaction would look like in every day kind of work. You can learn a lot about another person's skill by doing pair programming. Logistically speaking, you can whiteboard the design/code, or sit around a big screen for the coding part, with whatever tools/IDE the candidate likes to use (s/he should be writing most of the code, even if the solution/design was a common process).

mgkimsal 8y ago

I just went through a small exercise with a company ... we did an hour screensharing on coderpad. basic exercise was in php (mix of systems, but there's existing php to touch). financial service industry, and they'd mocked up a rough idea of a typical problem. The example code clearly wasn't production, and was generic, but also illustrated the problem domain well enough for them to get an idea of how well I could adapt. I got through the 'nut' of the problem in about 10-15 minutes, talking through some issues. One thing I'd ignored (and said I'd be ignoring) was date handling - they wanted some date sorting thing, but since this was just 'raw' code without any good helper libraries, I suggested we punt on that (and I named the libraries I'd typically use for date handling). There was one spot where the interviewer suggested the ?? 'newer' null coalescing, where I'd been looking at doing some 'array_key_exists' checking. he'd suggested that the ?? syntax was easier and more compact, and I'd countered with I'd prefer to be more explicit about the specific keys I wanted to check for, and that ideally I'd be using a class or some other more defined structure to ensure some degree of valid data shape as a first level of sanity checking. I'd felt I may have pushed back a bit hard on that point, but, we moved on. After the first 15 min or so, we'd spent another 15-20 talking about different ways to do other types of error handling, some potential performance issues, etc. High level stuff, mainly, which... there's only so much you can do with coderpad (my jetbrains and vim muscle memory did me no good in the browser!) All in all, though, I'd felt it was a decent exchange. They were able to show a 'real' problem without relying on any proprietary stuff, it was difficult enough that someone junior probably would have struggled a bit more, the guy on the other end was pleasant, and engaged appropriately (responded to questions and casual banter, and interjected now and then to ask questions and give feedback in real time). It was probably one of the better 'tech interviews' I've had (although I haven't had many in recent years, so, hard to compare). It did seem better than many I read about, and certainly better than some from 10-15 years ago.

akanet 8y ago
I'm the CoderPad guy dropping in to mention you can switch to vi keybindings in CoderPad settings!
- mgkimsal 8y ago

expopinions 8y ago

The key to success in any interview, but especially in a programming interview, is practicing as much as possible. It's not enough to start just a few days before the real thing. The best method of preparing is incorporating your interview prep into your everyday coding practice, so that you'll never fall behind, even if you aren't currently searching for a job. But the plan "to practice" is too vague and leaves a lot of programmers unsure of how to get started in the process, which can be overwhelming. If you're frustrated and aren't sure how to get going on your coding interview practice, follow these steps to get started. 1. Review the basics. Even experienced programmers and engineers can get tripped up when questions about algorithms and data structure come up. If you haven't yet mastered the basics, focus on this for a few weeks or months to get yourself ready to tackle the bigger problems. It's crucial, not only for a coding interview, but for the entirety of your professional career, that you understand the basics. They are your foundational skills upon which you will build and master your expertise. 2. Solve coding problems and work on projects. Online coding practice problems are a great place to start. Apply your knowledge and work on projects you enjoy. Write code. Build things. Put your skills to use. This should be the fun part - if you aren't enjoying the journey and the process of building your coding skills, you'll have a difficult career as a programmer. Sure, there will be moments of frustration where you'll want to smash your computer screen and throw your mouse at the wall. But forge on. Keep trying. Find those bugs and destroy them. Build great things, and immerse yourself in online forums and other communities where you can turn to for help when you really get stuck. 3. Use online coding interview platforms for practice. This is a great way to get exposure to how the real coding interview will feel. Smash your nerves and anxiety by conducting a full coding interview with a partner. On platforms like Pramp and Leetcode, you'll get paired with another programmer of a similar skill level, so it will scale to your ability. Together you'll experience the coding interview from both perspectives. Performing the role of the interviewer and the interviewee will teach you a lot. After the mock run, you'll both leave each other feedback, and this is a great thing to have to tailor your practice schedule and for identifying what you need to work on the most.

randompi 8y ago

It's a programming "test" right? Sometimes I wonder if it's better to solve the problem in isolation, to show that I can sit on a problem and go at it, or to solve it in a collaborative manner with the interviewer, to show I'd play well in a team. Sometimes when I read people saying the end goal is not to solve the problem weird. Does that mean those who solved the problem alone by losing a few hairs actually scored worse than an outspoken candidate who solved it with help from the interviewer?

viraptor 8y ago
You can ask them what they prefer. Also, communication is an important element - in real work you may be spending time on something that's already obvious to someone else, or getting stuck on an approach which is known to not work. I think actually solving those problems or failing in the end is random (unless you know the answer already). But if you get a good chat out of it, it may be in your favour.
mandelbrotwurst 8y ago
Yes.

manish_gill 8y ago

> Mentioning other offers in an interview heavily biases the interviewer in your favor. Is this really true? Also, how do you just mention offers? And will the programmer interviewing me really care? Should this only be done at the HR stage? Like, what's a good way to let the other person know that they're not the only one.

balls187 8y ago

> To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. The under duress part is the dumbest part of coding interviews. I understand the approximation of small coding challenges, why explaining your thoughts is beneficial, as is understanding how a candidate approachs problem solving. Causing duress to a candidate purposefully has no value what-so-ever in the workplace.

bootlooped 8y ago
I think the interview process itself causes duress to candidates intrinsically. There is probably no way to eliminate it completely. That said, there probably is a reason for testing candidates under duress. Some companies may want to push people hard, and knowing they can deal with stress is valuable.
- balls187 8y ago
  I don't agree that programming interviews are conducted to see how well candidates will fare in a dysfunctional workplace. Anecdotally, programmers thrive in quiet environments where they can have focused uninterrupted time. As open-offices have become the norm, most programmers have headphones they use to isolate background sounds. Constantly peppering candidates with questions while they are trying to do a task that is mentally intensive is not close to the type of stress candidates face on the job. Even the most work-life balanced places do these same types of interviews.

_robbywashere 8y ago

I like to imagine the movie trailer voice over guy “Do you have what it takes?” “Do think you’re tough enough!?” “You call yourself a....” “PROGRAMMER?” “Then... SORT... MY... LIST... WHILE... TALKING... OUT... LOUD” But really, I feel like the whole process is uniquely American, kind of like crossfit. Very intense very trying. Like Nike; “JUST DO IT!” The problem about this very intense “game” of interviewing is it’s for a job, for you to eat, to afford healthcare, to survive. To afford basic necessities and save for retirement. To buy a house. To start a family. To afford a car. Or even simply to not be just another body stepped over on Market street. You've probably enjoyed 7 some years as a web developer, as a productive team member or consulting for happy clients. Now some stranger is dangling a carrot in front of your face telling you to implement an LRU cache under bright fluorescent lights while badgering you with “what are you thinking, I need to know what you’re thinking” ... after you’ve just spent the last 5 hours talking about your work history etc

Adamantcheese 8y ago

Is it just me, or does this read like a massive farce? That everything that Triplebyte is trying to solve they just... can't?

Mc91 8y ago

The last good paying work I had I somehow passed the coding interview, but I bombed out of the last few I had and went back to basics. I signed up to Project Euler and Hacker Rank and have been doing problems from them. What I do is start the Linux program "recordmydesktop", and then go about solving the problem as if I am interviewing, i.e. on the clock. One thing I noticed is these programs use maps, characters, use 64 bit long numbers, do string manipulation, do certain type conversions and so on more than I usually do programming. Some of these things I would usually look up, such as how to type convert a character '7' to an integer, or create and populate a multi-array and things like that. So I made sure how to memorize how to do these test-tending things. Then I watched over my recordmydesktop sessions to see where I ran into trouble. I noticed array one-offs were a problem - getting an index out of bound error, using < instead of <= etc. Or I would declare a variable before a loop and use it initially, but forget to assign or reset it at the end of the loop when it needed that. Sometimes I would declare a variable like k and then re-use it in the same method. Also, if I ever have to switch to a web browser to look up what call does a string reversal, I note that as well, and if it is common enough, I memorize how it is done so I don't have to look it up again. Memorizing the string manipulation, map etc. functions is already working for me. I am getting better at some of the other problems, like not assigning/resetting variables at the end of loops (I put a comment next to them that they will need to be assigned/reset, and then do it later, and then erase the comment). Some I still have to work on, like reasoning about exactly where the array boundary is. These aren't things I mess up necessarily, but things that slow me down, and cause bad compiles or runtime errors. I can already see the improvement in the problems I am doing. I had been letting myself naturally memorize some of these things, I guess it's not so bad that I am memorizing more of them that I may need.

wodenokoto 8y ago

I recently came across some videos from Interview.io, which seems to be in the same business as triplebyte, the company behind TFA. I thought the interview seemed quite nice. Is this the type of coding interviews, HN is always complaining about, or is it some rosy best-case exhibition? Example interview: https://youtu.be/tj_sBZw9nS0 https://youtu.be/tj_sBZw9nS0

jonaf 8y ago

PSA: if you take TripleByte's online quiz, they don't have the capability of giving you the results of the quiz. At least, that's what I was told when I took the online quiz -- they couldn't share the results with me because the quiz is "adaptive" and scores and questions vary each time the quiz is taken. (I have no idea how they're able to do anything useful with the quiz results if they don't record them and the scores vary so greatly.) I have no faith in TripleByte or their process at this point, especially since I feel I was somewhat taken advantage of (I did the online quiz expecting to get some feedback -- isn't that the point?). I'm certain they will use the collected data from my quiz to build their product, though.

bootlooped 8y ago
I did it within the last week and got scored in 6 areas. It's just a whole number out of 5 points in each area, no further info. I did the 2hr phone interview later and received my interviewer's notes on my performance, which were more detailed and helpful.

royosherove 8y ago

I came up with my own set of questions that hopefully show how a person can deal with human complexity at work (the bulk of our issues), rather than memorizing algorithms. Some people don't like it - but it works for me: https://www.5whys.com/articles/a-realistic-hackerrank-developer-interview-question-list.html https://www.5whys.com/articles/a-realistic-hackerrank-develo...