As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options
Interview for a software position
Spawnbroker
Registered User regular
Registered User regular
Hey everyone! So I have been contacted about an entry level programming position and I'm going to be interviewed soon. They're doing a phone interview first, and I'm assuming an in-person interview if I do well.
So here's the help/advice part: What can I expect from the phone part, and after that the in-person part? Will they ask me to write pseudocode? Is there anything I should brush up on before this to prepare? I'm not necessarily nervous, I just want to cover all my bases.
Just to be clear, yes I'll be wearing a suit, yes I'll avoid all the stuff you should avoid at interviews. I know how to interview for an office job; I don't necessarily know what to expect interviewing for a software job.
Any advice?
Edit: Hmmm, I should probably be a bit more specific. The office I'll be working for writes software for financial companies. This is not a gaming job, and it's in the northeast. That should tell you a bit more about it.
So here's the help/advice part: What can I expect from the phone part, and after that the in-person part? Will they ask me to write pseudocode? Is there anything I should brush up on before this to prepare? I'm not necessarily nervous, I just want to cover all my bases.
Just to be clear, yes I'll be wearing a suit, yes I'll avoid all the stuff you should avoid at interviews. I know how to interview for an office job; I don't necessarily know what to expect interviewing for a software job.
Any advice?
Edit: Hmmm, I should probably be a bit more specific. The office I'll be working for writes software for financial companies. This is not a gaming job, and it's in the northeast. That should tell you a bit more about it.
Steam: Spawnbroker
Spawnbroker on
0
Posts
You'll be asked about some of the experience you've put down on your resume or asked to talk about some of the projects you've worked on. You'll be mentioning what languages, frameworks, etc. you did these in while discussing them.
You may also get some basic comp sci or math questions on the phone. Nothing terribly complicated, but it weeds out the field a bit.
It's quite possible. Other possibilities include some math or analyzing code that's provided. Sometimes all three.
There is a huge range of questions you might be asked depending on what the company feels is important. Know programming terminology, the kind of stuff you learn in a data structures class. That bit has at least been consistent.
Steam Profile
3DS: 3454-0268-5595 Battle.net: SteelAngel#1772
DO NOT profess to know something that you don't. If somebody says that they know something, I WILL ask them specific questions on it, and if they can't answer those, then they're out the door.
If you don't know something that you need to answer a question, rather than "i don't know" or muddling through the answer, tell them what you'd do to get that information.
For example, if they ask you how to create a database index (they probably wont unless you've said you know sql), don't just jump into: "Ummmm.... insert index from? on? ummm... tablename... column names... does unique go here?" - say, "I haven't done much database administration, so i'd need to check the syntax - I'd probably have to google 'create index syntax mysql', but it's something like this... (and then do you muddled attempts after that).
Play with me on Steam
then at the actual in person interview there was some more in depth challenges, had pseudocode once, more general problem solving/design stuff in others (wasn't really applying to programming positions so..)
Be ready to talk about things you've developed before and some of the decisions you made.
Brush up on topics like version control, test driven development, agile methodologies, design patterns, current trends in software development.
You don't have to know every language, but knowing the strengths and weaknesses of the main ones will help.
Other important points to consider: Keep the audience in mind. Smaller companies have a lot more leeway to get creative in interviews. I find that large companies will more often have boilerplate questions like "Tell me about a time when you worked with a team, and how you interacted with that team."
If it is a big company, try looking up info about how they interview candidates.
Extremely important for programming jobs, but also holds true for other knowledge-worker positions.
... And it may also help you decide if you don't work for them if they use like TeamServer or something.
e.g.
http://en.wikipedia.org/wiki/Bridge_and_torch_problem
In my interview after 30 minutes face to face, I was put in a room with a machine and given a quick ASP.NET assignment. I actually couldn't get anything to work, but they had been watching me the whole time over a VPN connection and loved the way I did troubleshooting and error handling. My interviewers burst back into the room after 30 minutes and exclaimed "You did great!" and I was like wuh ... huh?
Unless your interviewer is a Computer Science nerd who cares overly about binary tree level-order iteration, you will probably make more of an impression if you can express that you know what really matters to businesses. Things like phased implementation, testing, knowing that 90% of good code is error paths. That kind of stuff.
Yeah I got asked something weird and probably unsolvable too. Here it is:
Say you're working on a piece of software, and your division function stops working. Anything to do with division (this includes modulus, square root, etc.) no longer works. How would you write a function that takes in 2 floating point numbers (A and
- Basic logic/reasoning.
- An understanding of recursion.
- Identify the "problems" in a piece of code. (Did the applicant bring their own pen to mark my example? If the applicant got them all I ask to see if they are sure or unsure.)
- How well does the applicant work through a very difficult question. (Sometimes I make the problem very difficult with the knowledge that an answer will most likely not happen in the time allotted.)
Also, I can count to "boat".
Sometimes it's a big game of Jeopardy where they try to stump you with trivial information that you can easily google. Sometimes they just want to see how you fit in with others and whether you are a team player. Often times they want bodies for cheap and don't really care what you know as long as you can put up with odd, long hours and terrible pay.
The tech world is like a box of chocolates.
You implement a long division function. The trick to the question is that they are looking for you to notice that it can be done recursively(i think).
Actually, that's fallen out of vogue, because they're not good assessments.
Yeah, I'm not real sure how to implement long division without having division working though, that was the issue I was having.
you can think of division as a large amount of subtractions, and tracking of the remainder.
Joel on Software: http://www.joelonsoftware.com/
Rands In Repose: http://www.randsinrepose.com/
The Joel on Software site has a section called "New Developer" that I think anyone aspiring to make a career in software development should read.
I also have to add that the stack overflow site http://stackoverflow.com/ is what I consider the go to place for software dev Q&A.
Also, I can count to "boat".
I believe the solution is bit shifting, or using subtraction recursively. Most of them only work with integer values, and are very inefficient. Google how to implement a division operator, you'll see a few examples.
The better question is why would you want to work for a company that would impose that on you instead of fixing the problem?
bit shifting could work if you converted the numbers over to integer form first.
The point of the question is to see how you process problems, and the reasoning you use to find an answer.
I can't even count how many programmers are absolutely fan-fucking-tastic at brain-teasers but fail at simple algebra/loops/parsing/etc.
Sorry I disagree. Asking a person to write out an algorithm for long division without using the built-in divide operator should be something any software developer could do.
This isn't a trivia question, trivia question are stuff like "swap two registers without using a third." or "given 99 non duplicate values between 0 and 100 inclusive determine which number is missing".
Design questions aren't about skill. Design questions are to find out whether the person who are interviewing thinks in a way that is conducive to software projects, whether or not they actually know anything about the problem you are asking about.
Once you have that subset of candidates, you refine them further by testing their actual technical skills. But weeding out people unable or unwilling to use their head is crucial in hiring for any position.
However, I digress. My advice is to walk the interviewer through the process, and how you'd implement it. Forgot about actually implementing it, or implementing it correctly. As long as you explain your though process and finish it off with a "... and I'll troubleshoot and test to correct the implementation to the point where it's usable." you'll be good, and you'll probably wow them.
I'm glad trivia and puzzles are going the wayside.
I am starting to think you don't understand the reason why the question isn't pointless.
I just explained the alternative, and how it would be better.
You don't see how the division question has value so any further discussion is moot.
I don't know if people are hung up on the fact that the division problem has a stupid reason for existing, but it's not equivalent to the puzzles hedgie was talking about which are normally pure logic like the bridge and torch problem linked earlier. Question like the division one, or the other two examples bowen gave, are a way to test both knowledge of a particular topic and how you approach a software problem.