I never ask LeetCode questions because it’s far easier on both sides to ask experience-based questions like “what do you like/dislike about <technology on your resume>?”
If I get superficial answers that tells me something. If i get well thought-out answers from people who have clearly spent time in the trenches that tells me something too.
Back when I was doing C/C++ interviews, I'd ask questions like:
What's the difference between single and double quotes? A meh candidate answers something about you need single quotes for just a single character. A good candidate answers about how the data type for a double-quoted constant is a char.
If I want to pass a variable into a function, and have its value changed by the function, what do I do?* A lousy candidate says "put an ampersand in front of it". A meh candidate says to pass a pointer to the variable. The best candidate will talk about the difference between call-by-value versus call-by-reference.
People really do reveal a lot about themselves not just in what they say, but the way they say it.
(personally, I would be a meh candidate until you probed further - but I've not touched C for.. hmm, I'm old)
I often get questions where I need to determine if they're looking the textbook answer, or a real-life answer. Usually I will go with "well generally, the answer is $Textbook. However, ..."
I agree it's good for a candidate to demonstrate a solid understanding of evaluation strategies, but the way you phrased the question, the 'meh' answer seems about right. You asked what do I do? which invites a narrow answer specific to the language.
In fact, I had an instructor in college that would have marked you down if a quiz/test asked this question and you wrote an entire paragraph describing call-by-value versus call-by-reference.
On the final, he said "Each of these questions is answerable in 1-3 sentences. If you're writing 1-3 paragraphs, you're wasting my time and I will subtract points even if your answer is correct."
Forgive a painful mixing of metaphors: if the Workplace StackExchange is anything to go by, one interviewer's flying colours are often another interviewer's red flags.
This is absolutely true.
In /r/RecruitingHell, I recently saw a job seeker saying a hiring manager dropped them after they tried to connect on LinkedIn during the interview loop. Meanwhile, another HM in another loop praised them for it.
Yup.
There's a fine line between giving a thorough answer and just vomiting up everything you know that's slightly relevant to the original question.
I do AppSec. If I'm interviewing a candidate, and I ask them what Cross-site Scripting is, then if at some point during their answer they bring up SQL Injection, that's a red flag.
What's the email address: To email, send to the domain [redacted], using the mailbox "[redacted]".
In general, email addresses consist of a username followed by the at symbol (@) and the domain name, such as [redacted]@[redacted]. However, without being able to verify the existence of the domain [redacted], I cannot say for certain what the email address would be.
In theory, it's at will employment yada yada. But in practice, it makes a difference.
there are sites online, like the whoishiring threads here. i’m running https://hourly.fyi/jobs/
TLDR why leetcode in private when you can work in public*
(*yes yes, not everyone can work in public, but i bet a fair amount of you can but havent given it a real shot)
It wasn’t that much or that bad, really. The setup was pretty simple, and quite doable for junior devs IMO (though full disclosure I had just left a position as a lead game programmer, so for me specifically it would have looked a little bad if I didn’t smash this particular interview question). It also helped that the problem was open-ended with extra credit features. I learned later when giving the interview myself that most people never finished the basic game, the majority never tried to write an AI player, and the interviewers were quite forgiving with their ranking & scoring - it was adaptive to the candidates. The coding part of the interview was just trying to be a bit fun and not just be pure dumb LeetCode problems. IMO it worked, I totally enjoyed the interview. The rest of the 4 hour interview included some whiteboard questions (on DB schemas, which I flubbed pretty hard) and also a lot of just talking about experiences and goals.
I've never done anything spectacularly fancy with CLI terminals. I could rig up a UI with c++ and qt, or python and tkinter.. but it's been a while. Longer ago, I used to do objc but that was forever ago!
So yea, I'd die on this one hahaha.
I should try it sometime. I love tetris!
Re: ridiculous C++isms and embedded C, I’ve been in the same spot for my entire career. After learning C++ in college, I joined a CG film company that had banned C++ (dumb story) so I learned how to write object oriented C. Working in console games after that, we weren’t allowed to use any built-in memory management or exceptions or a current compiler, so very restricted C++. (And the worst bug I ever fixed was when someone tried to get clever with their C++ copy constructor.) These days I use CUDA, which is also technically C++ but basically C.
I think this is dismissive of their talent, relative to other people who might try doing the same.
To be fair, swyx was also being dismissive of their talent "Just work publicly and you don't have to prove your coding skills!", which of course assumes your talent will be evident to anyone glancing at your public work. In my opinion, making incredibly complex work look effortless, and therefore easy to follow, requires exceptional talent.
I believe those who are popular content creators are also better at marketing and sales. Getting their work recognized means that their marketing talent is good and not necessarily their programming skill relative to other people who are doing the same.
When looking from that perspective - are you optimizing for hiring people with good programming skills or those with good marketing skill?
You can take a traditional career path, or you can carve out a niche somewhere.
Most of interesting questions had to do with system design and debugging, soft skills (also system design and debugging, but of systems made out of people instead of code) and code reviews — with me reviewing their production code. Sometimes I got pretty stupid interview questions like remembering REST spec (there isn't one) by heart, but those were companies I wouldn't want to work for anyway.