> you can't expect even an amazing programmer with decades of experience to understand what the hell you were trying to do with your code -- in a
reasonable amount of time.
... That's a software engineer's everyday job, specially when just starting a new gig. In fact, the "reasonable time" part is often a pipe dream.
Someone unwilling (or unable) to read and try to understand someone else's codebase has no place doing technical interviews. That's literally the first thing that a new hire has to do.
You might have half point if you were saying that you discuss someone's portfolio during the interview (which would be analogous with the new hire discussing the code with the rest of the team to better gauge the decisions made), but you've said that you dismiss it and instead defend tests.
Speaking of that defense of tests: surgeons also had to do tests in medical school, yet they're not asked to perform routine surgery as part of their interviews (that I know of). This is to say that you were using a false equivalency.
> I'm sorry it's less comfortable than posting online, but it's reality.
Evidently, it isn't. What makes it easy for you (which is ultimately the real reason for those pointless tests) is not the optimal process. It's, in fact, the entire problem discussed in the FA and the comments here.
> Leetcode doesn't have more weight than projects in my book, and I didn't mention it, neither did the top comment
From the top comment:
>> At least, that was the reason they gave for ignoring the links I sent, and instead, giving a binary tree "Draw Spunky" test (I don't do well on them; never have, never will. I spend exactly 0.0 hours on HackerRank [emphasis mine], practicing).
What exactly were you going for?
> The discussion in this sub-thread was about interviews & online portfolios
One of the main points of the top comment was the explicit and deliberate dismissal of the commenter's portfolio in favor of leetcode type tests. I refer to the paragraph I just quoted.
> and it's really, really hard to [stand out as a programmer] with code alone.
Interesting, most of the programmers I know of, I know of them because their code is great; I'm here mostly thinking of authors of widely used open source software.
To reference a famous anecdote: I'd hire the creator of homebrew on the spot. You wouldn't even give him an interview.
> you can take more control of your interviews, and work to protect your own time.
In other words: Potential candidates should make your job easier by continuing the drill this whole discussion is about instead of complaining about how ineffective it is. How much of a problem this whole charade is.
That's just borderline insulting, and it's pretty clear that it is deliberate. I'm surprised it flew here, specially considering the featured article(s) and most of the other comments.
> If you paid attention in school and understand algorithms, them [sic] you should think of algorithm questions as the easy part of the interview, something you can pass without problems.
You called yourself a great programmer, I'll make no comment on that, but you've given me a good idea for how to screen which engineers should participate in interviews for when I have my own company: I'll ask them what they think of algorithm questions and I'll ask them whether they think that what is taught in college should be enough to pass those questions.
If they respond on the affirmative, I'll ask them the most obscure thing I can think of from any of my physics or calculus classes. Hey, after all, they "studied that in college", they ought to remember it even though it would be a gigantic coincidence if they ever actually had to use that knowledge in their job, and the question should be an easy point, correct?
Hopefully that will be a teachable moment, on how responding on the affirmative was wrong, maybe even unethical (because I sure wouldn't have asked that during their own interviews, with one caveat).
And this is, of course, ignoring the whole point of the featured article and the original one this is a follow up to: algorithm questions have devolved into being far more difficult than anything anyone had to do in college and they're something that 99% of candidates would never have done, or needed, in any previous job.
> The questions are there to see if you care about algorithms and understand the basics.
They aren't, GP comment was on the money by saying that they're just there for the interviewer to feel smart.
> Don't take them personally, and understand that the questions are for all candidates, and they need to filter people out who don't know algorithms.
Filtering out people who don't remember (as opposed to not knowing; for remembrance only a short refresher is needed, but that's something that a coding test doesn't give the time for) algorithms is a terrible practice unless the company doing the hiring is explicitly researching for algorithm design and creating knowledge as opposed to applying existing knowledge.
Or, in short, most people won't ever need to dive deeply into algorithm design in this field (most, if not all, of the algorithms needed are already baked into the commonly used libraries), meaning that filtering out the ones that don't remember is pointless at best, self-defeating at worst.
For the very rare cases (outside of the aforementioned companies that need to create new stuff for their products) where reimplementing an algorithm is needed (and there better have been enough research to know that it's not an example of NIH), a couple of hours of getting reacquainted with them is often enough.
> So stop complaining about the easy questions
You've given no reason to. In fact, by rationalizing it, you helped me see with even more clarity how much of a problem this is.
> Also, just FYI people who complain about certain kinds of interview questions is a small red flag in my book.
That's good, every person you rejected for that reason (along with the ones rejected over tests, specially if they had portfolios) clearly wasn't a culture fit and they are better off in a different company.
I just wish they could have dodged the whole hiring process you employ. Then again, I wish that for everyone, myself included.
> If you love programming, algos might not be the exact thing you want to do, but it's part of the job pre-requisites and basic knowledge
They aren't prerequisite for 99% of the jobs and I would say that, if you love programming, you would, well, program and let everyone know you do, like by contributing to open source software and building a portfolio. And yet you would barely spend a second of your time looking at someone's portfolio.
So whose criteria for "someone who loves programming" is the right one?
Finally, a disclaimer: I often do well in those stupid tests and have never spent more than a few weeks in between jobs, while my online portfolio is pathetically barren. Just to put in perspective that one can hate everything about the problem and rightfully complain about it while still having to play, and mostly knowing how to play, that awful game.