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

81–90 of 98 posts

Re: Software engineering interview questions

#81

Post by Denzel »

laeus wrote: post #39
Bahamut wrote: post #34

Earlier quoted context omitted.

I haven't seen a decent-sized shop where "everybody is pulling their weight". Different developers at are different points in their careers, and have different levels of productivity. As a junior developer, I was very slow when I first started. As a senior developer, I have produced 50% of the work for a project on a team of 8. There are only so many developers that want to work for [insert company] out in the wild.…

Right, I meant "pulling their weight" in a relative sense, with the understanding that a more experienced and talented employee will do more work or do it more quickly. Maybe my desire is simply to increase the proportion of coworkers who make roughly appropriate contributions to the team effort. I once had to explain how splines worked to a graphics programmer with 20 years of industry experience. A trial process li…

>> I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.

Is the knowledge of splines a major predictor of a graphics programmer's success? I don't understand why it appears to be a point of denigration here. The details of your story are foreign to me, of course, so maybe I'm missing context. But it's always helpful to remember that time is finite when compared to the seemingly infinite amount of things to learn. No one comes to work and says, "I want to suck today!"

Re: Software engineering interview questions

#82

Post by RogerL »

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…

Has it? Besides the number of great people they turn down, the great people that refuse to interview at all with them (I don't know anyone willing to waste their time with a process clearly designed to be biased towards their failure), how much deadwood are in those companies? A ton, by all available reports.

There is a difference between what I call 'clever' and 'smart'. There are plenty of people that are fast on their feet at thinking about algorithmic-y type things. That doesn't translate into an ability to think through engineering problems, drive a project forward, cut through red tape, motivate peers, mentor the less experienced, identify market opportunities, behave ethically, build great teams .. I can go on. There is so much to this job other than manipulating binary trees, and swiftness at doing that at a white board is not a particularly good indicator of being able to think hard about novel problems. My best math professor, ever, had to ask the class to do the arithmetic and often we'd have to correct his algebra steps. He was fantastic, he just wasn't great at doing that stuff on his feet in front in front of an audience.

And, of course, not many jobs require novel algorithms; most require all other stuff. I'd give my eye teeth for an engineer that can just plod through and keep a project on schedule and budget. Don't see how the 'tough questions' identify her.

Re: Software engineering interview questions

#83

Post by cheapsteak »

gortok wrote: post #29

The site sure starts out on 'dark pattern' footing. To sign up, you can link your LinkedIn, G+ (who has that?), github, or Facebook accounts (seemingly, not twitter), but once you do that, they claim there may be a username or email address conflict (even though you haven't provided an email address) so they want your email address as well. The proof is in the pudding: https://twitter.com/gortok/status/54746879416023…

I just signed up via G+ (I may be mistaken, but can't everyone with a Gmail account signin using g+ ?) Did not get any message about email address conflicts

Edit: Just tried signing up with Facebook (which has one of my other email addresses on file), still no message about email address conflicts, signed up and logged me with no issue.

Tried signing up for another account with GitHub and did get a message about email or username conflict this time, but I was using the same email address on G+ as Github so it was a legitimate conflict.

Re: Software engineering interview questions

#84

Post by dreamweapon »

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…

and the amazing difficulty of getting rid of them once they're identified as such

Everyone always talks about how "amazingly difficult" it is to get under-performing people to leave, but really, why is that so? I find that simply saying

"You know, we don't think this arrangement is working out for either of us. Can you please do us a huge favor, and resign? BTW if you agree, here's $X, a perfectly respectable severance package that acknowledges that you are human being, and that this was just as much our mistake as yours."

pretty much always works (provided the company is willing to swallow $X, which if they have any integrity they should have no problem doing). You don't have to say the "this was our mistake part" of course, but that's what the $X is for, because it says it implicitly (and in a more substantial way than mere words ever could).

Of course, there's also the task of getting other people to see that someone is under-performing, which can be quite difficult sometimes -- but that's a separate issue (and if it really is especially difficult to have these kinds of conversations with persons of authority in your group, then maybe you should be moving on, as well).

Re: Software engineering interview questions

#85

Post by propelledjeans »

pkaye wrote: post #56
toomuchtodo wrote: post #32

Earlier quoted context omitted.

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?

The job with the best team. Generally, the job where you have to jump through hoop will have a team who has jumped through those hoops as well. It's all about vetting.

Re: Software engineering interview questions

#86

Post by jghn »

propelledjeans wrote: post #85
pkaye wrote: post #56

Earlier quoted context omitted.

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

The job with the best team. Generally, the job where you have to jump through hoop will have a team who has jumped through those hoops as well. It's all about vetting.

Which is only meaningful if the vetting is for the sort of skills one actually uses day to day.

Re: Software engineering interview questions

#87

Post by aercolino »

barrkel wrote: post #62
vvoyer wrote: post #60

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.

I like to give slightly more difficult versions of these questions as take-home problems, rather than interview problems. Give them out after phone screen, but before in-person interview. And yes, something involving a binary tree order traversal would be the kind of thing that I'd be interested in. Because I want to work with programmers who can code, who at the very least know what recursion is and are able to empl…

For me it would be much more valuable if the programmer knew that a tree wouldn't be needed at all if expressions were represented in reverse Polish notation.

However, in the last 30 years, I needed to process expressions at work and by myself exactly zero times.

Re: Software engineering interview questions

#88

Post by MaxScheiber »

altpaddle wrote: post #51
MaxScheiber wrote: post #45

Earlier quoted context omitted.

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…

Graph traversal is quite relevant to DOM manipulation. More generally, these sorts of "classical" problems come up more than one would assume at first glance.

I believe that understanding the theoretical backing is very important for making correct software design choices, at least at the positions I have held. Moreover, this base knowledge is a proxy for general awareness of complexity analysis and architectural trade-offs (why do we pick this structure over that?). I agree that we needn't consider single-source shortest paths every day when programming, but for companies that want to be sure they are making good hiring choices, this seems reasonable to me. Graphs, for example, come up so often in practice, which is why I refer to them as fundamental. It's not like we're talking about red-black trees here. Again, it's a proxy for one part of what makes a great programmer.

Re: Software engineering interview questions

#89

Post by kyllo »

justizin wrote: post #25
kyllo wrote: post #21

Earlier quoted context omitted.

iterating over the file, incrementing the key/values as they occur Isn't that exactly what the Hadoop job would have to do anyway? The whole point of Hadoop is to process the data in a single pass, which is what your method does. As long as you iterate over the file without reading the whole thing into memory first.

Yeah, if you described an actual fucking program, and their answer was the name of a software package that you could learn in a day and they've been trying to hire an expert in for six months, and you would still just use that software package to run your program, be glad you didn't get the job. ;)

In the general case: if you go to a job interview, and the answer they're looking for on every question is just a buzzword, you don't want to work there.

Re: Software engineering interview questions

#90

Post by aercolino »

If you want to see how they code, why do you want to see their own algorithm? In normal conditions, They would Google the problem and find its algorithm on Wikipedia (with lots of additional information to peruse) and some interesting implementations on stackoverflow (both to choose from and to learn about related issues).

Programming in the wild has very little to do with knowing beforehand or being able to invent on the spot an algorithm.

But the real reason why software engineering interviews are being done that way is because programming is not perceived as an art anymore. Engineers' scope inside the company was greatly reduced, while their number increased. They are now commodity workers: Not only they must be replaceable, but also expanded and shrunk as soon as possible, much faster and cheaper than before.

Post reply on HN