31–40 of 340 posts
One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…
at this point of my career i straight out refuse technical/coding interviews i have a GitHub account with 7 years worth of contributions, multimillion dollar exit, projects online and previous senior roles on my cv if they still don’t trust me to do my job, the one i’ve provably done about a decade, their loss nowadays it’s easier to find high-dollar consulting gigs than deal with dysfunctional hiring processes advic…
I have 25 years of experience and I spent a year looking for a job, getting rejected after complex, time-wasting tests and endless voice interviews that went nowhere. At one point I had to take a cognitive test which I actually failed. I eventually found something but it was really discouraging there for a long time.
I conceptually like the idea of dropping coding screens, etc - but how do you objectively identify what you're looking for in a candidate without adding bias to the process? I.e., at least with a coding question, you can set up objective criteria. If you ask someone about their work, it might be a good experience but you're also setting yourself up to bias towards people who talk/think like you.
If you really want to test someone's coding, let them do some coding in their own time with their own tools and send it to you. This isn't ideal, since it can be time consuming, but I think it's more humane than live coding in some weird environment.
at this point of my career i straight out refuse technical/coding interviews i have a GitHub account with 7 years worth of contributions, multimillion dollar exit, projects online and previous senior roles on my cv if they still don’t trust me to do my job, the one i’ve provably done about a decade, their loss nowadays it’s easier to find high-dollar consulting gigs than deal with dysfunctional hiring processes advic…
One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…
I have 15 years of experience, and seem to woo teams every time we do screening calls. Could be how he describes the problem. Most of the time during code screens they don't want you to perfectly solve it. Talk it out. Someone who feels that perfect or bust is the only way to go will fail most of the time. Idk feels like something is missing. He's right, feedback loops suck. Question is... Can he practice doing a pho…
> Talk it out I personally hate this approach. Solving programming problems requires my full focus and vocalizing while trying to think is a challenge (partially due to my stutter). I can either focus on communicating clearly and professionally or I can stfu and code, not both. I’m happy to solve a problem silently and talk about it after I’m done, but I won’t do a phone screen that asks me to word vomit in the middl…
To mitigate this I try to constantly verbalize things that I'm thinking anyway, like, "This isn't the OO way to do it, but I think the OO way would be a poor match for the problem," and, "In real code I would model each of these item types with a class, but to save time and hopefully get further with the problem I'm going to model them as lists." The more I talk, the less they talk, and the less often I have to reboot into human mode.
I have 25 years of experience and I spent a year looking for a job, getting rejected after complex, time-wasting tests and endless voice interviews that went nowhere. At one point I had to take a cognitive test which I actually failed. I eventually found something but it was really discouraging there for a long time.
23 years here and at this point I consider interviews to be 1d100 random dice rolls. No matter how much you prepare there is no way you can predict how sensible the interviewers are. I figure just deal with it and interview more. If each interview is 1% independent chance of getting an offer, and you interview 50 times, you have a 40% chance of getting an offer.
I have 15 years of experience, and seem to woo teams every time we do screening calls. Could be how he describes the problem. Most of the time during code screens they don't want you to perfectly solve it. Talk it out. Someone who feels that perfect or bust is the only way to go will fail most of the time. Idk feels like something is missing. He's right, feedback loops suck. Question is... Can he practice doing a pho…
> Talk it out I personally hate this approach. Solving programming problems requires my full focus and vocalizing while trying to think is a challenge (partially due to my stutter). I can either focus on communicating clearly and professionally or I can stfu and code, not both. I’m happy to solve a problem silently and talk about it after I’m done, but I won’t do a phone screen that asks me to word vomit in the middl…
The author is focused with technical review, and as such he probably fails to see just how important personal review is. Yes, you are being reviewed technically, but you are also being reviewed personally. You may know a lot of technical things, but do I want you on my team? The phone interview is what i'm going to use to make that decision. Technical we can work over later, but only if you sound like someone I want on my team.
I'm always willing to say, "They look like a great fit for the team and our goals, and let's give them a chance to learn the tech" versus, "They know a lot of technical stuff and let's give them a chance to see if they can learn to work with other people."