9 ms·
The (JavaScript) Question I Bombed In An Interview With a Y Combinator Startup
- ultimatedelman 13y agoafter you gave him your "clever" answer, you should have followed up with mentioning that keypress is the wrong event to use, but rather "keyup", since keypress varies across browsers and doesn't account for the holding down of keys. try holding down a key in your demo to see what happens :)
- Hengjie 13y agoKeyup doesn't account for holding down keys either. It's keydown that is what you're after for that one.
- dmbass 13y agoYou want the oninput event, but IE < 10 has horrible support for it. Figuring out when the input value has changed is a lot more complicated than picking one of onkeyup/down/pressed.
- dccoolgai 13y agolodash.throttle() is a nice one for stuff like this sometimes.
- deleted 13y ago[deleted]
- mdkess 13y agoUnderscore has a nifty function, _.debounce, which given a function f, returns a version of the function that behaves as the one in your interview question. http://underscorejs.org/#debounce http://underscorejs.org/#debounce Even if not using libraries, it would be nice to abstract that into its own function when you inevitably want to use it again in some other control. The code is pretty simple - very similar to what you did: function (func, wait, immediate) { var timeout, args, context, timestamp, result; return function() { context = this; args = arguments; timestamp = new Date(); var later = function() { var last = (new Date()) - timestamp; if (last < wait) { timeout = setTimeout(later, wait - last); } else { timeout = null; if (!immediate) result = func.apply(context, args); } }; var callNow = immediate && !timeout; if (!timeout) { timeout = setTimeout(later, wait); } if (callNow) result = func.apply(context, args); return result; }; }
- rvivek 13y agoI'm guessing underscore's throttle function would be the better way, if underscore is available.
- aroman 13y agoThis is precisely what I would have suggested I would use if I were asked such a question.
- mdkess 13y agoThrottle is different, it's a rate limiter, whereas debounce just measures delays between calls. With throttle, the server request would be made every 200ms rather than 200ms after the user stops typing. From a user experience though, throttle feels like a better way to approach this, since it would let you update the list at a measured pace, but it would be incorrect for the problem as described.
- thedz 13y agoRight, from a UX perspective, throttle makes more sense due to more constant feedback. You want the user to realize that it is a live search before they finish typing. Else, they'll just type the entire query. But obviously, in this case, the interviewer specifically outlined requirements that would make debounce the better choice than throttle.
- mercer 13y agoGood point. I've generally used debounce for live search, and throttle for window resizing, among other things. In hindsight throttle is perhaps better for live search as well.
- thedz 13y agoFor window resizing, i'd actually use debounce. Most times, a user resizes a window with a predetermined size in mind -- they want to show something behind the window, or want to make the window fill an existing space. In that case, showing live updates in the window during resizing might not be worth it.
- adyus 13y agoThis is more of a question for the startup that Nathan was applying to: Given it took Nathan a reasonably small amount of time to research and learn the correct answer, what disqualifies him from being (or quickly becoming) a skilled developer for your startup? In other words, what's the minimum skill and knowledge level you'd accept, given that the applicant know how to learn the rest? Is that level arbitrary?
- eshvk 13y agoMaybe it is not about him being disqualified, maybe it is about the fact that the other people they interviewed were able to jump through their hoops and do all the tricks and were equally as qualified?
- jiggy2011 13y agoThe transcript implies he was disqualified because of this question. Of course he may have bombed other questions and this was just the last chance saloon.
- halisaurus 13y agoWhy not both? For one, setTimeout is pretty run of the mill. If you haven't come across a situation where you need to wait a period of time before initiating some event, you simply haven't coded much. If someone else had just nailed the question in the interview before him than—hoop or not—they've proven a skill he hasn't. Even if we ignore this, the "What Really Happened" area sounds like he only admitted he doesn't know, and worse, that he doesn't know how to proceed. Another comment above asks if one small set back is really a deal breaker, but in my opinion, not attempting to overcome a problem you haven't seen before shows more about a candidate's abilities than simple knowledge. Prove you can find a solution when all you have is a basic idea of the problem. Take a hint and run with it. (The interviewer gave the method name as a hint!) Google the answer. This post hints that the position was closer to entry level, so I would suspect that curiosity and autonomous problem solving are fundamental requirements for the role. When you're green a lot is going to be brand new, so you have to be able to learn on the spot and run with it.
- 1qaz2wsx3edc 13y agoThis is a terrible interviewer, it has nothing to do with you. They know what they want, but they don't know how to find it properly. Don't be afraid to use you're own notebook/laptop to Google a solution, or keep asking questions about the desired solution. Be free in not having all the answers either, be confident you can find the answers. An interview shouldn't be about vague technical hurdles you have to jump through. It's about proving competence & compatibility of character. If your interviewer is willing to end the interview because of one dropped ball, call them on it.
- ricardobeat 13y agoReally? I don't think there was anything wrong with the interviewer at all, he just wasn't at the level of experience they were looking for. There is no point in extending the interview beyond that point if you know it's not going anywhere.
- gesman 13y agoCompletely agree. Interviewer deserves personal performance review after making such conclusions. I think you got lucky by avoiding to work with these type of people before it got too late.
- deleted 13y ago[deleted]
- misterjangles 13y agoIt would depend on whether they're looking for a promising candidate or somebody who is already experienced. If they wanted the later then it would be obvious this was not the guy. Still, I think spending 5 extra minutes of your life with a young person to help them not feel like a failure - I don't think is too much to ask either.
- Afforess 13y agoI would have mentioned the Jquery-UI built in autocomplete function... http://jqueryui.com/autocomplete/ http://jqueryui.com/autocomplete/
- deleted 13y ago[deleted]
- nickbauman 13y agoAny stupid can interview for someone who is an exact fit with all the experience needed to do the job. Unfortunately very few people who fit the bill like that are even available let alone affordable.
- drewblaisdell 13y agoThe solution in the post attaches a setInterval reference to the "this" object, a reference to the input box. This is neater than using a variable defined outside of the closure, but I was under the impression that attaching arbitrary data to DOM nodes was bad form. Thoughts?
- TheZenPsycho 13y agoattaching arbitrary data to DOM nodes is fine in theory, except that older versions of IE have a bug in their garbage collector that doesn't cope with cyclical references. Cyclical references are very easy to unintentionally create in javascript because of closures. The typical situation is creating a variable to a dom node, and then attaching an event handler to that dom node. The event handler has a reference to the dom node through its closure object, and the dom node has the reference to the event handler creating the circular reference. You must be careful to null out the event handler when you are done with it. For arbitrary data, jquery provides a data() function that does the cleanup stuff for you. for event handlers, well, jquery's bind() (now renamed to on() ) is one of the first things you learn in jquery, and it (i assume) also deals with the IE bug.
- drewblaisdell 13y agoThanks for the reply. I'm mainly curious about this in terms of programming style/best practices. Beside implications to the namespace of that node (which could be avoided with data()), it seems to me that it would be best to separate the setTimeout ID to a variable defined outside of that closure simply to make the code maintainable, for if there ever was another reason to interrupt the setTimeout. However, due to the mention of closure at all by the interviewer, it seems that he felt that attaching it to the DOM node was the "best solution". Would you agree?
- dmbass 13y agoCapture the timeoutId in a closure. $(document).ready((function() { $('input').keypress((function() { var timeoutId = null; return function() { window.clearTimeout(timeoutId); timeoutId = window.setTimeout(function() { $.ajax({ /* ... * /}); }, 200); }; })()); }); // NB: this solution only works if there is one input. // If there are more than one, you need to create a new closure for each one.
- waps 13y agoThis makes me so very very glad I'm not a web javascript guy : INTERVIEWER: So, you may be able to guess, that there is a problem with this code. It is very inefficient. If you type a string with 30 characters into the text box, the server gets called 30 times. Not good, we are having all kinds of issues with scalability so we can’t afford to be writing code like this. Calling code 30 times is a problem. Sure there's a few places that might be true. Is this a device driver ? A video decoder maybe, or something else that's horribly complex ? Nope, just the most basic MVP website. Oh my fucking god. I remember programming on windows in Delphi, and on linux in QT. In both cases doing autocomplete the naive way just fucking works. Even with millions of possible completes. I remember implementing a function plotter that just completely refreshed a canvas pixel-by-pixel upon keydown. Not a problem. Even re-rendering a robot's simulated environment every keypress was nowhere near problematic. And now we're worried about a 30 times called dead simple function, in the most basic of websites. Wow. Progress. (I understand why this happens. Server latency ... just works that way I guess. But I don't have to like it. HTML page layout is another peeve of mine. Resizable layouts are a solved problem in every single GUI toolkit except for one. Custom components are another seriously lacking web thing. It is a major javascript accomplishment to display a custom temperature-like gauge ... wtf ?)
- TheZenPsycho 13y agoUhhh isn't making 30 seperate network connections in a second a scalability problem regardless of language or platform? if the target server is apache, that's spinning up a thread for every keystroke, for one user, and you think this is a problem unique to javascript, why?
- drewblaisdell 13y ago> And now we're worried about a 30 times called dead simple function. Wow. This problem is not unique at all to the browser environment. You should probably throttle/debounce autocomplete events any time a server is involved.
- waps 13y agoTrue. In those toolkits, generally no server was involved.
- donatj 13y agoIn my eyes its a server side problem. Set a decent cache header. Problem solved.
- TheZenPsycho 13y agohuh? so your solution is to create cache entries for 30 separate unique requests in a second, which are unlikely to be cache hits in the future?
- TheSisb2 13y agoThere's an error in your good solution. window.clearInterval(this.timeoutId); should be window.clearTimeout(this.timeoutId); You use clearInterval with setInterval, and clearTimeout with setTimeout.
- jbeja 13y agoI was touch and related by this post since some weeks ago it happened the same thing to me in a PHP interview, i will bookmark and whole this post dearly and read it every time that i remember that futile day and feeling suicidal instincts towards myself.
- gotofritz 13y agoWell, it was a pretty basic Javascript question