8 ms·

So today I had to implement the XDomainRequest API to support IE9 for one of our features. Yesterday I worked on a branch to upgrade our front end framework to

• nothrabannosir 11y ago
  Not defending the interview, but: It just really sucks that there are some companies out that believe that if you can rattle off an algorithm, then you must be a good coder. The implication is (not able to do X) → (not a good coder), not the other way around. They imply: "Doing this esoteric mathematical stuff is a requirement for being a good coder. And there are more requirements." EDIT: strictly speaking, they don't even imply that. It may be they just consider this one of the many possible signals. Maybe they only count it if you pass. Again, most cases may actually well be as you describe. But some might not be.
• marsinvasion 11y ago
  I remember an interview where I was asked to solve an algorithm from my college days. In the 10 years out of college, I've never needed it and to remember how to solve it during a timed interview seems completely unreasonable.
  • krapp 11y ago
    I'm pretty sure filters like this exist in part to implicitly reject candidates old enough to have forgotten their CS curriculum.
    • ebrewste 11y ago
      I'm pretty sure filters like this exist because the real world people that are doing the interviewing / filtering aren't good enough / experienced enough / invested enough in interviewing to come up with a better filter.
      • dexwiz 11y ago
        An interview is a two way street. If someone can't write an interview question, they likely don't understand what they are interviewing for. If your boss doesn't understand your job, you don't want to work for them.
    • thwarted 11y ago
      I was once asked, during a phone interview, to describe how to implement quicksort. I told the interviewer that I had not done that in years and I wouldn't implement a sorting routine from scratch these days because I'd use a sorting routine from a library. The interviewer said he'd never had anyone say that before. I ultimately joined that company as, I believe, the oldest engineer at the time. (At the time, I felt the remaining gauntlet of questions they asked were appropriate for the position I was applying for. And in retrospect, it was the younger interviewers, significantly junior to me, who were asking all the questions that required rote-memorization to answer, and the more experienced interviewers didn't.) In another case, I was I getting interviewed (again, via phone) with a bunch of CS algorithm questions. Now, I have a CS degree, but none of this stuff comes up day to day. I told the interviewer that if these were the kinds of questions, then it didn't seem my 20 years of experience were what they were looking for. The interviewer, someone probably 15 years younger than me, was really flustered, since he was reading stuff right from some collection of questions they had previously prepared and this response didn't match any of the acceptable answers that were listed. The company recruiter called me back later and apologized because the feedback she got from the interviewer was that they were not prepared to interview someone with my experience. Oh, and any tips I could give their recruiting team to address this would be appreciated. I told them I'd be happy to help improve their interview process, at my normal hourly rate. I don't think these filters are explicitly designed to reject candidates based on age, but it does result in it as a side-effect due to the freshness of those topics in the younger candidates' mind. And it just ends up being "easier" to go with the candidate who can recite the answer they are looking for, vs actually evaluating the candidate's fitness for the given job. Or hiring someone and seeing how they work out. There's this need to "hit the ground running" with new hires, and a perception that somehow, those who can answer these random trivia CS questions are able to do that better. This isn't an excuse, however I think it does give us some information on how to address the existence/perception of age discrimination where it does exist. (BTW, I took your use of "implicitly" as being unsavory, to mean "we won't need to reject people due to age, we'll just set them up to fail our test, and maintain our youthful culture", which is where a lot of the rhetoric around age discrimination is focused. That is, I don't necessarily consider it to be the result of bad actors, but inexperienced people who are forced into doing something they don't fully understand or appreciate the complexity of, and they just want to get it off their plate. Admittedly, you might have meant it as I describe in the former paragraph.)
• jamespitts 11y ago
  It is true, the algorithms may not seem critical day-to-day. Barriers to entry like the coding interview or ivyness of education often fail to identify the best candidates, reinforce monoculture, and could even indirectly support ageism, racism, and classism. But they persist because arbitrary barriers serve an important purpose in the minds of interviewers. For example, many organizations may be hiring largely on experience and instinct, with the coding interview serving as confirmation or as a premise to reject.
• dexwiz 11y ago
  I am a self taught developer in my first real job doing it. There seems to be two types of programming: magic algorithm programming, and API programming. Most job prep seems to focus on algorithms. The algorithms are easy to test, because there are clean metrics (does it work or not, efficiency, etc). Also they make people feel clever. Finding the most efficient way to transverse a bidirectional, weighted graph seems more important than finding the right function. This is amplified when implemention in some esoteric language like lisp or Haskell (sorry fanboys, its esoteric when its less than 1% on TIOBE). But most programs/apps/services may only implement one of these at their core. If you are building a database or search engine, you will run into these more often, but its limited for most people. CS seems to focus much more on this side of programming. The second form of programming is API programming, and I use this every day. This includes both finding the right function to use (or close enough) or creating API functions with sane parameters and results. This is much less glamorous, and is theoretically covered by "read the manual." But it is much more nuanced than that. Parameters may not be named the same thing or have the same form between APIs. Handling sync for async function calls are important. Hell, even defining the problem before finding a function for it can be difficult. APIs are the meat of programming. Designing and using them is definitely a required skill. Being self taught, I learned much more about APIs than algorithms. I am not bad at Math, got a minor in it, but some of the algorithms blow my mind. But I am glad I learned APIs, as I use them every day. If I need to deep copy a map, I use a function.
  • whorleater 11y ago
    You're treating CS like its composed of two different divides ("algorithm programming" and "API programming"), when in fact I think you're forgetting that algorithms can be used as the proper foundation for API programming. Handeling asynchronous calls in the proper manner (as per your example) is extremely similar to the consesus algorithm I learned in my distributed computing class. I doubt I'll explicitly be asked to implement a meldable priority queue like my professor assigned in algorithms class, but is the process of designing an algorithm and its implementation to conform to a specific requirement any different from "defining the problem before finding a function"?
    • 11y ago
• agumonkey 11y ago
  Interesting insight. I'm stuck in an abstraction learning phase because I feel unemployable if I cannot do the kind of algorithms you mentioned. A large misalignment it seems.
• _greim_ 11y ago
  > Where, in any of my day-to-day job duties, am I going to need to find the kth permutation of a set of numbers? People who don't know algorithms and data structures tend not to see them where they exist, so it becomes a subjectively self-fulfilling prophecy. You may not need to clone a graph in your day to day work, but seeing graphs where graphs exist can lead you to better solutions in a way that might seem "magical" to others. Even if it isn't too significant, that small edge can make a difference sometimes. Employers rightly want that.
  • bmj 11y ago
    I don't know what your experience is, but given what other folks have shared here, it seems that those with 10+ years of experience in the industry, doing mostly "API programming," have said "I don't use this sort of knowledge day-to-day." I have nearly fifteen years in the industry. I am also entirely self-taught, and have never done any in-depth study on algorithms and data structures. There have been a few times that my lack of knowledge was limiting (and most of those times involved complex queries), but those times are few and far between. But, you are correct: "a small edge can make a difference sometimes." To some employers that matters. To others? Maybe not so much. Maybe they are happy with a few folks that can deal with the algorithm issues, while the rest of team cranks out APIs and fixes bugs and supports old products.
  • foobaz1982731 11y ago
    Posting this under a throwaway so that people at my existing job do not recognize the account. Completely agree, and you might even learn something during the interview, especially if you were previously the "API" programmer group. I'm entirely self-taught, so I will readily admit that my algorithms and data-structures knowledge is not where I feel it should be. I did an interview somewhat recently where we talked about a problem that required the use of a data-structure that I had literally read about in preparation for said interview two days earlier, but did not really understand a solid use case for it. As we discussed the problem that was presented, I ended up arriving at the correct solution and everything was happy, but that's not the cool part. The cool part was that as a result of that conversation, all of the sudden the use for that data-structure "clicked", and an entire class of problems suddenly became obvious in how to optimally solve. I will actually be using that exact solution in a side project that's in the planning phase I haven't done the on-site interview yet, but regardless of whether or not I get an offer (or even accept the offer if one is made), I know that I'm going to walk away from this interview a better engineer for having learned about these algorithms and data-structures just to interview. Looking back at that phone interview, I wonder just how many other problems I've encountered and solved that would've been better served if I knew more about algorithms and data structures.
• skwosh 11y ago
  > Where, in any of my day-to-day job duties, ... Off the top of my head, or at least where I've used them recently: > kth permutation of a set of numbers? Producing all pairs of a collection, e.g. for computing the minimum distance between elements (via map/reduce). > clone a directed graph Any object in an OO language (like JavaScript) is essentially a directed graph, so, cloning one of those.
• vegabook 11y ago
  earth to JS junkies: the gold rush is over. The new no-growth market is going to parse the coder community with much greater scrutiny in the future. Graphic designers passing themselves off as front end coders, game over. From here forward, people who do not have deep algorithmic skills are not going to be able to find work. The lift-all-boats game is over.
  • cema 11y ago
    Oh don't be so gloom, there is still work for everyone, it seems. Whether it's the kind of work one seeks is another matter, but there is plenty of work as long as the standards are set low enough. Which is not bad btw -- imho, if a person starts at a "low" level they have a good chance of growing, versus if they start at a level when they cannot really perform, and as a result can hardly learn. (I am talking about software engineering; other disciplines may be different. And I may be wrong about software engineering too, this is just speculation based on personal observations.)
    • wyclif 11y ago
      The grandparent comment is an Exhibit A "pull up the ladders" sort of attitude. It's a good thing, not a bad thing, that motivated people can grab the lowest rung and pull themselves up. I started out writing BASIC, moved on to C and PHP, and am now working in Python and JavaScript. It's a good thing that I didn't listen to advice that said "you have to be a computer science student to write programs." I could study algorithms while I was doing entry-level work, and do things like read CLRS and Skiena.
• mrrrgn 11y ago
  While you can put processes in place to improve code quality (version control, reviews, style guides/linters), there's no simple way to help a person who doesn't understand the underlying structure of software. APIs are great tools, but don't let them lull you into becoming a cargo-cult coder.
• barrkel 11y ago
  Last week I had to implement part of a database archiving mechanism - taking data out of our expensive SAN and putting it onto inexpensive RAID. To make it more maintainable and reduce the risk of forgetting to archive things, it's fairly generic. It knows what it needs to extract, but when it's done, it needs to delete rows from the DB. Naturally, we use foreign keys; and we're not turning those off, because we don't want to risk losing data. That means we need to walk the foreign key graph of the schema for all tables who have rows scheduled for deletion, determining a partial order for the graph so we can delete in the correct order. Graph walking, partial orders - basic discrete math - and practical tasks in everyday programming. Last month, I was implementing a filtering mechanism for our result tables. That involved converting a predicate created by auto-filter style dropdowns into SQL, in an efficient way, analyzing the predicate to determine which tables needed to be joined to solve the problem. Recursive parsing of JSON, expression tree walking, elementary code generation - basic compiler theory, and not that unusal a task in everyday programming. Seems like every bit of work I do beyond a very basic level of functionality involves a bunch of computer science fundamentals. Why shouldn't I screen for this in interviews?
• a-saleh 11y ago
  > or clone a directed graph? I have had some need for this, while implementing tool for populating our database with test data :) But I have to admit that I went out of my way to snag that task, because I really wanted to utilize a non-trivial graphing algorithm one-day at my work.
• ignoramous 11y ago
  In the immortal words of Niklaus Wirth, "Algorthims + Data Structures = Programs". I agree to an extent that programming interviews are bad at filtering out candidates, but to an extent knowledge of data structures and algorithms go a long way in defining an ability of a programmer to solve the problems (often faced when dealing with systems like Databases, Operating Systems, Build Tools, Compilers) at hand in a reasonable way. One might not realise but knowing CS Fundamentals helps in orthogonal ways. Of course, coding is just a small part of software engineering-- there's design, planning, team work, testing, infrastructure and seemingly endless list of things to care about. I think a better judge of a programmer is really in "projects" they've accomplished. The ability to get done is so much important, I cannot emphasize more. Some companies, like Google, do try to identify and hire people based on their contributions to open-source and participation in projects of interest. Whereas, others, such as Stripe, have a very different kind of an interview process altogether (take home assignments, pair programming, presentations etc).
  • hibikir 11y ago
    Good programmers don't need to have 300 algorithms memorized: They need to know if what they are running is computationally expensive, and to e able to go look up an algorithm that might optimize the problem. I don't need to be able to whip up a red black tree implementation: But if I know I could use a tree, and the tree is going to be modified enough that self balancing is important, I can go look for a self balancing tree. A realistic example was when we were working on speeding up some chart rendering, and we realized that we were wasting a lot of time attempting to render things that were not visible on the screen. We saw it was too slow, and then thought: Is there something out there for occlusion culling? We looked at videogame literature, found quadtrees, and wrote our implementation. But would it make any sense to ask any interviewee about their knowledge of quadtrees? It'd be unfair, as none of us would have passed that interview in the first place.
• ChemicalWarfare 11y ago
  I've been in IT for about 20 years - all kinds of roles with the lowest common denominator being is that I stayed "hands on". Never in my career did I have to do any of the things some of the "interview prep" material out there is geared towards (even though I understand this is supply and demand as some companies are notorious for this CS exam type line of questioning). That's not to say that I didn't have to deal with algorithms - things like strategies for cache cold starting and invalidation, custom encryption, high volume batch tokenization of sensitive information etc etc. The thing is - every time I faced a task that would require a reasonably involved algorithmic approach I would do research, prototype the solution, functional/perf test different approaches etc etc. For that reason I would take someone who can outline these steps for me preferably with the tools/frameworks involved over someone who happened to remember a specific CS algorithm I asked them about. And if they can tell me how they would go about automating their testing, how they would react to unexpected events like message delivery mechanism failures that would be even better :)
• MaybiusStrip 11y ago
  A tech screen is a just that. It's not meant to accurately reflect the problems you work on, it's meant to see whether you can actually write code, whether you can explain your reasoning, and just generally how you react to a problem that requires some level of abstract reasoning. It's a way of filtering out candidates. At most companies, that's 30 minutes out of the 5 hours of interviews you're going to go through. Cloning a directed graph seems like a perfectly reasonable interview question. It requires no specialized knowledge, just being able to navigate a fairly common data structure. I can't imagine a competent programmer not being to solve that problem on a whiteboard, which is precisely the point.