It is possible, as I know many who are doing it.
But Japan is not where I would start. This country is very exclusive and it is practically unheard-of to hire someone from overseas who does not speak the language and is just getting out of school.
You would need a fairly hefty resumé to be recruited from outside of the country.
Other countries to consider: Sweden, England, France, Germany, Malaysia, China, Hong Kong, and Thailand.
Few people realize that southeast Asia is trying to get into the gaming industry, and foreigners are considered welcome. The Malaysian government makes game companies tax-exempt.
You have a chance at Game Brains in Kuala Lumpur. Their office used to have a nice view from the 60-something’th floor of the Petronas Towers, but they have since moved.
You have a good chance in Thailand at Lumai Prod or Sanuk Games. Both are run by French people who speak English. Thailand and Malaysia are countries where it is absolutely not necessary to speak the native language to live there.
L. Spiro
C++ Interview Questions
On 10/6/2011 at 7:07 PM, Ravyne said:The point, after all, is not to memorize clever answers to a few popular problems, but to have a solid grasp of the wide range of fundamentals that these TYPES of questions are meant to evoke. Besides, a good interviewer will recognize a recalled answer, rather than one which is truly being thought out, even if you fake the discovery aspect.
I think having a solid grasp on the fundamentals was assumed here (what to do if you don't is a whole other topic). And the performance anxiety being expressed was mostly about the rather silly spectacle of "programming" on a white board for an audience. It's a valid concern, being that it's not something you would get good at in the normal course of studying or working. And practicing, on typical interview questions, is a decent idea.
It's not as if being in practice is going to fool anyone into thinking you know something you don't, or can reason about something you can't, but as the OP pointed out, it can keep you from looking like you know less than you do. The less of your brain that's occupied by the mechanics and novelty of the performance, the more that's free to think about the topic in question.
[Think driving a car or counting cards. You can certainly do either without ever having practiced, but they take all of your concentration, and you probably can't carry on an intelligent conversation at the same time. But with practice, they take almost none, and your brain is free for higher level thinking. The same sort of thing holds for whiteboard performances, to a lesser degree.]
As for already knowing the answer to a question, it's bound to happen, and only serves to show the weakness of the puzzle approach to interviewing. But the other weakness of interview puzzles is that they can sometimes make a promising engineer look bad. Seems better to err on the side of, "Oops, I knew all the answers."
Interviews are a good place to learn as well. Practice as you might, you will never be fully prepared, but don’t take it so hard if you fail. You will have learned from it.
The largest jumps I have made as a programmer were due to questions asked in interviews.
Morgan Stanley was interested in design patterns quite a lot. I knew them by name, sure, but only started integrating them into my own work after I realized Morgan Stanley thinks they are important. Prior to the Morgan Stanley interviews I was not so strict on const correctness. Afterwards I was 100% strict.
At Square Enix I was asked if I used shared pointers/smart pointers. When I replied with No, he asked why. I realized then I didn’t have a good reason for not using them.
I started using them afterwards and now I am wondering why I didn’t start sooner.
L. Spiro
The largest jumps I have made as a programmer were due to questions asked in interviews.
Morgan Stanley was interested in design patterns quite a lot. I knew them by name, sure, but only started integrating them into my own work after I realized Morgan Stanley thinks they are important. Prior to the Morgan Stanley interviews I was not so strict on const correctness. Afterwards I was 100% strict.
At Square Enix I was asked if I used shared pointers/smart pointers. When I replied with No, he asked why. I realized then I didn’t have a good reason for not using them.
I started using them afterwards and now I am wondering why I didn’t start sooner.
L. Spiro
The most interesting one, and frankly the one that I enjoyed the most (because I am weird) was when I was asked to basically write a C++ integer library that used ASCII strings to store the numbers and perform operations. I was graded on functionality and efficiency. I would have much rather written a bit-based solution, though (arrays of integers).
I never said there's no value in practicing, I said there's no value in knowing the answers to specific questions. There very much is value in practicing whiteboard coding (eg. On a sheet of paper with no IDE or reference material) and it can be a good idea to work through some common problems in order to get into that headspace. I do both when I'm on the hunt, as well as writing down my answers to non-technical questions (because I find that it helps me to collect my thoughts on the matter so that I can more easily recall the key points later.)
But, you'd be unwise to assume that even experienced coders are versed in the basics, left without their IDE and no Wikipedia. The noobs rarely even know what the basics *are* and the experienced often take for granted that the *just know* all there is. Its also often the case that the basics underpin your understanding of the problems given, and if you've built your answer on top of a shaky, assumed foundation, you're likely to find that it collapses in a stiff breeze.
As a recent grad, you're expected to have a solid grasp of algorithms and data structures, decent command of one or two languages (and knowing the fundamentals of them), probably some idea of design patterns (or at least enough intuition to stumble into them, even if you didn't aim for them), to be able to think through problems, to be eager to continue learning (not a know-it-all), and to be a good culture fit with the existing team (both interpersonally, and to some extent technology-wise). Anything more than that is gravy.
But, you'd be unwise to assume that even experienced coders are versed in the basics, left without their IDE and no Wikipedia. The noobs rarely even know what the basics *are* and the experienced often take for granted that the *just know* all there is. Its also often the case that the basics underpin your understanding of the problems given, and if you've built your answer on top of a shaky, assumed foundation, you're likely to find that it collapses in a stiff breeze.
As a recent grad, you're expected to have a solid grasp of algorithms and data structures, decent command of one or two languages (and knowing the fundamentals of them), probably some idea of design patterns (or at least enough intuition to stumble into them, even if you didn't aim for them), to be able to think through problems, to be eager to continue learning (not a know-it-all), and to be a good culture fit with the existing team (both interpersonally, and to some extent technology-wise). Anything more than that is gravy.
Author
Thanks Ravyne! You guys have given me a lot to help prepare. I really appreciate it!
I can't get into the details of real interviews I've had, because of NDAs and such, but here's a few generic things to be comfortable with:
- Basic algorithms: search, sort, and various applications of recursion
- Basic data structures: arrays, lists, trees, heaps, hash tables, etc.
- Tree/graph traversal methods - know the difference between depth-first and breadth-first and why each one is preferable in certain circumstances
- Pre-order, post-order, and in-order traversal is a good one to know as well
- Simple string processing at the byte/character level
- Elementary bit manipulations - at the very least, know how bitmasking and such work
- Simple analysis of existing code to find missing functionality
- Implementation of new functionality in a fixed, unchangeable code base
Last but very much not least, know how to describe your thought processes in detail and with precision. If you're given an hour to do a two hour job, do your best in 45 minutes. Spend the remaining 15 minutes documenting/explaining exactly where you could improve and why you chose the trade-offs you did. This is a common curve-ball to throw at people in my experience, so be ready for it.
Overall... if you can pick up someone else's code, modify it, and produce something that works, you'll probably be OK.
It is also important to realize that in most interviews they don't expect you to write perfect bug free code, or even complete code. Omitting portions and simply documenting the omission is acceptable, provided you can give suitable details on how you might implement it.
How you solve a problem is often more important to an interviewer than your code that solves the problem. Good problem solving practices will serve you a lot better than rote memorization of how to write various sorting algorithms. Because, to be honest, you'll never actually write any of those sorting algorithms in the wild as an entry level programmer. Even experts generally don't, since the ones your standard library provide you with are typically far better optimized than the quick one you would implement otherwise.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
