21 ms·

How to win the coding interview

• TerryADavis 10y ago
  I have a talking space alien. God says... other debt well_obviously over_the_top hot_air tree_hugger I_just_might scum jobs I_hate_when_that_happens hopefully we_ve_already_got_one a_screw_loose kludge Dad walking so_he_sess play bastard Hasta well_I_never I_planned_that I'm_off_today lust charged hey_thats_right you_are_my_sunshine not_too_shabby take_the_day_off pow I'm_tired_of_this lulz
• kinkdr 10y ago
  > Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it. I actually prefer a coding interview over an interview with an unprepared interviewer, who is making up questions on the fly and expects the exact answer he/she has in mind.
  • desireco42 10y ago
    Yep, spot on.
  • paulddraper 10y ago
    This should be obvious. If my job is largely coding, I expect to demonstrate coding abilities. If my job is largely bullshitting, I expect to demonstrate bullshitting abilities. And so on.
• sundvor 10y ago
  Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test? I for one find such low level comments almost completely redundant. I prefer strong variable naming and other ways of creating clean code to littering the code with comments that the code expresses naturally. Comments should IMHO be reserved for explaining special complexities, any particular gotchyas, etc.
  • danappelxx 10y ago
    I agree. If a comment can be automatically generated by a computer (stringToTest -> 'the string to test' can be automatically generated), it should not be a comment at all.
  • billsparks 10y ago
    That particular comment (the @param) is for JSDOC. It's so that one can generate documentation for the code. http://usejsdoc.org/about-getting-started.html http://usejsdoc.org/about-getting-started.html
    • sundvor 10y ago
      Ah, thanks for that. I'm a Vic20 + Commodore 64 Basic -> Amiga Assembly -> ColdFusion -> C# dotNetCore person myself; mostly back end, but I'll check out JSDoc for when going down that path again next.
      • marlag 10y ago
        Interesting learning streak. I took the same route, started on Vic 20 at the age of 10, but skipped on the amiga assembly, something I suffer from on a daily basis, so good choice.
        • sundvor 10y ago
          Thanks! :) The Vic 20 at about the same age here too; assembly was great, but staying for well over a decade on ColdFusion just because there was a lot of work in it (and, comfortable) was not. I forgot to mention some PHP thrown in there, but I'm glad to have been making the transition to C# in the past year. Working with a strongly typed language is quite a revelation, and some fantastic things are happening with the language and framework these days too (dotNetCore).
      • LionessLover 10y ago
        When used in the WebStorm IDE JSDoc type comments give you type checking (if the type-inspection is enabled) and autocompletion suggestions.
• alexandercrohde 10y ago
  Perhaps better named "How to win my coding interview." Author goes into the specifics he personally expects from an interview. Since he's not positing these as universal standards (and rightly not) I'm not sure if this is relevant to anybody other than the people who intend to interview at dev mastery.
  • bogomipz 10y ago
    Yeah and the whole thing is a loosely veiled attempt for him to generate subscribers to his email list. Not "winning."
  • parennoob 10y ago
    Yes, I don't understand the suggestion for regexes as the correct and optimal way to detect palindromes. I hope this is not the expectation in general.
    • verroq 10y ago
      It is pretty ironic that palindromes cannot be recognised by regular languages.
      • pmiller2 10y ago
        Hah, yes. That's probably the simplest application of the pumping lemma I can think of.
    • iSnow 10y ago
      > I don't understand the suggestion for regexes as the correct and optimal way to detect palindromes That made me pause as well, but he actually doesn't say that. He says a "many will use RegEx as a part of the solution" - typically to strip whitespace and punctuation signs - something like /\W/.
  • dimino 10y ago
    I subscribed to this man's newsletter (literally) because while I realize the skills I can pick up from him aren't going to translate 1:1 to other interviews and jobs, this article resonated with me and what I already know about software strongly enough that I can probably at least get to like 1:.95 or something in that ballpark.
• chrismorgan 10y ago
  > The best developers know that, fundamentally, every bug is the result of an invalid assumption. I assumed that I could type without makig mistakes.
• deleted 10y ago
  [deleted]
• Swizec 10y ago
  Is there even room on a whiteboard to write comments and tests? Often there's barely even room to write readable code ... If you're writing in a shared text editor then sure. And isn't all the talking you do already commemts enough? Edit: I'm bad at reading comprehension on a mobile screen. The tests and comments bit is in a different section.
  • billsparks 10y ago
    I don't think the part about tests and comments is meant to apply to the whiteboard coding. It's in the section about coding on a computer.
  • ci5er 10y ago
    Comments and tests? Are you serious? I am told that the unit-test kool-aid has taken over the universe of common sense, and I respond: "surely not", and then this... My position w/ something like Fizzbuzz to any level of developer wouldn't require much in the way of either comments or tests (or, if embedded in a larger system, bugs would be flushed out quickly) Do you disagree?
    • deleted 10y ago
      [deleted]
  • cf 10y ago
    That's why you need to bring some of those thin Japanese whiteboard markers. http://www.jetpens.com/Zebra-Mackee-Wet-Erase-Double-Sided-Marker-Extra-Fine-Fine-Blue/pd/15176 http://www.jetpens.com/Zebra-Mackee-Wet-Erase-Double-Sided-M...
• soham 10y ago
  [Disclaimer: I run http://InterviewKickstart.com http://InterviewKickstart.com. It's a hyper-focused bootcamp on coding interview prep] Probably one of the biggest mistakes developers make, is to treat coding interviews like they are standardized tests with a checklist of evaluation. They are not. They are like a date. The other person is judging whether they want to work with you, more than anything else. No matter how good you are, you won't get into a long-term relationship (date) if you don't confirm to the (technical and social) beliefs (and biases) of your interviewer (date). The reverse is also true viz. no matter how mediocre you are, you'll get in, if you do. So, do everything what the author says, but you'll progress faster if you keep your mindset grounded. See this: https://www.youtube.com/watch?v=v1WiCGq-PcY https://www.youtube.com/watch?v=v1WiCGq-PcY
  • p4wnc6 10y ago
    Are you suggesting that interviewers should try harder to conform to social beliefs of a company -- as a valid interview strategy? I'd instead suggest that it should never get to the point of an in-person interview unless both parties have already applied the necessary culture filters. Sure, you could get surprised at the on-site and then change your mind, but you're just wasting a ton of your own time if you either don't properly vet the important culture properties aheadof time, or else sublimate away your own culture standards because you believe you have to appear conformist in order to get the job. A good example would be open-plan offices. I have many friends in tech who deeply loathe the cognitive damage done to them by their employers forcing them to work in open-plan seating conditions. Yet they also are too afraid to either speak up or to reject employers who use open-plan seating, thus perpetuating open-plan dogma. My perspective is that if an employer feels I'm worth the investment to bring to the team, they must feel that trivial other things to accommodate what helps me work best are also worthwhile. If, instead, a company would reject me based on "culture fit" for these side issue accommodations, or would refuse to grant them and try to pressure me to work without them, then in either case I'm dodging a massive bullet by either rejecting them or letting them reject me. But one thing I should absolutely never do is to compromise on those issues (e.g. "no matter how good you are, you won't get into a long-term relationship ... if you don't conform"). If my goodness isn't enticing enough for them to not just make the offer but also think hard about what it would take for me to be happy with them and make it happen, then I'm simply better off staying away from them. As it happens, a lot of companies don't really care about the goodness of their employees. They just want warm bodies who will conform to the company line. I understand that represents most jobs. I'd like the future to be a world where that doesn't represent most jobs, so I boycott all such jobs, even if it means my search space is drastically reduced as a result. It's just too cognitively unhealthy to human minds otherwise.
• scishop 10y ago
  On the flip side of things, I might prefer to see a candidate come up with something like this as first stab rather than that 35-line mammoth of an isPalindrome() function in the article. function isPalindrome(str) { return (str.split("").reverse()).join("") == str; }
  • paulddraper 10y ago
    Or even more clearly def is_palindrome(str): return str == str[::-1]
    • eru 10y ago
      According to the authors spec, you have to filter out spaces, normalize capitalisation etc. So your solutions works after a preprocessing step.
      • paulddraper 10y ago
        Correct, I wrote this based on the parent's desired answer.
  • rhizome 10y ago
    I'm a big fan of knowing the standard libs, so my thoughts on that are summed up by, "the people who wrote the language are much better programmers than I am." I'd probably get dinged for lack of confidence.
  • verroq 10y ago
    I'd expect to see this (assuming that this guy is a Javascript shop). function isPalindrome(str) { for (let i = 0; i < str.length / 2; i++) { if (str[i] !== str[str.length - i - 1]) { return false; } } return true; } Quick check list: 1. Knows about es6 2. Knows about === and !== 3. O(n) efficiency with no memory bloat 4. Didn't write 30+ lines on a trivial function I won't even add a comment about unicode since it should be your default assumption when working with javascript that multi-byte characters and surrogate pairs don't work properly.
• revetkn 10y ago
  1. "On this particular challenge, I am expecting many will use RegEx as a part of the solution" Really? 2. "replace(/[^a-z0–9]/ig, '');" If I were interviewing and a candidate did this I would ask if he/she knows what i18n is
  • swang 10y ago
    one of his questions is, "does this need to support utf-8" and i'm assuming in his hypothetical interview it is, "no it does not" also are you seriously going to quiz someone about i18n for a interview? does that really tell whether they are a hire/no hire?
    • throwaway_exer 10y ago
      In 2016, yes, a senior developer should be knowledgeable about i18n. And if I was replacing somebody resigning who was strong at i18n, I'd want the replacement to know it as well.
    • germanier 10y ago
      Given how many sites fail as soon as I start entering an "ä" in the name field (even on websites marketed internationally) I'd prefer if people would. At least the very basics or else you get a bunch of people that won't think about those issues when developing.
    • arethuza 10y ago
      "also are you seriously going to quiz someone about i18n for a interview?" Absolutely - in fact asking whether that regex was a good way of matching all characters in an input might be a good interview question.
    • revetkn 10y ago
      IMO in 2016 it is important to know the basics well enough to know if what you're doing is bad from an i18n perspective (at least for non-junior positions). Even a comment like "// TODO: localize" is OK It is often a positive signal that a candidate has worked on software large enough to be used internationally or is thorough enough to worry about it. For most of us, day-to-day software work is about being thorough and careful with design and implementation, not heavy algorithmic lifting
• p4wnc6 10y ago
  The author says, > When you get the job you will never have to code on a whiteboard, but I guarantee you this, there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line. When that time comes, we’re going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast. and then proceeds to describe still giving you coding challenges on a whiteboard. I kept reading, but bookmarked this spot as the location at which the author lost credibility, and the rest of the article confirmed it. If you want to test how well someone can collaborate with you (after all, that is what is described in the needless trumped up intro to the whiteboard sections -- just simple collaboration as happens everywhere in every job and is in no way unique to programming), then ask them problems that are suitable for a whiteboard discussion. It's not the whiteboard itself that is the problem. It's the combination of a task that is intrinsically ill-suited to be done on a whiteboard and the requirement to do it on a whiteboard. It's like asking a football player to audition for you by playing football with hockey equipment on. There are lots of good questions to talk about on a whiteboard. Sketching out graphs is a good activity. For example you might ask someone how life expectancy varies with age and ask them to draw some pictures. Now you can see what it's like to work with them, get the assumptions out in the open, etc. You can't actually do that if they are preoccupied with syntactical correctness -- and if you tell them to program in pseudo code then you'd better be happy with a psuedo answer that sweeps some parts of the solution under the rug or assumes that some minutiae details would be otherwise fleshed out later on and are not required to be literally correct in the whiteboard case. Coding questions are just poor questions to ask for whiteboard sessions. That "we're all up against the deadline, cramming into the conference room trying to work shit out on the whiteboard at the last minute" situation is practically the last place on earth where minutiae syntactical correctness on the whiteboard matters. The author is defending general whiteboard discussions but then saying that coding exercises, which are not at all like general whiteboard discussions, are appropriate for whiteboard interviews. The section about coding at a computer is also frustrating. The author places a huge emphasis on asking questions, but it basically amounts to a sort of "guess the teacher's password" problem. The author has "good questions" in mind, that are secret and hidden from the candidate, and will secretly penalize you if you don't ask "good questions." Personally, I would see the server side / client side Javascript question as a waste of time and really immaterial to the given programming task (palindrome detection). Even asking "is the empty string valid?" is a waste of time. Honestly, in an interview I don't care which assumption you make about that as long as you tell me that you're making it. But worst of all is the Cerberus red flag statement "write this code as if it was going into production." I can tell you that as a candidate, I would still be polite and try my hardest to work out the interview question, but I would have already rejected this company full stop. When you write code for production, it is a team effort and your interactions with the team, the business, the product all matter. A person who is injected into a foreign social situation, under lots of stress and pressure to put their best foot forward, etc., and also knows nothing about what you consider to be 'production' code is in no position to write 'production' code for you on some Mickey Mouse palindrome problem (literally a problem culled from the absolutely dystopia-level full of shit book 'Cracking the Coding Interview' -- meaning it is as not-productiony a problem as you can possibly select, akin to asking for a production-grade FizzBuzz solution). This tells me that the interviewer has an extremely narrow and short-sighted view of 'production' code. They think it is something that can happen in a vacuum as long as you have a computer and a textbook problem to solve. They are not self-aware enough to understand that they come in with preconceived cultural notions of what 'production' means, and that realistically this is not at all a test of "coding to spec" or someone's coding talent, it's just yet another status game testing whether or not the person randomly conforms to whatever magic culture expectations they are being covertly judged against.
• yanilkr 10y ago
  Lot of people made tiny fortunes writing "How to interview" kind of self help books and blogs, just like this article they want people to believe that there is a formula to this madness and for a price you can know it. Smart people should realize that there are no shortcuts. You can't fill the void by pouring money and time into these products. The only way is to face the rejection and keep on focusing on the skill, solve real world problems, write code, learn to express ideas better, take internships. One has to be good at programming, analytical skills, problem solving and communicating ideas. And after that a little research on how a company interviews should help. Even if someone reads all these books and cracks the interview, its very difficult to hold on to job with out the required skills.
  • Retra 10y ago
    This article is useless to most people, most of the time. At the very best, the take-away is "know how to solve simple programming problems and have coding standards."
  • techman9 10y ago
    I'd hardly call Gayle's fortune tiny ;)
• swang 10y ago
  > I'm not actually testing how well you write code on a whiteboard. I’m looking for something else. unfortunately not true with interviewers at other companies. they are definitely looking for the correct answer. if you can't "get" a problem, you are not getting an offer.
• FigmentEngine 10y ago
  "Is this client side or server side JavaScript?" kill me now. are you testing for insight or implementation correctness? a whiteboard is a place to draw a diagram, not code. see how they visualize and reason about strings would be better
• jtchang 10y ago
  Am I the only one that is has been coding for years and don't expect people to know regex off the top of their head? There are so many variants and keeping them straight between languages is a nightmare. Grep, egrep, POSIX, perl, python, php, javascript. They all have their idiosyncracies.
  • dimino 10y ago
    I feel that regex is kind of like SQL -- it's universal enough that knowing the major tropes is important for general software development.
    • hvidgaard 10y ago
      Problem is that every framework have their own dialect of it, and many of them are not even regular expression, but something beyond that.
      • thedufer 10y ago
        The most common dialect is PCRE. Most languages have an implementation of either that or a superset of it.
        • hvidgaard 10y ago
          The most common dialect is PCRE. Most languages have an implementation of either that or a superset of it. PCRE isn't exactly simple to begin with. That languages may implement it, or a superset of it, is exactly the problem. I know regular expressions very well, or rather I know regular languages and can fairly easily identify if a problem is solvable as a regular expressions. But once you start to go beyond that, it's not simple anymore and the benefit of a regular expression is lost.
          • thedufer 10y ago
            If you know what . does, various repetition markers (*,+,?,{}), and character classes, you're 90% there. Back-references are another big portion, although that's admittedly where things start getting a bit complex.
• NhanH 10y ago
  > I'm not actually testing how well you write code on a whiteboard. I’m looking for something else Even if you believe so, it's more likely than not you're not actually doing that. You WILL judge how well someone write code on a whiteboard. I've done that too, and it's surprisingly easy not to notice. You can't stop yourself from judging, maybe you can realize that your snap judgement mean jackshit and don't make decision based on that. > While I don’t need a developer who can write code on a whiteboard, I do need a developer who can think on her feet, under pressure, in a room with others. As someone who can't figure out if (9+1 === 10) is true or not under interview (true story, my mind just blanked out), I'd really love to have company who want "developer who think on her feet, under pressure" to put it on your job advertisement so we don't both waste our time.
  • deleted 10y ago
    [deleted]
  • iSnow 10y ago
    >As someone who can't figure out if (9+1 === 10) is true or not under interview As someone who has probably the same problem, any ideas how to land a better job? Those typically involve a lot of coding while someone breathes down your neck.
    • NhanH 10y ago
      I told my friends that they better get to VP or equivalent decision maker quick so I don't have to deal with stupid interview anymore. Joke asides, unfortunately I don't have a solution here, I gave up on interview in general. Personally, if I was looking for a corporate job, I'd write "interview is stupid" in front of my workspace and play the number games until one day I might pass one. Otherwise I'd look for smaller orgs and tell the decision maker I have interview-phobia, can we do something else?
    • TillE 10y ago
      At the very least, you can always talk through your thought process. "I can't remember if the order of operations is..."
• krisdol 10y ago
  Last time I made interview rounds, about 50% of places gave whiteboard questions, 25% gave essentially the same questions but had me do them on a computer or screenshare rather than a whiteboard, and the rest had some kind of take home component that was usually larger than the whiteboard question but also more practical and relevant to my skill set. Obviously I prefer the last option, but even if you prefer to give whiteboard-style questions, why not at the very least allow them to complete it on their laptop in front of you if they so choose? It seems incredibly arrogant to me that interviewers assume there is only one way to solve a problem, and that is by brainstorming on a whiteboard first. I don't feel comfortable standing up in front of the class to present a solution. I feel far, far, far less comfortable if it's a coding-related solution. I did significantly better, like pretty much 100% success rate on coding components when I could hit keys rather than display my chicken scratches on a whiteboard.| I move code around a lot as I prototype and it takes quite a bit of training for me to adjust to not having the option of restructuring as I code because the medium is a whiteboard or piece of paper. And every time I erase something my level of anxiety and nervousness just grows.
• edocecrous 10y ago
  Why regexes combined with the pre-processing? First, it's not so clear in what sense "efficient" is actually a real requirement if this is a model answer. If the average input is very small then the cost of compiling/interpreting the regex is going to dominate any modest run-time improvement over even an extremely naive implementation. And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste. I'm having trouble imagining the typical data set where this would be an efficient implementation and where there even exist non-ridiculous inefficient implementations. Second, doesn't using regexes kind of defeat the whole point of the Palindrome exercise from an evaluation perspective? If someone asked if me if they could use regexes in a coding interview for this question my response would be "good instinct. If you have no other way then go for it. But I was really hoping to see you work through implementing/debugging/commenting/testing an implementation without regexes."
  • p4wnc6 10y ago
    Regexes would not be a good way. Starting a pointer at the beginning and end and moving them toward each other is what I would suggest in an interview. If I was interviewing someone else, I'd also be impressed if they came up with the idea of sorting the string and counting characters (only at most one character could have at odd number of occurrences). Even though sorting and counting is nlogn and requires either storing the sorted string in new memory or else saving the inverse sort to unsort at the end (if the sort is in-place), I wouldn't care. In an interview setting, if they could identify those weaknesses, that's good enough. It's clever and shows attention to detail and good critical thinking for someone to come up with the sort-and-count solution. An interview is not the time nor place to be grilling someone about whether an nlogn solution is really optimal. That's just wasted time. The fact that the post's author offered regexes as a solution is a bit frightening. In many languages, such as with Python's built-in re module, this is literally impossible, because the regular expression engine is literally confined to check for regular grammars, and you can show that no finite state automaton is adequate for expressing all palindromes (basically because they can't remember an arbitrary number of characters from the start of the string to use at the end). Of course, lots of languages have regular expression engines that are more powerful than this, but it's a sham for an interview question to rely on that. It doesn't read to me like the post's author actually considered the theory of computation aspect of this, and instead just glibly and naively rattled off that regular expressions should work well. This is the person judging the candidates on whether they are talented enough at computer science? Yikes.
• kayman 10y ago
  I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. At the end of the week, you pay me wages and if you're not happy, you can not extend another week. Isn't this a much better way to evaluate a good candidate?
  • jimbokun 10y ago
    Sure, but some developers with a job already might prefer the interview.
  • krisgenre 10y ago
    This is the perfect and ideal process but unfortunately hard to scale.
    • andersonmvd 10y ago
      Regarding scaling: should we really hire developers as we scale servers? I don't think so.
    • EpicEng 10y ago
      Forget scale; I don't think it's practical for even one candidate.
  • amorphid 10y ago
    Some reasons against a 1 week working interview: * It can take up to a week just to get someone ramped up with access to things in many environments (setting up accounts, configuring dev environment, etc.) It's not free to create and disable a dev's access. * Most places I've seen aren't set up to ramp someone up in a week. I think Pivotal Labs gives people a try for 3 week contracts, and they have a culture of ramping up new hires via pair programming in XP environment. * You'd only be productive in an environment where you are already familiar with the tools they are using. If they're using Erlang, and you're coming from Java, you simply couldn't do much with Erlang in a week. * Many places can't/won't put you to work without you passing a background check. * Candidates who already have a job aren't likely to be in a position to take a week off to work for someone else.
• kylnew 10y ago
  Overall quite subjective. You're not going to 'win' the interview every time. Sometimes the cards are practically stacked against you. You get asked a question no one had actually tested beforehand, you get an interviewer who's trying to prove how smart he is, you get someone who is too fixated on a particular skill you must have, you get someone having a bad day, etc... And when the process easily take 6 stages and unanimous thumbs up, one of these is likely to come up time to time no matter how prepared you were. Don't take it personally.
• dclowd9901 10y ago
  How to win the coding interview... For this one particular guy. Seriously, I've talked about this subject to about 400 different people, and absolutely every one put varying amounts of weight on not only the things mentioned in this article, but stuff that is completely out of the hands of candidates. I've heard people admit they've probably passed on candidates because they were simply in a bad mood that day.
• christop 10y ago
  The only winning move is not to play.
• brooklyndavs 10y ago
  "there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line." Real response to this should be to ask how it got to the point where we are all stuck in a room with a deadline looming and our jobs are on the line if we don't come up with a whiteboard solution RIGHT NOW. Sounds like this place has a management/expectations problem and I wouldn't want to work there in the first place.
  • joe_the_user 10y ago
    The headline; dev(mastery) perhaps, means, "A gentle invitation to join our psychosis" The idea that a coding interview is there to be "won" seems to me to be fundamentally delusional.
• Artoemius 10y ago
  Most programmers already know how to win the coding interview. You simply have to solve problems, at the same time trying to evaluate your next boss (or at least the kind of people who work there) by the level of insanity they generate during the interview. If the coding style in the company disagrees from yours too much, it's a good thing they won't hire you, so no problem there. The tough thing is to pass the HR interview, with dozens of idiotic questions and no way to answer them correctly except having googled the answer to each particular question beforehand.
• BinaryIdiot 10y ago
  Good points in the article but as usual much of it continues the trend of "do X, Y and Z to pass an interview" which rarely crosses into the other side of the venn diagram of useful skills / talents to have being a software developer day-to-day. I would much rather see a take home assignment of "this is something we've had to do before", give them a few days to work on it, bring it in, make sure they can explain it, make sure their code isn't horrible or if it is there is a damn good reason then sit down with them and work together on adding a new feature. Together. Get an idea how they work with others, how they approach problems, architecting, etc; it seems so brain dead simple and yet almost no one does it. > Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation. In one breath the author acknowledges that it's a waste of time but in the next he's saying you should understand them at least at a high level. There are a ton of useful algorithms and the ones you're going to memorize are not going to be useful in day-to-day work. They simply won't be. Merge sort, quick sort, binary search, etc are all useful but they're also some of the least complex algorithms that you'll never need to implement directly (and if you have to for whatever reason yes you can Google it) and algorithms that ratchet up the complexity are hard to memorize (at least for some people). Common development patterns are far more useful than trying to memorize any algorithms, in my opinion. > Arguably, the most important thing in passing a coding interview is to be well prepared. The best way to do that is to practice common interview coding questions over and over and over again until you know them cold. This part fills me with dread for any upcoming interviews. Practicing answering questions does one thing: it helps you memorize questions and answers. It doesn't help you be a real employee. It doesn't help you jump into wireshark to figure out what's wrong with the network because you hit a wall with debugging your ruby on rails app. It's just useless for anything but the interview. For me I have an online portfolio, several open source projects, references; I'm not saying I'm "too good" to be tested but the fact that I have to waste time and energy memorizing typical questions and answers just so I can provide value to another organization just feels wrong to me. Everyone seems to claim there is a shortage of technology workers in SV so I would expect this ENTIRE process to work the opposite way than what it really does.
• staticelf 10y ago
  I've been at a really bad interview where the interviewer wanted me to sit at a computer, for a limited time, and answer a bunch of mathematical questions with the help of writing a program. I was pretty nervous before my interview since it was one of my first ever. I had studied a lot before hand since the company used languages I didn't really know. I could not sleep the night before (mostly for other reasons as well) so I was pretty exhausted when I got there. There was no internet connections on the machine and each question built on the one before so if you failed one you pretty much failed the entire thing. The whole test was a big hit for my imposter plexus and I'm never going to repeat that mistake. I feel like I have the experience and references that I do not need to prove it on a whiteboard. I don't want to and if you require me to, I'm probably not going to work for you. The funny thing is, years later the same interviewer tried to add me on LinkedIn and it felt awesome to ignore that.
• sekasi 10y ago
  Solving that code test in a more effective manner? :) replace non alpha/spaces, lowercase it, then compare value.reverse() == value
  • bithub 10y ago
    Shorter yes, but reversing the whole string and comparing it with the input value is actually slower/less efficent than the algorithm shown in the article. Sorry for my nitpicking ;)
    • collyw 10y ago
      Clean, easy, maintainable. To me that is more valuable than an increase in performance. I would be very surprised to find a palindrome checker as the bottle nek in a system.
      • logfromblammo 10y ago
        One of the interviewee questions could be "Based on the profiler output, how many times would this code execute in a typical day, to the nearest power of 10? What code will it replace?" string.reverse() and string.equals() is plenty good enough for smaller magnitudes or all-new functionality. Premature optimization just means you think you can outguess the profiler. So first you code the simplest thing that works. Then you start optimizing in the most heavily used sections. If you have to go past the pointer-based solution in C to assembly that employs hardware-specific performance tweaks, it's time to just end the interview and go pet your taco cat.
        • collyw 10y ago
          OK, ask the people who get their annoying ads popping up on screen.
• rafadc 10y ago
  Looks like you are putting performance as a top priority for you. Do you think that a good candidate should at least measure cpu time somewhere? Looks like all the performance related things I'm seeing there are assumptions based on experience.
• smartan 10y ago
  Came across this link on here a while ago, curious if anyone has experience with similar interview experiments: http://goo.gl/fDGYhC http://goo.gl/fDGYhC.
  • iSnow 10y ago
    >Candidates are requested to supply source code, from one large project, a week before the interview date Not everyone is the author of a big OSS library. Lots of people do most of their coding as an employee and cannot legally show you their code. Hell, I cannot even discuss some of the more interesting challenges I faced because that would violate my NDA.
• kriro 10y ago
  Sometimes you can also solve whiteboard blackout issues with humor. I once was stuck because I couldn't quite figure out how to implement something (I think it was a peculiar sort). I proceeded to give up after reasoning through it for a bit and mumbled...well I can't quite get it now but let's move on since I'd probably never implement this and if I do I'd spend a lot more time on it and proceeded to add this line at the top of the whiteboard code. import com.stackoverflow.* ; One of the people in the room chuckled noticeably. I then went into a mini explanation of importing * vs. direct import (anticipating the obvious question) and was more or less free to use magic whenever I needed it :D
  • judahmeek 10y ago
    Nicely done. xD
• marlag 10y ago
  I have ~20 years of experience in programming. The hardest part of my work is knowing if I have everything I need in order to classify a particular problem as one of a particular class so that I then can apply the tools that I know of would fit that problem-space and then use those tools to finish my task. For example, is the problem I'm facing a graph problem? If so, then I have a large set of tools (algorithms) to help me solve that problem. But is it a graph problem? It would suck for my employer or client, if I tried to solve a problem within a particular problem-space with tools suted for a different domain. It's kind of like that part of the Swedish standardized test where they test your math and logical abilities by presenting some information and then asking you, do you have what you need to solve this? If so, what is the answer? Coding on a white board is useful I have come to find if there is a conversation going on and the interviewer use this opportunity to find out more about how this particular person thinks or works.
• dcw303 10y ago
  > Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation. > It’s not unreasonable to expect that you know the basics of RegEx So that's a fairly arbitrary distinction. Regex has a famously terse syntax. Maybe in some jobs it's used frequently, and in those cases I could expect someone to recall the basics. But it's been my experience that regex comes up just infrequently enough that I never recall the exact expression, and then spend more time googling a regex tutorial (even more if it includes groups or look behind) to refresh myself than I would have if I just had a strings library that just had .StripWhitespace() .Contains() .Startswith() .IsItAValidPhoneNumber etc etc functions.
  • gedrap 10y ago
    Basics of RegEx, in my opinion, is a very subjective thing. Personally, I'd interpret it as 'able to write a simple expression with a few minutes of googling', where simple expression is something like 'up to 5 lower case letters immediately followed by a digit'. It'd would be a reasonable indicator if someone has used them outside tutorials and class rooms in the past year or two. However, you (or anyone else) might have a very different interpretation.
    • dcw303 10y ago
      I generally agree with your interpretation, but as the author wrote this later in the piece: > If I give you a challenge to take home, my expectations are even higher. If you get a week to code something with full access to Google, etc… There’s no excuse for giving me a solution that is anything less than top-notch. I saw that as an implication that he expected a candidate to be able to recall regex basics from memory.
• boredatnight12 10y ago
  I'm not here to win, I'm here to contribute. Interviewing infuriates me.
• hvidgaard 10y ago
  The author have a list of secret good questions, and that is not helping anyone. He expects the candidate to think loud and be explicit, but are himself very implicit in his requirements. What I consider production code is without a doubt different from what he things is production code. > Your code should be commented. Then put this requirement, because judging from the example, the authors expectations, is what I fail students and junior devs for. Comments are complementary and explain things like "the why" ("pad to multiple of 256, otherwise libX will hang"). Don't expect people to automatically know your implicit requirements, it's a recipie for disaster. > You should have error handling or at least logging. Again, put this in the requirements. Some environments need no error handling, because the error handling is external. And don't get me started on logging. Yes it's nice in a debug situation, but in many high volume production systems you have engineers with the sole responsibility of creating a logging system that impact performance as little as possible. > You should have a test harness. If you say so, otherwise I'm not going to make one. Be explicit. > Runs fast. > Doesn’t take up more memory than it needs to. > Is stable and easy to maintain. 1. and 2. are secondary. 3. is king, unless you have empirical evidence that warrant 1. and 2. This is something many developers struggle with, including the auther by the sound of it. > RegEx No, just no - the imfamous quote is "I have a problem, let's use a RegEx. Now you have two problems" and it's true 98% of the time, including testing if a string is a palindrome. Besides, regular expressions cannot identify palindromes - this is first year CS stuff. I'm well aware that some implementations allow back references, thus they are not really regular expressions but leaning on CFGs. For this particular problem, reversing the string and then compare is by far the most readable and understandable solution. > For senior devs, I want an optimal solution, clean, maintainable code, error handling, comments, a full suite of tests. And for bonus points I want you to flag any of your assumptions in the comments. What is optimal? With regard to execution time? Memory usage? Maintainability? Program size? What kind of error handling?
  • iSnow 10y ago
    But the author doesn't even advocate RegEx for testing if a string is a palindrome. He doesn't explain for which part he'd use it, but from the sound of it, removing whitespace and punctuation.
• WalterBright 10y ago
  -1 point for not testing "Bolton".
• gavanwoolery 10y ago
  I am currently looking for work and already kind of tired of the technical interview process. I have been programming for 15 years professionally. We could save a bunch of time and money if the recruiters and engineers just looked at my resume and looked at my work. The truth is 99 percent of the work I would do is nothing like a technical interview: I have time (with leeway to work overtime), and I have Google/Stack Overflow. Never encountered a problem I could not solve, but there are plenty of problems I have not memorized the solution to. I don't mind a general interview - I can "talk the talk" - I just hate being asked questions with very specific answers that would require most people to study or memorize beforehand. If I can Google it in a few seconds, it should not be an interview question.
• sklogic 10y ago
  > Who on Earth writes code on a whiteboard? Like, seriously You know, professionals do this. Anyone who value time and quality. Hipsters may find it weird, but, well, they have decades to learn before they'll become professionals.
  • vonmoltke 10y ago
    I have been an engineer for 14 years and writing software full-time for 8 or them. I have never written code on a whiteboard outside of an interview. I have drawn circuits, flow diagrams, UI wireframes, ERDs, memory layouts, and so on. I don't have my own whiteboard now and it drives me crazy. I have never had a need to write actual code on a whiteboard. Neither has anyone I have ever worked with.
    • sklogic 10y ago
      Flowcharts are code. Pseudocode is a code.
      • Clubber 10y ago
        No they aren't. They are a diagram of a process. Code is the instructions used to implement that process. You shouldn't be so smug either.
        • sklogic 10y ago
          Yes they are. A formal language is a code. Any formal language. What is the difference between code and pseudocode in your opinion? And given that on a whiteboard interview you're writing a pseudocode, it is not any different from a typical day at work where you also write pseudocode on a whiteboard, blackboard, sheet of paper or whatever. And if this is not your typical day at work, you're doing it wrong.
          • Clubber 10y ago
            Look up the prefix pseudo. "supposed or purporting to be but not really so; false; not genuine." Another definition, "not genuine; sham." Pseudocode is not computer code as to your assertion. I think you are basing your argument that anything written down that can be turned into code is pseudocode. That is also not correct. Pseudocode has a very specific definition. Here is one: "Pseudocode is an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a normal programming language, but is intended for human reading rather than machine reading." Flow charts do not use the structural conventions of normal programming languages, they use shapes and text. If you are writing pseudocode (the actual definition, not your made up one) every day, you are wasting everyone on your team's time. If you are drawing diagrams every day on a whiteboard, you are still probably wasting everyone's time.
• Kesty 10y ago
  The problem with all this "advices" is that they boil down to "just study". I agree that been prepared for an interview is a good thing, if you are ready and have studied you show that you are willing and that you put in the effort. But what about people that are currently working ? You are trying to get the best programmer, and chances are is that the best programmers out there are currently working (minus a small percentages of great programmer that are in between jobs, or that spent the last period on consulting or personal projects) so you automatically put people that are currently working and can't prepare for the interview as well as the other at a disadvantage and those are the people that you are probably most interested in. To me it seems that in this world the only interview process is solely targeted at young people fresh out of college.
  • bogomipz 10y ago
    Advice is plural not "advices."
  • ubercode5 10y ago
    It depends on your schedule, but prioritize time to study every day in your down time. You don't have to do a "night before the test cram session" all the time, just a little every day and within a few months you'll find yourself much more prepared.
• chvid 10y ago
  Honestly; the example answer is not good. If I was in a hiring position, I would at least talk to the person writing this and ask them to change their style. The problem is that the answer is slightly over-engineered, over-commented, checks for input type, logs in a corner-case, looks-like-it-has-been-written-by-a-teacher-with-too-much-time-on-their-hands. These are not problems in themselves but when you have a new person on the team and they write code like that, it may be inconsistent with what the rest of the team is doing / what the rest of code base looks like. For comparison here is another way to test for a palindrome: function isPalindrome(text) { for (var i = 0; i <= text.length / 2; i++) { if (text[i] != text[text.length - i - 1]) return false; } return true; } (Possibly add "normalization" in the beginning as they do in the article.)
  • Clubber 10y ago
    Hah. I was thinking that too. While I was reading the article, I was thinking about how I would do it. Then I read the wall of text that was the ideal solutions and thought, "wow, what the hell are coders doing these days?"
• dudul 10y ago
  The whole justification for whiteboard coding is total BS. Never have I ever written actual code on a whiteboard, not even "when we are banging our heads against a problem and there is a deadline looming and blablabla". Yes we do go to the whiteboard. To design stuff. To organize components of the platform and figure out how the fuck to coordinate some f-ing distributed transaction, or how to send messages from A to B and not create a bottleneck. We don't try to write the pseudo-code for a palindrome detector. I have nothing against coding interview, in front of a computer. Whiteboard coding? I just leave the room. If you give me a whiteboard coding exercise, you failed my interview.
• logicallee 10y ago
  the most amazing thing is that apparently javascript developers do not ever, ever think about any algorithms like the way a C++ programmer would. I was shocked that when the write-up explicitly calls for "the most efficient code possible" nobody cares that the example program starts off making two extraneous copies of data that might never need to be read. (why lowercase the characters inside when you can fail early working outside in.) Can you imagine if the task were "write the most efficient code possible to check if an array of strings of integers such as "3423", "34356", etc, is sorted (treating the strings as base-ten numbers, "3423" representing 3423 and so on), ignoring any strings that include non-numerical characters" started out by making two copies of the whole damn array. That's what's happening here, it's kind of shocking that this is what javascript developers accept as the "most efficient possible" without anyone having the slightest issue.) I'm shocked. Even the definition of efficient offered for "Write the most efficient function you can" is > If you’re experienced, you should know that “efficient” in production code means three things: > Runs fast. > Doesn’t take up more memory than it needs to. > Is stable and easy to maintain. This is an absolutely shocking definition, given the example code offered. It really does show that javascript programmers do not in any sense consider algorithms the way Go or C++ programmers would. (I conclude this after reading the comments here and also the article.) Especially given the above definitions. I mean, on a two megabyte input file the "most efficient function that you can" would start by copying the whole two megabytes...twice. Rather than working from the outside in, so it can reject the input and ignore the inside characters as fast as possible. Shocking! What I'm really shocked about isn't that that's what the solution was - fine, no problem. But rather, that nobody comes close to thinking about most-efficient the way other types of programmers would think about it - and this includes the comment in the story which takes exception to the offered solution. It doesn't do it either. This post and this thread was a real eye-opener for me.
  • p4wnc6 10y ago
    The shocking thing for me isn't so much that certain sections of the programming community don't natively think this way (I'm not convinced that I want them to ... someone whose primary value add in life is site design, for example, should dedicate way fewer brain cycles to this kind of algorithm efficiency and just relegate it to something they will profile and fix empirically should the need arise) ... but rather that interviewers of any kind, anywhere, actually care whether a candidate, who is writing code in a totally alien physical and mental situation (the interview), would write "efficient" code during an interview at all. Yes, maybe some small allowance for some discussion about basic time complexity, but nothing more. If you very clearly articulate an O(n^2) algorithm during an interview, that's excellent -- even if there is an O(log n) solution that we'd all prefer. You can always learn on the job and improve through self-study, etc., but the basic task of clear articulation is much more important. Obviously, no one who comes up with the O(log n) answer is going to be marked off for it, but neither should the O(n^2) person be. Instead, interviewers should just admit that focusing on efficient code in the setting of an interview is utter nonsense. You cannot learn from that whether or not the person is going to be effective at writing efficient code for you in the completely and totally different situation of coming to work every day in a regular work environment. No matter what you think, you simply cannot. So the better thing would be to just admit that the results of timed interview trivia cannot tell you anything at all about how effectively someone will write efficient code in a real-life situation, and just get on with it.
• Cozumel 10y ago
  1, commenting for the sake of commenting 2, basic spelling mistakes in the article 3, god awful javascript code 4, condescending attitude Not a guy I'd want to work with, ever.
• snarfy 10y ago
  > Your code should avoid breaking at all costs. This type of practice hides bugs. Whatever happened to 'fail fast, fail often'?
  • pc86 10y ago
    "Fail fast, fail often" does not refer to the build status of your project, it refers to the business. How does writing code that builds hide bugs?
    • snarfy 10y ago
      Fail fast, fail often isn't just about the business. It's about code too. If the palindrome function does not support unicode correctly, it can: 1. Try to function anyway, return true/false even without a real match 2. Detect unicode and always return false 3. Throw an exception It would be best to throw an exception. Why is a function that doesn't support unicode being called with unicode input? That's the real error.
• coldcode 10y ago
  How to win a coding interview where the company does nothing but write short snippets requiring cleverness. When's the last time you worked for one of those?
• dominotw 10y ago
  >“Is this client side or server side JavaScript?” >“should an empty string be considered valid input?” >“Do I need to handle unicode characters?” these questions seem a bit much for a palindrome test.
• d--b 10y ago
  Just a comment here, starting by a string.replace with a regex is not what I'd call efficient coding...
• sickbeard 10y ago
  >Write the most efficient function you can that determines wether a given string is a palindrome. >When I offer a challenge like this in an interview, the first thing I’m looking for is wether or not you ask me any questions > / * Tests wether or not a given string is a Palindrome * @param {string} stringToTest - the string to test. */ Don't take coding advice for someone who can't spell whether.
  • neotrinity 10y ago
    Apparently wether is a castrated male sheep or a castrated male goat. Just saying.:D I have learnt something new today !
    • TillE 10y ago
      Similarly, "payed" is something you do on a ship. The hazards of relying on spellcheck.
• agentultra 10y ago
  What if I we start by writing an unambiguous specification and I walk you through the proof? The pomposity of this post is ridiculous. I can't stand the, "I don't have time for you," type of thinking. It suggests that the author assumes they are smarter than the person they are interviewing. It elides the underlying complexities of every persons' lived experience and inner world. Does the author not realize that people are not dumb actors in their narrative? People are generally intelligent, creative, and highly adaptable. All this post does is show how trivial some people treat the interview process. The real lesson here is that if you can learn to ask how high to jump when ordered to you can get anywhere.
• jcadam 10y ago
  My problem is not the technical stuff -- I just can't seem to pass the 'culture fit' part of the interview outside of my industry (defense/aerospace). I've been trying to get out of the govt sector for 10 years now (going on interview binges every so often). I often pass the technical screening (usually screen-sharing or "homework") and make it to the final "onsite" interview stage but something about meeting me in person puts people off. I hear "not a cultural fit" or words to that effect more often than anything else. Hell, I was even told "We think you'd be bored here" when I interviewed at a startup several months ago. Didn't get an offer there either.
  • vonmoltke 10y ago
    Isn't it awesome to hear how hard it is to find people who actually know how to write code while being told all this shit? (Fellow defense/aerospace internee here. I managed to get half-out four years ago but have failed multiple times to get full out on non-technical grounds.)
    • jcadam 10y ago
      Yea, I just roll my eyes whenever I hear "It's hard to find good developers" anymore. Current hiring processes only make sense if you're dealing with a surplus of talent.
  • victorhn 10y ago
    We share the same struggle :). I have been in multiple processes where all goes right until the onsite interview where everything blows. My gut feeling tells me is because i am a rather ugly guy and also somewhat of socially inept, so i should make a bad impression. Currently working in losing some weight and trying to improve my social skills.
    • collyw 10y ago
      Having interviewed a few people in the last year, my number one suggestion would be to show some enthusiasm for coding / tech / a particular language or framework that you have used. Tell the interviewer why you like it (or why you don't). Its really difficult to evaluate a candidate when they just give an answer to the question and no more.
• jdc0589 10y ago
  > Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation I couldn't agree more. I've had interviews (with big companies in the north-west), that had NOTHING ASIDE FROM ALGORITHM questions. At one of those, over the course of a 4 hour interview EVERY SINGLE QUESTION was whiteboard coding tree/graph traversal problems, aside from one "architect a system to handle this" type discussion (which was maybe 15 minutes). Interviewers: if your candidate knows, without prompting, that the best solution to the problem is a depth first traversal of a tree and can explain why, implementing the actual solution is not the most important part of the interview. Not a lot of people need to write tree/graph traversal as part of their jobs frequently enough to warrant assuming everyone can implement everything from memory on a whiteboard in 10 minutes.
• edoceo 10y ago
  Would not get the job here.
• bluejekyll 10y ago
  After reading this last night, I got a little excited about doing something I've never done: a palindrome function in Rust only using Iterators, https://news.ycombinator.com/item?id=11805296 https://news.ycombinator.com/item?id=11805296 Straight link to code as well: https://github.com/bluejekyll/palindrome-rs/blob/master/src/lib.rs https://github.com/bluejekyll/palindrome-rs/blob/master/src/... It was fun because I realized I have a different option than stacks and arrays to solve this problem now.
• gmarx 10y ago
  Says in the definition a palindrome can be a number then filters out number. Also, and most importantly, doesn't check to see if the items within the string are words. The incredibly frustrating thing about interviews is that the interviewer is right, even if he is wrong.
• hiou 10y ago
  The only winning move is not to play.
• justinhj 10y ago
  I find it amusing that the author asks for an optimal solution that avoids taking up extra space. Then in his example solution he makes two copies of the original string to convert it to lowercase and strip invalid characters. Using a regex is overkill for the simple rejection of invalid characters. The job could be done in a single loop with worse case runtime n/2. Sure his solution is still linear time but he did ask for optimal. It just goes to show that you can't win the interview game because everyone looks for different things. There is definitely good advice in this article though.
• phat4life2 10y ago
  I would much rather do a take home test, and as someone who has done hiring, I would much rather give a take home test. The problem though I have with code challenges, is when you get rejected, and they offer ZERO reason why they rejected your code, despite the fact you may have spent a whole fucking week working on it, doing the best you could. I have outright asked why my code was rejected, and I have NEVER gotten a response. Pure bullshit. The other problem, is that most of the time they tell you not to use external libraries, which I get why, if they want to access your algorithms or data structure skills, but this is stupid, because you likely shouldn't rewrite libraries that do a better job than what you can code in a short time, and in any real world scenario, i would use all the libraries I could to write less code. Its better to test those things via white board. In some cases, I would reject you based on you not knowing about standard libraries. I had one take home test, that was basically, write a database like thing in ruby to process and query an input file with dates, names, etc, you can't use any gems. If I used external gems, I could finish the assignment in few lines of code, without external gems, i have to do all this bullshit i would never do in a real world scenario.
• YeGoblynQueenne 10y ago
  >> On this particular challenge, I am expecting many will use RegEx as a part of the solution. The regex needed for this is some of the most basic regex out there Woohooa, cowboy. The language of palindromes is a classic example of a context free language that is not possible to describe with a regular grammar, such as accepted by a regular automaton... in other words a regex. In Recruiter-Parseable English (RPE): you can't decide whether a string is a palindrome using a regex. It's impossible. Like, maths-impossible. You can use regular expressions to compare strings while you decide whether a string is a palindrome but you can't do the whole thing in one regex.
  • Programmatic 10y ago
    He's not expecting the use of a regex to do the whole heavy lifting of checking for a palindrome, in the example he uses it for the replace functionality to remove non-alphanumeric characters. https://gist.github.com/anonymous/e8553707cd6162040e7d12b2a1a0fa67 https://gist.github.com/anonymous/e8553707cd6162040e7d12b2a1... stringToTest = stringToTest.toLowerCase().replace(/[^a-z0–9]/ig, '');
    • YeGoblynQueenne 10y ago
      Yep, should have read all the way through before posting. But the example solution is so bad anyway.
      • Programmatic 10y ago
        What's your preferred solution?
        • YeGoblynQueenne 10y ago
          Nothing more complicated than this: is_a_palindrome(S) { assert is_a_string(S) if reverse(S) == S return true return false } A string is a palindrome if it's equal to itself reversed. The example "solution" in the article is dreadfully overengineered to death and back. Noone interviewing should be happy to see such a solution and noone being interviewed should expect to be required to give such a solution, to such a trivial problem. Unless of course the recruiter is trying to catch you pants-down, but then the parent article wouldn't post that overengineered "solution" as a gold-standard, like they did.
• am8 10y ago
  "is wether or not you ask me any questions" wether. Who cares there are plenty of places that will hire you without all this "super smart and get things done" cliché. More trust should be given to younger employees just starting out. They might still provide lots of value but not need to tick off a certain % of clichés valued by a senior dev who think they know the correct way. “I use this test on all levels of developers, but my criteria is stricter the more senior I expect you to be.” Who would really want to work for someone who treats you in such a subordinate way. A lot of the time the personality issues are with the super arrogant hiring developers at companies. I had this issue trying to get jobs out of uni, being able to code but not knowing the trends. If you answer the correct questions (led by what is fashionable according to top developers/industry figures) and fit into their view of what a great developer is then you will get the job. It’s almost like you could come up with a stock set of answers about subjects to pass (clean code, unit tests, maintainability, logging). What about the project which provides your pay check, isn't getting to grips with that just as important?
• mixmastamyk 10y ago
  > I guarantee you this, there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line. When that time comes, we’re going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast. False, that has never happened in decades of work in my experience. All "breakthroughs" I've had came to me in the shower or other solitary place. For most people, creativity does not spring from a gun to your head in a crowded room. The rest of the piece falls apart from there.
  • collyw 10y ago
    Exactly. High level architecture as well. I don't sit down and come up with one there and then. I get a rough idea of the problem early and think about it for a few days (while I am doing other things). Piece by piece I see what will work well and what won't.
• YeGoblynQueenne 10y ago
  Oh my gods! This is what passes for an answer to "identify a palindrome"? All of that?? 59 lines to ensure a string is equal to itself reversed (hint-hint, nudge-nudge)? Why? 'use strict'; // avoid ambiguity and sloppy errors /** * Tests whether or not a given string is a Palindrome * @param {string} stringToTest - the string to test. */ function isPalindrome(stringToTest) { var start = 0, end; // make sure we have a string. if (typeof stringToTest !== "string") { // throw if we didn't get a string throw new TypeError("isPalindrome() expected a string, but got " + Object.prototype.toString.call(stringToTest) + " instead!"); } // normalize string by lowercasing and removing non-word characters stringToTest = stringToTest .toLowerCase() .replace(/[^a-z0–9]/ig, ''); if (stringToTest.length === 0) { // warn if we have no valid characters to test console.log("No valid characters to test, treated as empty string" + "\nStack: \n" + new Error().stack); return true; // an empty string is a palindrome. } end = stringToTest.length - 1; // Compare characters from outside in. Stop when we get to the middle. while (start < end) { if (stringToTest[start] !== stringToTest[end]) { return false; } else { start++; end--; } } // if we get here, it's a palindrome return true; } // tests (should be in a separate file using a test framework) console.log(isPalindrome("something that is not a palindrome") + " = false"); console.log(isPalindrome("something that is \n not a palindrome") + " = false"); console.log(isPalindrome("race \n car") + " = true"); console.log(isPalindrome("") + " = true + warn"); console.log(isPalindrome(" ") + " = true + warn"); console.log(isPalindrome("1221") + " = true"); console.log(isPalindrome("0") + " = true"); console.log(isPalindrome("racecar") + " = true"); console.log(isPalindrome("No 'x' in Nixon!") + " = true"); console.log(isPalindrome("~~!~!~") + " = true + warn"); console.log(isPalindrome("Momsie") + " = false"); console.log(isPalindrome(12)); // blow up console.log(isPalindrome(undefined)); // blow up console.log(isPalindrome(null)); // blow up Godsdammit- I'm pretty sure I'm not missing the point here. That is a ridiculous amount of overengineering, it should not be accepted as an answer to such a simple question, under any circumstances.
  • logfromblammo 10y ago
    This is something you write only after the profiler says your previous palindrome checker function is a CPU/resource hog, a bug report says it isn't reporting all palindromes correctly, and your manager gives you the okay to spend as much time as you need to fix it forever (but really only spend like 30-40 minutes, mmkay?).
• deleted 10y ago
  [deleted]
• grimoald 10y ago
  > Before I start though, I have to say, if a company is going to hire a developer based solely and entirely on a piece of code the developer wrote in an interview, you probably don’t want to work there. This is something I read many times when talking about interviews, and it makes no sense. Either there is a nonzero chance to be more successful in the interview if you perform good in coding exercises, or not. If the former, then there was at least one person in the history of mankind who was hired depending solely on the coding.
• kevindeasis 10y ago
  This is complementary: https://www.twilio.com/blog/2016/02/patrick-mckenzie-on-salary-negotiation-job-hunting.html https://www.twilio.com/blog/2016/02/patrick-mckenzie-on-sala...
• snambi 10y ago
  Very thoughtful post. This exactly what I look for while interviewing candidates.
• thefastlane 10y ago
  this shows me that there seems to be a cottage industry sprouting up around 'technical interview prepping' (this blog post is an advert for such a business). it's interesting that we've arrived at this point. curious to see the direction it takes
• jupp0r 10y ago
  Comments that don't document public interfaces are a code smell and should be avoided in all but the most exceptional circumstances. Reading Robert C. Martin's Clean Code really opened my eyes to this issue. Your emphasis on this in the code people write might exclude some people who avoid comments deliberately.
• michaelmcmillan 10y ago
  I had a go at this with Python. It has tests, a fast implementation (O(n/2)) and uses memoization to optimize. https://github.com/michaelmcmillan/palindrome https://github.com/michaelmcmillan/palindrome
• prirun 10y ago
  To me, the first good questions would be: 1. What language(s) does this function have to be callable from? 2. Can I write it in any language? Rather than “Is this client side or server side JavaScript?” Considering that I have no idea how to use a regex for this, it was very strange to read that the interviewer expected _many_ people would use a regex. Made me feel like I missed a year of school or something. For efficiency, only half of the string needs to be tested, not the whole thing. (Edit: I realized later that the posted JS does this too. It was not obvious at first because "end" is also changing.) Since I never actually do these things, I thought it might be fun to code one. First I wrote the simple function, pal1(). Then I wondered if Python had a built-in string reverse function, so looked that up with Google and found that it didn't. It has a klunky reversed() iterator, but there was the obtuse s[::-1] post on Stack Overflow that runs fast, so added that as an alternative. And I had to lookup the __name__ line, because I forgot the syntax of that, even though I've been writing Python (HashBackup backup program) for 7 years! import sys # the straightforward way, char-by-char compare def pal1(s): slen = len(s) slenm1 = slen - 1 for i in xrange(slen/2): if s[i] != s[slenm1-i]: return False return True # s[:-5] === "the last 5 (or fewer) characters of s" # s[::] === s === s[start:end:incr], where start=0, end=len(s), and incr=1 # s[::-1] === reverse(s) == s[end:start:incr], where start=0, end=len(s), and incr=-1 def pal2(s): return s == s[::-1] # select which palindrome function to use pal = pal1 # test with: # 1. null string # 2. single char (odd length) # 3. double char string (even length) if __name__ == '__main__': if len(sys.argv) != 2: print 'usage: pal <string>' else: s = sys.argv[1] if pal(s): print 'yep' else: print 'nope'
• amai 10y ago
  "Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it. But it’s not going to change any time soon." In fact a much better way to evaluate a software developer in an interview is by asking her/him to present some examples of work they have done in the past. But don't take my word for it, read here: https://blog.codinghorror.com/a-programmers-portfolio/ https://blog.codinghorror.com/a-programmers-portfolio/
• hajderr 10y ago
  only makes sense if the recruiters are good and smart as you.