Software engineering interview questions • Hacker News Board

Re: Software engineering interview questions

#41

Post by disjointrevelry » Tue, Dec 23, 2014, 7:52 PM UTC

sfbushstreet wrote: post #31

Sadly, each time I want to change job, I have to go through those questions again. No any company (or interviewer) would admit that they decide whether or not to extend an offer to you solely based on how well you solve those programming puzzles. But reality is, your "performance" during the interview session is oftentimes more important than your experience (e.g., your side projects. Even you can demo your projects…

I blame it on primate science. Some scientists got some chimps, did some tests, and figured running tests and puzzles on the chimps to gauge their performance must map to humans as well due to a loosely correlated metric, such as genetic distance.

Re: Software engineering interview questions

#42

Post by pnt12 » Tue, Dec 23, 2014, 7:57 PM UTC

matthewmacleod wrote: post #38

I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that. We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of…

I think the point of some of these tests is to quickly distinguish from people who can and can't code solutions for simple problem. The latter has obviously lied in their application and can be dismissed right away, creating time for other interviews.

Re: Software engineering interview questions

#43

Post by morgante » Tue, Dec 23, 2014, 7:57 PM UTC

BigChiefSmokem wrote: post #5

Best way is to paid-intern an engineer for a week/month and try them out (if they're willing) and see how they fit and might be able to expand on your current culture. That's really the only good way. Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.

If only competent candidates would agree to doing that. I've offered it to multiple candidates, and only those who were justifiably unemployed for months were interested (and, unsurprisingly, they didn't work out).

Re: Software engineering interview questions

#44

Post by icecreampain » Tue, Dec 23, 2014, 8:02 PM UTC

What lovely questions! I didn't see anything regarding "remove all dead code from this method" or "find out why the mail server isn't working" or "ask a client specific questions about an upcoming project to judge the time needed" - which all happen to be real-life problems, not fucking brainteasers that have exactly 0 practical use outside the interview process.

They have no practical use during the interview process either, come to think of it...

If someone would ask me any of these questions during an interview I would just leave. They want people who like quizzes, not solving computing problems.

Re: Software engineering interview questions

#45

Post by MaxScheiber » Tue, Dec 23, 2014, 8:08 PM UTC

peeters wrote: post #33

pixeloution wrote: post #13

Earlier quoted context omitted.

I didn't see much that qualifies as a "Brain Teaser" - most of these are algorithmic questions. Knowing when do implement a depth first search != brain teaser.

Actually a crapload of efficient algorithms are applications of "clever" tricks. They're not necessarily intuitive, and the people that can recite them in interviews have very often already seen the solution (or the same general pattern applied to a similar problem). In that sense, they are very much like brain teasers. If every programmer should be able to construct complex algorithms from first principles in a 10 m…

I don't follow your argument. Candidates for a lot of software engineering roles are expected to know a certain selection of fundamental algorithms, including things like DFS and Dijkstra's. The companies I have interviewed at have been very clear about what is expected knowledge. I don't see how this is at all relevant to being able to construct it from first principles. That's the whole reason you're expected to know it!

If you're talking about "tricks" like the tortoise and the hare solution to detecting if a graph has a cycle, then sure, I can get behind that. However, there is a base of algorithmic knowledge that you are expected to know, and it is entirely irrelevant whether or not you can construct it from scratch.

Re: Software engineering interview questions

#46

Post by tn13 » Tue, Dec 23, 2014, 8:10 PM UTC

BigChiefSmokem wrote: post #5

Best way is to paid-intern an engineer for a week/month and try them out (if they're willing) and see how they fit and might be able to expand on your current culture. That's really the only good way. Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.

There are many more better methods but eventually if a method is better it also means it is expensive. Hiring a paid intern would involve lot of legal crap + lot of time wasted on a person. Also number of interns we can have is super limited and we will need some sort of interview to select interns in first place.

Asking tough questions in interview is not particularly bad because tough questions generally work welll. This strategy has worked well for Google, Microsoft, Apple and Amazon I dont see why it cant work for everyone else.

Re: Software engineering interview questions

#47

Post by wbhart » Tue, Dec 23, 2014, 8:13 PM UTC

The hard questions in that list seem much easier than the Google foobar challenge questions. Though of course you have days to solve those, rather than having to solve them during a (presumably short) interview.

Re: Software engineering interview questions

#48

Post by bvanslyke » Tue, Dec 23, 2014, 8:22 PM UTC

fiachamp wrote: post #18

rcoder wrote: post #10

Earlier quoted context omitted.

I agree strongly this is the best way to interview a candidate. It's even relatively easy to set up for a new grad or junior candidate who isn't currently working. They should of course also be local or have no family or professional commitments that make a week-long non-work trip difficult. Sadly, many of the best engineers I've worked with do have families, are working, don't live in the same town, and would absolu…

We've found a good middle ground. Giving the candidate a few days to do a test project that involves fixing a bug on the production site. Its something they can do at night after work, gets them resolving a real-life problem, seeing how fast they figure out the codebase.

Kind of sounds like a sleazy way to get free labour. Unless these are made-up bugs or you are paying these candidates.

Re: Software engineering interview questions

#49

Post by pmiller2 » Tue, Dec 23, 2014, 8:34 PM UTC

mathattack wrote: post #35

BigChiefSmokem wrote: post #5

Best way is to paid-intern an engineer for a week/month and try them out (if they're willing) and see how they fit and might be able to expand on your current culture. That's really the only good way. Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.

Even a week or month is short. I've been in situations where it's tough to make a hiring decision based on 10 weeks of (paid) interaction, even when saying "No" means having only 4-5 interviews to decide on a "Yes" for someone else. This is why hiring people who we professionally interact with (referrals) is so important. And it's a handicap for people with weak networks or internal-only jobs.

How is it that a company could not be able to make a decision after 2+ months of a person actually working for them? If it's not a clear "no," we know that person hasn't managed to destroy the company and can at least get along well enough socially. If it's not a "yes" after that much time, that seems like a management failure. After all, 2 months should be more than enough time to produce enough code to tell whether a person can code and will bring a net positive influence to the environment.

Re: Software engineering interview questions

#50

Post by Kurtz79 » Tue, Dec 23, 2014, 8:51 PM UTC

sfbushstreet wrote: post #40

matthewmacleod wrote: post #38

I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that. We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of…

This is how companies like google, facebook, and linkedin interview candidates. It's not effective, but it's the common practice

It's not very effective, but I don't think it's that bad.

In the end as a developer your job is to solve problems, and getting hired is simply another problem (solving which has self-evident benefits, so you shouldn't lack motivation).

It's not like the hiring process for technical jobs is shrouded in mystery: there are tons of resources on the internet about it.

You know what kind of questions will be asked, you know how you are expected to answer, the rest is just study and practice: a successful interview should be at least proof for the employer that you are able to grasp that process and carry out the work necessary to see it through.