321–330 of 340 posts
I too can pass on-site interviews, but my problem is I don't even get a first phone screen to begin with, they discard me without even spending 5 minutes on me.
You Americans (even afroamericans) have absolutely zero clue about how racist your companies actually are.
"But Google and Microsoft CEO are Indian!" Yeah, but not really.
By the way, I'm Southern European, with a Southern European sounding name.
Earlier quoted context omitted.
>so if they do well on leetcode you just assume they did well in their past jobs. wat? how did you draw that crazy conclusion? even competitive programmers says that there's probably negative correlation between good engineer and competitive programmer and I'm saying this as a person who doesn't mind having to solve algo questions
> even competitive programmers says that there's probably negative correlation between good engineer and competitive programmer They don't. I've worked with some of the best competitive programmers in the world, they do think it is a positive and look for people with a strong competitive programming background. However, if your interview process only selects for ability to solve algorithm problems, then people with a…
That's fair
I'm unable to find what I've been reading, probably some thread on spoj (edit I found this [1]) or this https://codeforces.com/blog/entry/17302
for now I only found this
https://www.youtube.com/watch?v=F4rykKLcduI&t=435s
by https://codeforces.com/profile/Errichto
_____________________
[1] - https://discuss.spoj.com/t/spoj-a-praca-i-zycie/26380
https://en.wikipedia.org/wiki/SPOJ
Title: SPOJ & work and life
It's written in Polish, but as I see that was about kinda different thing
>How were SPOJ and programming skills useful in the context of your studies?
>Virtually not at all. I will say more - these skills were an obstacle in obtaining the title of engineer.
>
>...
>How useful are SPOJ and specific, classic algorithms at the programmer's work?
>Wandering around the labor market, I got the impression that it was easier to become a programmer with a vague idea of algorithms and extensive experience in creating specific projects than being a master of all kinds of algorithms, but without experience in coding something bigger.
So the point was kinda different than I remember
_____________________
Earlier quoted context omitted.
> There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes. I don't know what to say to this beyond, absolutely yes this situation exists. The easiest scenario is you are on call and get paged and must solve a critical issue in as few minutes as possible.
What kind of shop are you working in which requires you to solve algorithms puzzles to resolve outages? Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Implementing a better or more scalable or more r…
Sure, that's nice, but you're living in a fantasy if you expect that to always be possible.
I also didn't say anything about implementing scalable or more resilient, or even algorithm puzzles. That's not what we're discussing.
I'm talking about communicating when problem solving. If solving an outage was always a mundane rollback or simple intervention, then it should've been automated. For example, say a new deploy corrupted the database subtly. How do you recover it? Perhaps you rollback the deploy, create a new database instance from a backup, perform a cutover, lock writes, write a migration to copy records from the old instance to avoid losing data written since the backup, validate the restore, unlock writes, monitor. You probably also need to work with stakeholders to draft and send comms to customers, document the steps you took, answer questions from product folk.
This is what I am trying to get signal on in an interview. How do you work on your feet, when it matters most. If you expect to be able to sit in silence for 30 minutes after you were paged while you draft a solution in your head then you're going to have a bad time.
For a junior candidate, these expectations are reduced, but this is the bar for a senior candidates. If I wanted you to solve an algorithm puzzle I'd give you the puzzle and tell you to come back tomorrow. If I didn't think you could solve an algorithm puzzle, we wouldn't be having a conversation.
Communication is the whole point.
Earlier quoted context omitted.
When one of the mediums actively helps and avoids small human errors, I'd prefer the person knowing using it instead of sticking an old and imperfect method out of pride.
> When one of the mediums actively helps and avoids small human errors How does it actively helps and avoids small human errors in reasoning. > I'd prefer the person knowing using it instead of sticking an old and imperfect method out of pride. What does even pride have to do with this?
Because reasoning is only a part of everything to be done. An IDE can help with typos, best practices ( global variables, lack of error checking, etc) which are tedious things that take time. Isn't it better to the things that matter instead?
Earlier quoted context omitted.
> he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo and he floundered the entire time If I was floundering because the interviewer found a hole in my knowledge (and there are many holes in Albert Hall) I'd proactively state that and say where the holes weren't and ask for a question about that. For example, I've implemented a complete C compiler, front to back, so at one point…
> There's no reason at all why the interviewee cannot drive the direction of the interview, rather than being driven. You know how they made a program pass the Turing test? They didn't make it smart, they hardcoded a conversation where the program drove the conversation to where it wanted it to be. That way the person interacting with the program was passive, so they never noticed that they were just interacting with…
Often I feel like a con artist for doing this, especially if works to overcome a superficial interview. Sometimes it turns out my perception was correct and yet it turns into a better interview because I’m adding value to the interview where the interviewer had gaps…
Earlier quoted context omitted.
Nothing jumps out to me as overwhelming proof of programming ability. Are you suggesting that leetcode tests provide "overwhelming proof of programming ability"?
Not gp, but obviously yes. I'm yet to meet someone who can pass a leetcode-style interview with sober and conscious interviewers, but can't code. Have you? Leetcode and coding ability is an A -> B but B -/-> A situation: failing leetcode doesn't mean you can't program, but the reverse is absolutely the case. Leetcode can't filter out other potential issues that may impact success (e.g. poor anger management, or poor…
I should perhaps be clear that by "overwhelming proof of ability" I meant "the ability to program well". Which by definition does intersect with one's capacity for judgement, on a certain level. (Though is largely orthogonal to other behavioral issues, I find).
I see LC as providing proof of, at best, minimal ability. And I've seen plenty of people who can run circles around LC-style tasks, but when it gets to the bigger picture -- you know, writing good, maintainable software -- somehow, it just never comes together right.
We agree that obtaining proof of minimal ability is important. I just think that proof can be obtained in other, far less mutually degrading (and error-prone) ways.
Earlier quoted context omitted.
To quote the author, > Triplebyte has a quiz that actually does a pretty good job of this; you get asked thirty or so questions about databases, networking, and simple coding questions ("what is the value of 'a' when you get to line 17?"). I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.
Definitely much more subjective than algorithm interview.