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

Python coding interview challenges

github.com

Post reply on HN
Print view View original

141–150 of 252 posts

Re: Python coding interview challenges

#141

Post by meheleventyone »

jorgemf wrote: post #134

With this type of post I always read comments complaining why they should know those things for an interview. They are not necessary. It is like some more knowledge is going to harm them. I wish I would know more about everything. Sometimes the connection between knowledge and how to solve a problem are not clear when you learn that knowledge. Why is it important to know how is the syntactic structure of a sentence i…

I don't think most people are complaining about gaining knowledge but the relevance of the test to job performance or the requirement to study whilst working and raising a family.

"... you wont be able to discover how to solve a problem if you don't have knowledge about the solution in advance."

Is simply false, whilst research is a skill all of its own it's most definitely possible to go off and learn key techniques when you need too. Relying on serendipity for knowledge to be useful is not very efficient after all.

At best the additional knowledge gained is a helpful side-effect.

Re: Python coding interview challenges

#142

Post by bogomipz »

user5994461 wrote: post #123
bogomipz wrote: post #75

Earlier quoted context omitted.

Sure, that scenario is equally broken and happened to me with a big S.V company recently. If the company can't even schedule an interview with someone on the actual team then I'm probably not interested in the company and can and have cut the phone interview short upon learning that.

It's not enough to be on the team, the person has to be able to talk, not a mute engineer.

I completely agree.

Re: Python coding interview challenges

#143

Post by charles-salvia »

cauterized wrote: post #27

I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them. A company that needs someone to solve these sorts of problems doesn't want me on…

To me this sounds like you just develop dependency-laden bloatware, i.e. you'll throw in some 5 gigabyte Javascript library just to do one thing.

Re: Python coding interview challenges

#144

Post by canttestthis »

collyw wrote: post #138
canttestthis wrote: post #128

Earlier quoted context omitted.

At some jobs we make the libraries you use to solve those problems. These interview questions test very basic CS concepts and many of them are essentially just extremely watered down versions of real life problems. I can teach a dev how to Google for libraries, I can't teach him basic CS concepts. I would much rather hire for the latter. In fact this whole thread makes me uncomfortable. I wouldn't want to work with a…

Sure, but those jobs are few and far between. If you are indeed writing that sort of code, then it makes complete sense to test people on that, but the vast majority of jobs using this style of testing are not.

Even for other jobs, using this style of interviews reduces your false-positive rate, because any style of interviewing thats good enough for the sort of software that this tests for is going to be good enough for them.

Re: Python coding interview challenges

#145

Post by Apocryphon »

Never mind the specifics of the selection process, Silicon Valley's risk-adverse approach to hiring is baffling. Instead of making candidates go through an overly rigorous process, why not embrace California's at-will status and hire and fire often? Employers and employees already view each other with suspicion in terms of loyalty, the former willing to downsize capriciously at any moment, and the latter willing to jump ship every year or two. So accept the mobility and instability of startups. Instead of spending immense resources on the interview process to find the perfect, you focus on getting the good and terminate swiftly if they turn out to be bad.

Not to mention, even when you have these types of interviews it still doesn't seem to filter out toxic people, such as the harassers of Susan Fowler at Uber.

Of course, it would be easier for workers to be okay with this arrangement if basic needs such as health insurance were decoupled from one's employer. That's another argument for single-payer in CA.

Re: Python coding interview challenges

#146

Post by Dolores12 »

cauterized wrote: post #27

I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them. A company that needs someone to solve these sorts of problems doesn't want me on…

> I've never had to deal with one of these sorts of problems in my day to day work;

You are from different niche and actually you are being paid less than those guys who knows the stuff you don't

From [0]:

"[S]killed cloud and backend developers, as well as those who work in emerging technologies including Internet of Things, machine learning and augmented/virtual reality can make more money than frontend web and mobile developers whose skills have become more commoditized..."

[0] https://www.linux.com/news/developer-nation/2017/3/visionmob...

Re: Python coding interview challenges

#147

Post by wpietri »

hibikir wrote: post #87
wpietri wrote: post #47

Earlier quoted context omitted.

You absolutely can test a candidate with real-world workloads. It takes longer than 15 minutes, though. I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.

While I fully agree with you in that interviewing is broken, and it's broken because we throw away a lot of great people, you'll be surprised how much time a company spends finding the right candidate. Imagine we spend an hour per candidate on screening, and we pass 10% of people, and we spend 6 hours on each on site,with 25% of them passing.Finally 50% of candidates accept the offer: This is very typical math, and i…

I probably wouldn't be surprised, having set up hiring processes before. E.g.: http://williampietri.com/writing/2015/slightly-less-awful-hi...

Anybody spending 6 hours per candidate on site can afford to test them on some real work. I'll typically do 2 hours for pair programming, and/or 1 hour for reviewing some existing code. 1-2 hours is also a good amount of time for a joint design session on some real problem.

You're definitely right that we're missing good people. I keep coming across people who didn't get the right job until they invested a bunch of time into learning to beat the Mensa-puzzle interview. So one way to make the numbers better is to find more good people.

I think if we're going to do the math, I also think we need to account for the cost of getting people who are not so good. If we test some thing that we hope correlates with doing the work, we're asking for large downstream costs. The more our interview tests what people actually need for long-term success, the better off we are.

Re: Python coding interview challenges

#148

Post by wpietri »

x1798DE wrote: post #58
wpietri wrote: post #47

Earlier quoted context omitted.

You absolutely can test a candidate with real-world workloads. It takes longer than 15 minutes, though. I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.

You are often weeding through a large number of applicants, so spending 100 hours on each candidate is just not feasible, and, generally, not necessary. Plus, high quality, experienced developers are not going to want to spend 100+ hours doing real work for companies just to see if they can get a job. I'm more than happy to spend an hour here or there for a phone screen or coding test to show that I understand the ba…

Then it's a good thing I didn't suggest spending 100 hours per candidate.

Re: Python coding interview challenges

#149

Post by jacquesm »

Paul-ish wrote: post #136
jacquesm wrote: post #118

Earlier quoted context omitted.

Your typical interviewer, if he or she does not have relevant knowledge is just as likely to throw out the baby with the bathwater as they are to select the right candidates. There is no reason not to have the team do the pre-selection. I know this is all terrible news for recruiters and HR people alike but really there is nobody better qualified to determine who they want to work with on a particular problem than th…

What do you do when tons of people apply for a position?

Find a better way to reach your target audience. Getting people to self-select is the very best way to reduce the load from interviewing.

Re: Python coding interview challenges

#150

Post by fnl »

jorgemf wrote: post #124
logfromblammo wrote: post #110

Earlier quoted context omitted.

Not revealed as a terrible company, perhaps, but as a terrible interviewer. If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries. That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm g…

> "before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index" How I am going to ask you to tweak an index, if you don't know how to browse a tree? Although I would have asked you about B+ and B* trees, the ones used to index a database. There are differences in those trees and you need to know t…

How big is the chance that you select the candidate who happens to know all solutions (e.g. by learning them by heart recently for the dozens of interviews he's planning on doing), but is not a good technical fit? My estimate is: pretty high; Let me explain why.

If you indeed need someone who knows about B* vs B+ trees, why not ask him about that separately ("explain me the difference between ..."), to see if he has the technical background you need? Even if someone understands that difference, that same person might have problems getting DFS right during the whole live interview, for a number of completely irrelevant reasons (nervousness, a momentary lapse, being a bit "rusty", a.s.f.). For the candidate to know the difference between a B+ and B* index/search and to operate a database correctly doesn't require the ability to implement DFS flawlessly (and most likely will never require the person taking a shot at that, for that matter...)

I think the real problem is that some people don't seem to understand the goal of these questions. If you do algo whiteboard questions (and you should!), you should measure the candidate's behavior, reactions, and analytical skills, while attempting a solution with you - and not to find out if the provided solution is correct or not (indeed, its often more interesting when the solution is not and you work with the candidate on locating the issue!). And all the while, the interviewer can try to figure out if he/she wants to work with that person, given the current interaction, too.

Post reply on HN