171–180 of 268 posts
Evaluating a programmer by how well he solves a logic puzzle makes about as much sense as evaluating a race car driver by how well he rides a horse.
Earlier quoted context omitted.
Agreed. I can write a regex the (very) few times I need one, but it generally entails me looking up a cheat sheet to get the appropriate character classes. If you were to put me in front of a whiteboard I would flub the most simple of tasks (from the original post, "{(.*)}", I think? Did we mean to include whitespace, and does . translate properly? Because that's partly language dependent when it comes to white space…
Start using regex in your text searches while programming. It will make you more productive (especially when you start using it with search-and-replace) and you'll learn regex properly. Please don't parrot that Jeff-Atwood-nonsense. EDIT: I don't care if you ever actually use regex in a program. You should learn regex just as a part of using a text editor. For example, suppose I want to write a bit of repetitive code…
Per your example, I code in a functional language. I'm even less likely to make a mistake if I just reuse the function, than I am to apply a regex.
Apparently in some alternate universe where design is not considered problem solving.
Earlier quoted context omitted.
You know the saying, " If you have a hammer, everything looks like a nail "? I think the corollary to that is " If you don't have a hammer, nothing looks like a nail ". If you have little knowledge of graph theory, algorithms, and other such "esoteric nonsense", you wouldn't recognize situations where those will be helpful, which then reinforces your belief that algorithms are useless. I have seen too many times a pe…
This so much. I don't get how people can think that something so simply and straightforward as the time complexity of an algorithm is something superfluous that only belongs to some boring classes they took in university, and it has nothing to do with "real world problems". Those people complaining about Google caring so much about their engineers being able to deal with basic algorithmic, instead, should wonder why…
I imagine it has little to do with algorithms and everything to do with infrastructure. Most Google services (and even outside of Google - most services, websites, mobile applications, etc) are simple store data/retrieve data services. When it comes down to the source, fast data access is thanks to the database, and very few developers develop database systems.
you like design! design a puzzle where the game is to optimize features for your end users.
how many wonderful algorithms have shitty interfaces? i know because I have written them - and nobody uses them because the interfaces suck.
i promise to keep an open mind to design, if you try a jigsaw once in a while
>Four people need to cross a rickety bridge at night. Unfortunately, they have only one torch and the bridge is too dangerous to cross without one. The bridge is only strong enough to support two people at a time. Not all people take the same time to cross the bridge. Times for each person: 1 min, 2 mins, 7 mins and 10 mins. What is the shortest time needed for all four of them to cross the bridge? 17 minutes, if you…
If you program, you are a programmer. By definition. I suspect what you're really asking is: why do so many companies thinking programming == solving puzzles? The answer is that: (1) Based on what you're defining as a puzzle, they don't. (2) It is valuable skill (but it's also not the only skill). -- (1) -- While there are stupid companies that ask "puzzles", this is not the norm at Google, Facebook, and similar comp…
However, without going into specifics. How does an interviewee handle/convince an interviewer with a preconceived solution?
For example, Interviewer A has an interview tomorrow and plans on asking this really slick problem that has one way of being solved well. A looks this way up and knows the ins and out of it. Now as an interviewee,if B were to come up with a 100 ways of handling the problem (starting from brute force) but fails to reach the "cool" solution because he has only 45 minutes of time . Do you think the interviewee would be considered a good candidate?
I'd say that the interviewer has hardly learnt anything about the candidate by asking such a problem. But then again, I could be wrong.
If you program, you are a programmer. By definition. I suspect what you're really asking is: why do so many companies thinking programming == solving puzzles? The answer is that: (1) Based on what you're defining as a puzzle, they don't. (2) It is valuable skill (but it's also not the only skill). -- (1) -- While there are stupid companies that ask "puzzles", this is not the norm at Google, Facebook, and similar comp…
I don't think you can adequately back up that statement. Google is a massive company with very broad needs in each engineering discipline they hire for. My most significant criticism of Google's hiring practices is that they feed every software engineer through the same sieve. The sieve is calibrated as you describe, and that calibration is appropriate for many of their core positions. But, they need some developers like the one you describe as being a "terrible" fit as well. They need some developers who have a foot firmly planted in another engineering discipline, or various non-engineering domains. There are a whole lot of things they need that they don't test for because they spend all the available time testing for traits that are only critical to a portion of their business.
Interview questions you don't like/fail shouldn't be viewed as reflective of you, but reflective of your fit at that company. They asked a puzzle-y question you couldn't solve? Either their problems are puzzle-y, or they have terrible criteria for evaluating people; either way, do you really want to work there? They asked a hard algorithmic problem, the kind that was someone's PhD thesis 30 years ago, and which you'd…
Agreed on all points. But how would you interview a candidate? I see what not to do. Here is what I do: * Ask about their previous work. Dig into something they are excited or proud of. * Try to solve a problem together. Usually a simplified version problem I am actually solving at the moment at work. * If it is a new grad. I will ask them some simple questions about data structures, school projects. * If there is an…
Depending how many applicants you get, I'd start with a screener, a basic, customized problem that they get an hour to solve, that doesn't have a hard pass/fail, but is just a "Hey, let's see how they code when given a problem". If you have constraints you want to filter for, now is the time (you want speed, see above. You want production quality, give them more time than you think a basic implementation would take, and indicate you want the thing to be production quality; see what they do, what they ask, etc).
If they pass that, yes, what you describe sounds fine, if it's what you're looking for in a hire.
If you want to favor false positives, ask a variety of fairly trivial questions; you're trying to make sure you ask questions they may not have solved before, but which any reasonably competent dev can solve. Bonus points if the person scopes them beforehand.
If you want to favor false negatives, ask harder questions, but make sure they actually are ones you deal with. If you're writing basic business CRUD apps, and your challenges are really in deployment, reliability, gathering and responding to user needs, etc, asking them to implement something from Cracking the Coding Interview is counter to your purposes. Ask them instead what it takes to build a reliable system. Are they familiar with doing that? What are some of the considerations? If they suggest distribution, are they familiar with CAP? Etc.
Really, it all depends what you're looking for. If you want someone who is keen to learn about the domain you work in, ask them if they know about things they have no reason to know about, and indicating that "it's okay if you don't"; see if they admit it. See if they respond with enthusiasm when you start to explain it, "Oh, that's cool!" when confronted with a new idea is probably someone you want, "Huh, okay", maybe not. Etc.
I readily admit, hiring is hard, extremely hit or miss, but a lot of companies seem confused about how it's supposed to work; don't borrow the interview practices of another company in a completely different industry. Google asks those questions? Google -can- ask those questions; they're trying to filter out people. You don't get 1000 applications for every job opening, you can't afford that. You also aren't dealing with the same problems; someone who fails those questions may still be a great hire for you.