I personally find "What is your favorite programming language?" or "What systems architecture to you find more compelling?" to be far more valuable. It gives some insight into their commitment to the trade and gives you an opportunity to make it a conversation to dive into their reasoning process and depth of knowledge about a topic. I think it's far easier to weed out the fakers if they can't express why Erlang is interesting to them than for them to tell you how to implement a linked list which is very easy to google and memorize(but won't necessarily prove any skill).
Python coding interview challenges
101–110 of 252 posts
Re: Python coding interview challenges
#102Re: Python coding interview challenges
#103From what hear about some startups, the challenges are for the general candidate pipelines the company wants to weed out w/o fearing legal repercussions. The inside-track, friends, and frat candidates often get to skip right through the process or have copies of the problems/answers from insiders. (Illusion of merit.)
I have heard about larger companies / government agencies having these kinds of interviews due to internal procedures, but hopefully most startups have more sane setup.
Re: Python coding interview challenges
#104[1] https://nbviewer.jupyter.org/github/donnemartin/interactive-...
Re: Python coding interview challenges
#105From what hear about some startups, the challenges are for the general candidate pipelines the company wants to weed out w/o fearing legal repercussions. The inside-track, friends, and frat candidates often get to skip right through the process or have copies of the problems/answers from insiders. (Illusion of merit.)
I think this view is a little bit cynical. Hiring your friends which usually happens in the early stages is often more about having worked with them before or having them come in based on a recommendation / knowing they're a culture fit ahead of time etc. It's a way for small startups to spend less time on hiring, and increase their chances of getting talent that they couldn't necessarily attract on the broader marke…
- Because it is actually a good predictor of job success (does anyone think this is the case for anything but a handful of job roles?)
- To be adding a hurdle to target those who really want the job (downside: it also adds a hurdle to top-notch gainfully employed people who dont have time to study for such exams)
- Another is they just need something to reduce an otherwise overqualified pool of already qualified candidates (fair point, but at the risk of losing out candidates from concern one above.)
- Legal risk mitigation -- add a quantitative measure to show a facade of merit and process.
TBH, I have never been on the hiring side at a small firm, so I don't know. But I have seen several things:
1. People recruiting me to Amazon and practically giving me the exam questions (I declined mostly due to location) Same thing at two other firms (perhaps to get referral bonuses?)
2. An H1B process that is by-the-book correct yet entirely against the spirit of the program.
3. Tons of interviews, screenings, etc at big firms just to justify an already-decided inside candidate. This I witnessed firsthand and makes me really upset because of all the candidate time they waste and the false hope they give to people who were never in the running to being with.
Re: Python coding interview challenges
#106Earlier quoted context omitted.
How are companies supposed to evaluate candidates without giving them some form of busywork? The best way I can think of is to pay them to complete a project but that's not possible when you are interviewing loads of candidates.
Introduce them to the team they will be working with, have them do a code review or take a ticket and find their way through docs and discuss a potential solution. In general teams are a much better judge of talent and ability than recruiters or your typical interviewer, especially in a normal work setting.
Re: Python coding interview challenges
#107I 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'm a kick-ass get-things-done full-stack web engineer. And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.
Re: Python coding interview challenges
#108Looks like a fun bedtime reading material to me.
I'd say read this kind of stuff on regular days, not one night before interviewing, and peeps would do just fine.
Re: Python coding interview challenges
#109Earlier quoted context omitted.
I was going to agree with you, 98% of my career has been "google for a library, then use or tweak". It's RARE we ever actually do anything "new". However there ARE companies that do, and every once in a while YOU may have to do something new. In those cases it's good to make sure you have a foundation to build on. I have 4 books in the "The art of computer programming" series on my desk. They've been more or less dec…
In that 2% of the cases where you have to come up with something new, I don't really think that knowing pretty much any of this would help. You are storing a lot of information that will probably never be used. On the other hand, knowing how to come up with the solution. Knowing where to ask, what books to read or what people to ask, seems like a more important skill.
Re: Python coding interview challenges
#110Earlier quoted context omitted.
> If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?
No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.
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 going to need to be doing that instead of just writing an SQL query and tweaking an index, which is likely what I would be doing at most companies.
Part of development is figuring out not just the answers to the questions, but also figuring out "Of all the questions I could have been asked, why was I asked that question?"
A disappointingly large fraction of the time, the answer to "why did you ask that question?" is "we noticed a correlation, confused it for causation, and built an entire strategy around it".