Readit Newsdbrumbaugh commented on A secret poker game you can play on the subway experience.prfalken.dev/e... · Posted by u/oktcho
Clicked off as soon as I read "let's dive into"
> [...] adding a layer of excitement and unpredictability to your journey.
That's the bit that did it for me.
dbrumbaugh commented on AI killed the tech interview. Now what? kanenarraway.com/posts/ai... · Posted by u/ghuntley
What I've been thinking about leetcode medium/hard as a 30-45 minute tech interview (as there are a few minutes of pleasantry and 10 minutes reserved for questions), is that you are only really likely to reveal 2 camps of people—taking in good faith that they are not "cheating". One who is approaching the problem from first principles and the other who knows the solution already.
Take maximum subarray problem, which can be optimally solved with Kadane's algorithm. If you don't know that, you are looking at the problem as Professor Kadane once did. I can't say for sure, but I suspect it took him longer than 30-45 minutes to come up with his solution, and I also imagine he didn't spend the whole time blabbering about his thought process.
I often see comments like: this person had this huge storied resume but couldn't code their way out of a paper bag. Now having been that engineer stuck in a paper bag a few times, I think this is a very narrow way to view others.
I don't know the optimal way to interview engineers. I do know the style of interview that I prefer and excel at[0], but I wouldn't be so naive to think that the style that works for me would work for all. Often I chuckle about an anecdote from the fabled I.P. Sharp: Ian Sharp would set a light meter on his desk and measure how wide an interviewees eyes would get when he explained to them about APL. A strange way to interview, but is it any less strange than interviewing people via leetcode problems?
0: I think my ideal tech screen interview question is one that 1) has test cases 2) the test cases gradually ramp up in complexity 3) the complexity isn't revealed all at once; the interviewer "hides their cards," so to speak 4) is focused on a data structure rather than an algorithm such that the algorithm falls out naturally rather than serves as the focus. 5) Gives the opportunity for the candidate to weigh tradeoffs, make compromises, and cut corners given the time frame. 6) Doesn't combine big ideas (i.e. you shouldn't have to parse complex input and do something complicated with it); pick a single focus. Interviews I have participated and enjoyed like this: construct a Set class (union, difference, etc); implement an rpn calculator (ramp up the complexity by introducing multiple arities); create a range function that works like the python range function (for junior engineers, this one involves a function with different behavior based on arity).
>Take maximum subarray problem, which can be optimally solved with Kadane's algorithm. If you don't know that, you are looking at the problem as Professor Kadane once did. I can't say for sure, but I suspect it took him longer than 30-45 minutes to come up with his solution, and I also imagine he didn't spend the whole time blabbering about his thought process.
This is something that drives me nuts in academia when it comes to exam questions. I once took an exam that asked us to invent vector clocks from whole cloth, basically, having only knowledge of a basic Lamport clock for context. I think one person got it--and that person had just learned about vector clocks in a different class. Given some time, it's possible I could have figured it out. But on an exam, you've got like 10-15 minutes per question.
The funny thing about it is that I do the same damn thing from the other side all the time when working with students. It's incredibly tempting once you know the solution to a problem (especially if you didn't "solve" it yourself, but had the solution presented to you already) to present the question as though it has an obvious solution and expect somebody else to immediately solve it.
I'm aware of the effect, I've experienced it many times, and I still catch myself doing it. I've never interviewed a candidate for a job, but I can only imagine how tempting it would be to fall into that trap.
dbrumbaugh commented on Using eqn for static website equation generation douglasrumbaugh.com/post/... · Posted by u/heraclius1729
Hey all--the author here.
I just want to clarify one thing that I didn't think to mention (but probably should have) in the article itself. I went out of my way to use eqn specifically because I wanted to use that particular tool here. I write LaTex a lot on a day to day basis, and wanted to play around with something else. So this wasn't a case of picking eqn because I thought it was the best tool for the job.
dbrumbaugh commented on Using eqn for static website equation generation douglasrumbaugh.com/post/... · Posted by u/heraclius1729
I use KaTex (https://katex.org/) as part of static site generation, and I get LaTeX quality output (because it duplicates LaTeX's algorithm) using only CSS.
Using the eqn and troff suite in 2025 ... I'll just say there's a better way. LaTeX is arcane enough, but at least it is a universal standard in mathematical publication that it pays off to learn a little.
Oh, absolutely. I just have an unhealthy fascination with old tech, so I went into this with the specific goal of using eqn, rather than LaTex. I write LaTex all day for my day job, and I wanted a reason to use something else.
https://www.youtube.com/watch?v=um-7IlAdAtg