Tangential question - why does the HN crowd hate these types of questions in interviews but apparently likes to do them on their own time? Different folks answering to different posts? Honestly curious.
Tangential question - why does the HN crowd hate these types of questions in interviews but apparently likes to do them on their own time? Different folks answering to different posts? Honestly curious.
- You can take your time, no pressure.
- You can use whatever language or paradigm you like.
- You don't have to explain anything to anyone.
- You are not ashamed of using hacks or shortcuts.
- It's a learning exercise if you are using a new language.
- You can google for things like "I know this problem needs A* but I forgot how to implement it", which show you know the important part, how to solve the problem, but forgot the useless part, the algorithm itself, which you can easily google.
- There's a single, objective answer to the problem and it gives you hints about it (too low, too high).
If interviews where like this where I could do problems at my own pace at home and then later in the next interview we'd discuss my solution, interviews would be way less stressful and interesting. The interviewer would even know how long I took to solve the problem.
(Now for context, the interview questions I typically would recommend are a order of magnitude easier than AoC's typical bar, in the language of the candidate's choice, ideally on a real computer and not a whiteboard. Tonight's question though (a warmup) wouldn't be a bad one. It's straight-forward, no trickery, nothing clever, and directly applicable to real-world coding. And it would screen >50% of candidates that I'd give it to.)
No, or you're strawmanning the type of interview that is being suggested here. No, the challenge is about solving the problem; it doesn't take "creativity" to find the maximum in a list of integers, and the problems a SWE is going to encounter in the real world far dwarf such a question in terms of difficulty or "creativity" required to solve.
Some of the rougher AoC problems are harder, yes a bit more so. But a.) I qualified that that's not in context here in the original comment and b.) even there, it often isn't creativity that's required, it is knowing your basic principles, e.g., what data structures exist and when to apply them. But HN has an anathema when it comes to this sort of stuff; heaven forbid that SWE requires skills.
> I think that pressure can be good for creativity but it can also be it's death. However, motivation is important for creativity. Competing online with other like minded people is a good motivation whereas a job is something you need literally in order to survive. It's not really comparable imo.
This is mostly non sequitur. There's no eliminating stress completely from an interview, but depending on what tech I have handy, allowing the candidate a full REPL, access to reference material, coding in an IDE and language of their choice are all there to reduce stress and let the interview focus on what hopefully the candidate is good at.
I'm not attempting to compare competing online with an interview: you're not competing online in one of my interviews. The sort of problems, however, as an example of what might be asked in a coding question is the scope of what is being compared here. The point is: a. they're not the infamous sewer lid question b. they don't require "one clever insight" to solve and c. they in many ways mirror real-world issues. (E.g., parsing an input, taking an english description and turning it into relatively simple code.)
I just want to mention though, I am not trying to criticize "your interviews". It seems like you put quite a bit of thought into it which i think is great and every interviewer should.
(We do not ask in interviews questions of the same nature as the last third of AoC. If anything, most of our interview questions are below AoC day 1 in difficulty. And yet they screen absurd numbers of candidates.)
While I've definitely encountered tougher than this AoC in interviews, I find I have a hard time maintaining that bar: I have to push to maintain even the bar of this day's AoC question (e.g., "write min()") as it turns away sufficient number of candidates that hiring managers start looking to lower the bar, which is absurd.
(But that said, when I encounter tougher problems, they're not tougher than about mid-AoC, which is still well within reason, to me. They're still not the infamous sewer lid. Nobody is asking the sewer lid question anymore, and collectively we need to stop propagating that myth. It was banned at Google well over a decade ago…)
(Ultimately, it seems to me to be an economics problem: we're not attracting good devs, which means we're not offering good devs something enticing enough; we're left with the subset for which our offer is enticing, but that isn't what we're looking for. But I can't solve that problem.)
I don’t think this is a problem per se, I think it’s very egalitarian, but it’s also not difficult to see why people might be uncomfortable or complain.