Hacker News new | ask | show | jobs
by mikymoothrowa 1493 days ago
> It doesn't require knowing a language well, but only well enough to solve the problem.

I guess that really depends on the language. IMHO, if you can solve a reasonably complex problem using a language, you know that language.

2 comments

I am on the interview team for the company I work for and I wrote what some consider to be our canonical python solution (fastest and simplest) for one of the problems we use. I had to look up the syntax for a "for loop" because I hadn't written python since my first year at university. To me, being able to stitch together simple concepts present in almost all mainstream programming languages doesn't mean I know python, it means I know how dynamic programming works. I don't know the python ecosystem (history, present, or future), know the standard library, know what idiomatic code looks like, deeply understand what makes the language unique, have the mindset of a python programmer, etc. Maybe I just have a high threshold for feeling like I "know" a language.
i did a leetcode interview in c++ and didn’t remember some syntactic details of lambdas and that was the end of it. please stop with this nonsense that interviewers are understanding and that you can look things up or that you will be able to take your time to produce the optimal solution to a problem.
Well I can't speak for other interviewers especially at other organizations, but I try very hard to make it a positive experience. In fact I'll give as much help as necessary to get to a working solution, within reason. I would much rather fix the lambda syntax myself or help the candidate find an example on stackoverflow so we can go back to the interesting part. If the interview ends with a working solution but needed a ton of help, the candidate probably did not pass but maybe they learned something. And maybe they'll tell their peers that it seemed like a place where they could fail without embarrassment, collaborate, and learn.
This doesn't seem right at all. I can kludge together a solution to an arbitrarily complex problem in any language, but that doesn't mean I'm writing it in a way that can be extended and developed upon by other people. The latter is also what takes up the majority of development time.
A one-day interview can't test you on things that take up the majority of your career time.