Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software engineering interview questions

oj.leetcode.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Software engineering interview questions

#51

Post by altpaddle »

MaxScheiber wrote: post #45
peeters wrote: post #33

Earlier quoted context omitted.

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 kn…

Ok but the question is why are some of these questions even considered the 'base' level of knowledge for interviews? At least on the front end side we still ask about these algorithms even though binary search trees and Djikstra's have almost no application in our work.

The reason for these questions being considered 'fundamental' seems totally contrived, and that's that everyone studied them in their CS program, not necessarily because that's the kind of knowledge you apply day to day.

Re: Software engineering interview questions

#52

Post by sheepmullet »

tn13 wrote: post #46
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."

The downside to the methods Google etc use is they have a huge number of false negatives. They reject tons of great engineers. This works out well when you constantly have thousands of great engineers applying to work for your company.

It does not work well at all if you are a normal company.

Re: Software engineering interview questions

#53

Post by sheepmullet »

laeus wrote: post #20
Bahamut wrote: post #11

Earlier quoted context omitted.

For me, speaking as a software engineer, I highly agree - if a company tried to pull that on me, that would be a quick way for me to turn down the company. It doesn't make sense if the candidate is working for another company - why would the candidate use up all of his/her vacation for one company if the company isn't serious about bringing the person onboard full-time as a regular employee off the bat?

To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such), I might see this as a pretty substantial benefit of working at a company that uses this method. Given that, I might be willing to participate in this kind of interview process. It would probably have to be a company I already know and admire for some reasons up…

"To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such)"

And yet companies will still let good engineers walk out the door because a competitor is willing to pay them 20% more.

Re: Software engineering interview questions

#54

Post by Iftheshoefits »

MaxScheiber wrote: post #45
peeters wrote: post #33

Earlier quoted context omitted.

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 kn…

Well, "a lot of software engineering roles" have requirements and knowledge expectations that are far out of line with what the job actually requires. There are some "fundamental algorithms, including things like DFS and Dijkstra's" that simply aren't applicable to a lot of software engineering roles, big and small.

Most of the questions and interview ceremony around these things, especially for the aforementioned positions for which they're largely irrelevant, are exercises in hazing, ego building/busting (depending on which side of the interview you're on), and petty power plays.

Re: Software engineering interview questions

#55

Post by wernercd »

toomuchtodo wrote: post #32
pkaye wrote: post #24

Earlier quoted context omitted.

Really good candidates will have multiple offers and given equal choices of companies, will choose those which make them not run through hoops.

In demand DevOps candidate here. I had multiple six figure offers from companies, and still picked the job that required a 4-6 hour project I completed over 2 weeks in the evenings (that I was paid for). Provide the right work environment and perks, and people will "jump through hoops" if they think its worth it.

This.

At the end of the day, what job/pay/perks do you want?

If jobs require you to jump through some hoops, then they will be jumped through - within reason.

Re: Software engineering interview questions

#56

Post by pkaye »

toomuchtodo wrote: post #32
pkaye wrote: post #24

Earlier quoted context omitted.

Really good candidates will have multiple offers and given equal choices of companies, will choose those which make them not run through hoops.

In demand DevOps candidate here. I had multiple six figure offers from companies, and still picked the job that required a 4-6 hour project I completed over 2 weeks in the evenings (that I was paid for). Provide the right work environment and perks, and people will "jump through hoops" if they think its worth it.

So if two companies gave similar perks but one required you to jump through hoops, which one do you think a majority would consider?

Re: Software engineering interview questions

#57

Post by ep103 »

pkaye wrote: post #24
fiachamp wrote: post #18

Earlier quoted context omitted.

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.

Really good candidates will have multiple offers and given equal choices of companies, will choose those which make them not run through hoops.

I don't know, if a company asks me to complete a simple test application, I might be more inclined to talk with them, because it means my interview (ostensibly) would be about the code I'd submitted. Which in turn is much more like what a day in the life of a developer would be like at their company (I write code, review with team lead, repeat, or somesuch).

Re: Software engineering interview questions

#58

Post by kriro »

pkaye wrote: post #24
fiachamp wrote: post #18

Earlier quoted context omitted.

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.

Really good candidates will have multiple offers and given equal choices of companies, will choose those which make them not run through hoops.

I think really good candidates will enjoy working on relevant issues and not working on silly interview questions. If anything these "hoops" seem like exactly the filter you'd want. You want people who enjoy jumping through those hoops every day after all.

Re: Software engineering interview questions

#59

Post by gaius »

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.

Free consulting? No thanks. Paid gig? Well that'll make my taxes complicated. No thanks.

Re: Software engineering interview questions

#60

Post by vvoyer »

I am not able to answer any of these easily and still get a lot of job done and job offers every day/two days.

Interviewing for a frontend Facebook job is all about doing an Array.map/reduce no more.

What matters is what you can do.

Few engineers really need to learn and master "Binary Tree Level Order Traversal" every day after coffee.

Post reply on HN