5 ms·
I was interviewing at Google, I don't know about the other companies. Paying for good engineers was never a problem. Finding engineers with good algorithmic ski
by xiphias 11y ago
I was interviewing at Google, I don't know about the other companies. Paying for good engineers was never a problem. Finding engineers with good algorithmic skills is hard.
So maybe the problem was not with your coding skills, but your algorithmic skills. That's what an interviewer is looking for, it's not important if you make some syntax mistakes.
Anyways it's better to prepare without an IDE and using a simple editor (sublime, vim, emacs...). At Google anyways there are internal languages without IDE support, so you'll need this skill.
If you really want to work at Google, it's best to study some algorithmic books and write lots of testing code. My favorite site was UVA online judge:
http://uva.onlinejudge.org/ http://uva.onlinejudge.org/
Solve half of the problems there (500 from 1000). It will take couple of months, but you learn a lot from the experience and get to understand what the interviewers look for.
- xiphias 11y agoSorry, I wanted to write that I was in the interviewer's position at Google.
- EugeneOZ 11y agoIt's absolutely stupid to ask candidate to work in uncomfortable environment (without favorite editor/IDE) and expect to see full potential of this developer. Even if Google have some internal langs, even if this particular developer will have to work with them time to time, developer will spend some time to get used to it and become comfortable (more or less), not like in the interview. For more absurd, ask them to dictate their code. All my anger here is not pointed to you as interviewer, although I see some try to defend this style of interviewing with argument about "internal langs". Google invest a lot into IDE support of their home-made langs (Go, Dart), so I doubt it's a valid point.
- Radle 11y agoThat's why he said syntax errors don't really matter.
- clintonc 11y agoIt's not about making an uncomfortable environment; it's a recognition that a program is 90% written before you should ever fire up your editor. What is meant by "full potential" here? You are not expected to write a hundred lines of code, or get something working end-to-end. The goal is to see if you can see to the core of something more complex than a for loop. If you can, you ought to be able to explain that to a colleague in a person-to-person manner, including some syntactically-passable code. Believe it or not, a whiteboard is pretty much to most efficient way to do that.
- xiphias 11y agoActually my first question as an interviewer was always a for loop. Generally reversing a string in place. For some people it took the whole 45 minutes of the interview to get it done. They felt accomplished at the end. I had to wait through it with straight face...I couldn't tell them that it was only a warm-up question, because I was not allowed to say anything that might hurt their feelings. My task was to gather data about the person.
- EugeneOZ 11y agoMaybe they think "it can't be so simple question, it's GOOGLE, maybe they ask for the most fast and efficient algorithm of existing..."
- xiphias 11y agoYou can ask how efficient it needs to be. The interview is always a 2-way conversation. For example you can tell that you can check whether the string size is divisible by 4/8 and use built-in CPU instructions that convert between big-endian and little-endian ordering. Still, generally what's more important for me to see that the person who is interviewed checks all the edge cases (sees the difference between odd and even length strings, and makes sure that trivial cases, like 0 or 1 byte/character long string work as well)
- S4M 11y agoI would be wary about that too, but I would rather answer with the first algorithm that comes to my mind, without worrying about efficiency yet, and if the interviewer ask me for something more efficient, well, then I would start digging.
- danieltillett 11y agoIf them the rules of the game then play the game. If you are interviewing at these places then spend time practicing answering questions on whiteboards. If companies are going to use proxys for identifying programming talent then just practice for whatever proxy is being tested. Yes it is silly, but until you are in a position to change anything your only choice is to play to win or not play at all.
- EugeneOZ 11y agoNo, there is another option: work with companies without silly rules of recruiting. And benefits sometimes are even better:)
- danieltillett 11y agoThat is the don't play option.
- Osiris 11y agoAccording to their website, only 4 people have achieved 500 problems solved. That seems like a pretty high bar to set.
- xiphias 11y agoIt's true..maybe 100 is enough. Still, it's an awesome tool.
- dsacco 11y agoWhere did you get that information from? It looks like there are actually hundreds of people who have solved over 500 problems[1]. Which is not to say it is easy, but putting it at only 4 successes makes it much more intimidating. http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=20 http://uva.onlinejudge.org/index.php?option=com_onlinejudge&...
- Osiris 11y agoI clicked "Site Statistics" -> "Overall rankings" http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=14 http://uva.onlinejudge.org/index.php?option=com_onlinejudge&...
- facepalm 11y agoThe bar for resistance to boring tasks? Probably that would really be a good indicator for a valuable employee who would work on whatever you throw at him. Don't get me wrong, I love that kind of puzzles, but only for a while. They don't seem to be too hard either. I randomly found this: http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3&page=show_problem&problem=36 http://uva.onlinejudge.org/index.php?option=com_onlinejudge&... which is literally just translating the given algorithm into a programming language of your choice and adding a counter.
- golergka 11y ago> simple editor (sublime, vim, emacs...) > simple editor > simple > vim > emacs
- sigsergv 11y agoThe only problem — you must provide working solution, not algorithm but working program. That's a completely different thing.
- mauricemir 11y agoSo if you need an Algorithm you look one up in Kunth or do some research - or for a lot of cases do what we did when I worked at cutting edge RnD buy it in from people like NAG. Recently I needed to develop tool to optimse some PPC I did not know the Algorithms But i knew how to research and building the tool took me less than 2 days to implement.
- e3b0c 11y agoFinding engineers with good algorithmic skills could be hard. But it's not the point. There are tons of undergraduate students in developing countries working hard on those puzzles day and night. Some of them can even squash a whole program into a single function with more than 1000 lines and still be able to make it bug free and quite micro-optimized. The really rare charms, in my opinion, are those who are able to design. That is, making good choices among the trade-offs. I don't think Chris Lattner, Rob Pike and Linus Torvalds would shine at the quickness of puzzle solving or inventing the fastest algorithms. I even doubt if Don Knuth can do better than you on UVA online judge.
- cageface 11y agoExactly. The most valuable skill for a working programmer is designing good abstractions. The ability to cleanly break up a complex problem up into manageable parts is more valuable in day-to-day coding work than any of the skills companies usually screen for. I'll concede there are probably some roles for which algorithmic chops are paramount but they're absolutely the exception.
- xiphias 11y agoActually from the design and speed of git, I think Linus knows a lot about data structures to be good at ACM. Don Knuth: the same, he goes to instruction level speed in his books..is that really general design? Did you really read his books actually? Rob Pike: sorry, but he was the ,,distinguish engineer'' guy making our lives hard with his half-baked languages that were full of as many inconsistencies as possible. I never liked the Pike language and maybe go is a lot better, but still it doesn't even have a generic type system. Chris Lattner: I would rather bet on him than Rob Pike. Putting together a modern language with modern infrastructure is hard. Putting together a half-baked language is easy (especially if you have engineers working under your management). Still what's more important: if you understand the speed of basic data structures, you can reason about performance of more specialized data structures (like memory management in the linux kernel) as well.
- EugeneOZ 11y agoHope you put your personal preferences in the most far corner if your brain, when interview candidates. If you wouldn't hire Rob Pike because of personal preferences it would be one of the biggest mistakes of interviewer. I don't like lack of generics in Golang, but it's too ridiculous reason to think Rob Pike is distinguish engineer or not talented enough.
- imaginenore 11y ago500 from 1000. Ha ha. I solved more than 100 of them, and there's absolutely no way it will take "couple of months" to solve 500, unless you're one of the best programmers on the planet and are working on solving them full time.
- soham 11y agoI used to be a Director in Engineering team at Box. I now run a unique bootcamp in the valley (http://InterviewKickstart.com http://InterviewKickstart.com), where we train engineers to do better at technical interviews. In my perspective, a combination of following is happening: 0. The companies the OP interviewed at, can afford to not give a benefit of doubt. If they hire a few less engineers, their revenues are not going to see a significant dip. Not true of startups. e.g. If an e-commerce startup misses a holiday season, they are done forever. They'd hence be more forgiving. 1. Valley thinks it is a meritocracy, but it is not. Valley is full of biases when it comes to engineering talent. (It's true for all meritocratic systems). They want certain kinds of engineers. 2. Regardless of the hiring market, the companies OP interviewed at, are not forgiving in their interview processes. e.g. use of substring() instead of passing indices in a string recursion will kill an interview with most interviewers. So will use of pow() in atoi(). And you won't know ever. 3. Interviewing is not a test. Interviewing is closer to a date, than it's to a test. There are no "failures" on a date. It's about whether that relationship clicks. "Hiring market" has little bearing on a date. 4. Even if the interviewing panel and hiring committee knows that there is a shortage of engineers, they cannot knowingly give a benefit of doubt to a candidate, or that starts to affect morale in the company. 5. They cannot afford to give a lot of time in interviewing. e.g. they cannot spend a week working with you and knowing you better. If they do that, they will never be able to hire enough engineers. They need them in hundreds a month. They hence have to have an interview process that's short. And short interview processes are bound to be imperfect.
- karmakaze 11y agoTried it just now. Site is woefully slow, which is ok to just load questions and submit. Problem is only supporting C/C++, Java, and Pascal. I'm trying out making Scala my 'go to' language.