|
The skill of the interviewer seems to (unfortunately) have more effect on what person gets the job than anything. Here are a few examples from my experience. Terrible Recruiter. Asked best/worst trait, where do you see yourself in 5 years, crap like that. Not great Internship from recruiter. Basically a vocabulary test (data structures, define abstraction, etc) Microsoft consulting position. Maybe I didn't like it because I wasn't prepared. Questions like what changed from .net 3.5 to 4.0, the big picture for my last project (huge workflow tool; I didn't have an answer prepared, so I stumbled through it), and no coding problem. Good Other microsoft consulting position. A simple code problem with a lot of questions about edge cases, what to return, and other discussion. Best Consultant position (current job). Basically a conversation about coursework, experiences on resume, etc. Was good because the interviewer was experienced, so none of the questions were canned and pointless. Part 2 was a programming interview with a project euler problem, which was actually a lot of fun. It seems that if you're generally smart, its far superior to network to get an interview with somebody competent. Otherwise you'll have to prepare for canned questions. Also, for the problems, be sure to bring paper and actually write things down. Drawing a tree or other data structure helps a lot and looks good to the interviewer.
|
#
¿
Jan 5, 2011 21:04
|
|
|
|
| # ¿ May 7, 2024 16:05 |
|
|
boho posted:This is all well and good, but in the context of interviewing for babby's first junior position, beyond knowing the concept behind Bio-O and that its most basic incarnation is (n^[number of loops your operation is nested in]), the rest is 100% trivia in the vein of a highschool history class. If I was in an interview getting grilled about the best/worst/average efficiency for the different sorts I'd probably take out my phone and just look it up. If interviewer dude got pissed that I hadn't memorized all of that, gently caress working for that place anyway. One of the most common followup questions to a whiteboard problem is "What's the runtime of that?". As far as sorting algorithms, if you understand the sort the runtime is trivial, if you don't understand the sort that's also fine as long as you understand/can implement a few others (Mergesort and Radix are good choices). The concept is super simple (redefining it just because): if you pass in n items, how many times will the innermost section (where comparison/switching happens) of your algorithm be run. n^2 means each element checks each other element (200 elements = 40,000 passes), n means each element is visited once (rare in sorting algorithms), and nlog(n) basically means that it does something like halving the sample size each pass.
|
|
#
¿
Oct 11, 2013 21:24
|
|
|
shrughes posted:Looking at hedgecore's post you can see it's just a bunch of neuroses about how to throw away perfectly good hiring opportunities. Stuff like this:
|
|
#
¿
Nov 20, 2013 05:02
|
|