Am in the only 30 year old coder here, who earns around £300 a day coding, but would fucking die in one of these interviews?
Nope.
How to Crack the Toughest Coding Interviews
41–50 of 144 posts
Re: How to Crack the Toughest Coding Interviews
#42> Given a cube with sides length n, write code to print all possible paths from the center to the surface. What is a path through a cube? This seems like some weird combination of graph theory and geometry.
If you follow the links, this was asked to someone interviewing for a job on the Windows team who then posted it to an interview question aggregator, so it's likely that the actual phrasing of the question was lost.
But as best as I can tell, they're considering each 1x1x1 space to be a node like a Rubix cube, and they want a list of all possible paths from the center node to the surface. I imagine that half of the question is making sure that the interviewee presses for details, because there's plenty of problems I see with the question right off the bat. If n is even, there's no single center node, so where does the algorithm start? Can the algorithm traverse diagonally by edges, or only by adjacent faces? Not to mention that there's an infinite number of possible paths for some values of n, assuming paths can cross themselves, for the same reason that there's an infinite number of paths from my front door to my car if I feel like walking in circles for a while.
Re: How to Crack the Toughest Coding Interviews
#43Am in the only 30 year old coder here, who earns around £300 a day coding, but would fucking die in one of these interviews?
What industry do you work in?
Re: How to Crack the Toughest Coding Interviews
#44Earlier quoted context omitted.
Actually, it was invite-only when I was there. But that's sort of besides the point. It's irrelevant whether or not it's an "honor" to be on the hiring committee. The point is that being on the hiring committee does give you some insight as to why people tend to get rejected. Without being on the hiring committee, you really only see why you're rejecting people -- smaller sample size, biased, less diversity of questi…
I'm on 3 of our hiring committees, and i've been at google for over 6 years. It hasn't been invite only for as long i've been here, AFAIK. Either that, or I was secretly invited! It is irrelevant whether it's an honor, but as to whether it gives you insight, you are generally right but you did miss an important point: The vast majority of people who are "members" of a given hiring committee often don't show up every…
That doesn't seem to be a point missed so much as one that's obvious and generally unnecessary to state fully qualified descriptions of everything in casual conversation.
Re: How to Crack the Toughest Coding Interviews
#45I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable. And only people like developers would put up with being tested like lab mice in this manner for a job.
Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?
Because for programmers what they are asked to do in the interview can (and often is) very different from what they have to do on the job.
Unless your job is to reverse strings on the whiteboard.
Re: How to Crack the Toughest Coding Interviews
#46I got that book. While the questions and answers are useful, in my experience this book alone is nowhere near enough to get prepared for a Google interview (not that the author claims that). I studied CLRS's Introduction to Algorithms and a couple of other books for about 2 months. Even then I could not answer the hardest questions during the onsite interview. And if you cannot come up with an optimal algorithm for a…
>And if you cannot come up with an optimal algorithm for a given problem, all of the items mentioned in the article (communication, clear coding, testing) don't really matter. That's just not true and if any company is only interested in whether or not I can generate a correct answer under pressure in 20 minutes, then I'm not interested in working for you.
You seem to be disagreeing with something I haven't said.
I'm simply describing my experience interviewing at Google: I didn't give an optimal solution to a couple of problems, and didn't get an offer. So I infer that the other items mentioned in the article don't matter as much for getting a job at Google.
Re: How to Crack the Toughest Coding Interviews
#47Earlier quoted context omitted.
In order: Do you use git? How do you do ticketing? What's it like working here? In my experience engineers at big companies will not give you an answer to those, but canned marketing responses. I don't know why.
You have to be more sneaky. Rather than asking something as generic as >What's it like working here? ask them >What do you like the most about working here? If they give you something like "the stability" or "the high pay" those are generally bad signs. Better signs would for example be "the great people I get to work with every day" or "the autonomy to get to choose what I work on".
You can probably throw the "If you could change one thing about the company, what would it be" type question as well.
Re: How to Crack the Toughest Coding Interviews
#48I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable. And only people like developers would put up with being tested like lab mice in this manner for a job.
Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?
whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit.
so yeah, ask me to program. i mean, srsly program. let's hack together for an afternoon; hell, let's do a full day of paired programming to knock out a small bug in your code base. you'll learn a hell of a lot more about what i know, how i communicate, steps i take when i do when i don't know something, and what my processes are. this soft, inter-engineer-social stuff is overlooked over far too often; i wan't to work with people who will amplify my process and abilities, and in turn i'll amplify theirs. smarts don't count for enough.
Re: How to Crack the Toughest Coding Interviews
#49I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable. And only people like developers would put up with being tested like lab mice in this manner for a job.
Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?
I am not saying that programmers should not be validated. Interview questions that are like IQ tests that depend heavily on single spark of inspiration are poor validators of determining productive programmers.
Re: How to Crack the Toughest Coding Interviews
#50Personally, I don't really get this type of interview. For one it sounds like they've pretty much standardized it for all developers with little insight into how a new candidate might fit into an existing team best.
Also, it simply does not reflect in anyway what it will be like to work there or what it will be like to work with that person. One key reason is that the interviewer asks questions they already have the answer to and that unbalances things and results in an inaccurate analysis.
In real life, none of the people in the room would have the answers and they'd all be working together to solve the problem.
These people come and interview all day. The team would be better off just having that person tag along with them and work on real problems together all day.