121–130 of 679 posts
-organized intelligently
-has simpler explanations than you find online
We’re super proud of our content and just recently 2 people have landed Amazon with us. People actually feel ready for interviews with us. Give it a go :).
[flagged]
8 hours of software development is more than enough practice for a developer. Having an employee with a well balanced life is superior to one who is unable to detach from his work.
I've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a…
I'm in ops and we've found that simple exercises are better at weeding people out than complex ones.
"The martini may be simple, but it is not easy to make an excellent one. It's a very solid test of a bartender's skill because, unlike many drinks, ingredients alone cannot carry the cocktail. A piña colada for example, is mostly about ingredients (are you using a good coconut cream? fresh pineapple?) For the martini the chilling and dilution need to be just right. This tests the bartender's most important skill: mixing. Proper mixing of the beverage is ultimately what makes a martini."
[..]
"martinis are shockingly easy to fuck up. and this conversation is exactly the reason why the martini is a good test of a bartender's capability. being a bartender is more than putting fixed quantities of ingredients in a glass. how do you know when your martini is properly diluted, either by shaking or stirring? a good bartender will know. a bad bartender will not. a terrible bartender won't even realize dilution is crucial."
I don't really drink much and never had a martini in my life, but I thought it was pretty interesting.
Earlier quoted context omitted.
The "point" of the whiteboard interview is to see how you think and converse and interact around your coding process, not (necessarily) how accurate/good you are at writing the code. You could write pseudocode that can't compile, and as long as you can explain the algorithm and talk about its complexity you could "pass" (in theory) Screening interviews do take place in a shared doc or other editor, I believe.
I'm sorry, I don't see how that relates to what I was asking. To be clear, I agree, I just don't understand why you chose to write this in reply to what I wrote.
Don't get me wrong I think it's silly, but
Earlier quoted context omitted.
Maybe for the devs, but "solves fun puzzles" is not a measure of quality either. The number of people who "aced the interview" but are borderline worthless for real product development is not trivial in my experience.
I still haven’t met the guy who is an algorithms genius who can’t program, but I can guarantee a license isn’t going to solve that problem.
It leaves out:
- communicating
- teaching
- dealing with ambiguity
- navigating politics
- working cross-functionally
Most high level individual contributors at large tech companies don't even code.
Earlier quoted context omitted.
You're missing out on lots of amazing people who treat programming as work and have other hobbies. Or people in temporarily different situations (like young kids). Or people with more important things happening in their life. You're effectively filtering for mostly people in their 20s. I mean, it's your choice, but your loss too.
Citation needed All the good programmers I know have side projects and live and breathe code. None of the mediocre/bad ones I know do. Think of it this way: what's likely to make you a better programmer: spending half (0.5x) of every day on (a work-mandated subset of) code or spending most (1x) of every day on code? The answer is obviously the latter. And it sounds weird, but most of my programming knowledge comes fr…
Earlier quoted context omitted.
I'm glad whiteboard interviews are dead now that everyone does "virtual" on-site interviews. When I interviewed at Google, I requested a laptop because writing on a whiteboard all day hurts my hand. Every interviewer complained about me using a laptop.
What, exactly, was the substance of their complaint(s), if any? Was it just that you made them do their job in a way different from how they are used to?
- "Oh, you're using a laptop"
- "Do you really need to use that?"
- "Just write it on the whiteboard"
- "It would be easier to see on the whiteboard"
What I hate most about whiteboards is how you can't easily insert lines so you have to leave lots of space. I tend to write code like an onion rather than top down.
Earlier quoted context omitted.
I'm sorry, I don't see how that relates to what I was asking. To be clear, I agree, I just don't understand why you chose to write this in reply to what I wrote.
The complaint of the interviewers would (likely) be that they want to see the candidate go through the whiteboard process, because of the reasons I gave. It's just part of the process. Writing in an editor takes away their ability to probe that process. Don't get me wrong I think it's silly, but
I've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a…
Earlier quoted context omitted.
So you don’t interview anyone whose work is company proprietary?
nope. tech is so fast moving if you're not at least experimenting with your own code then you're not going to be a good fit. we tend to also hire engineers who have contributed to open source.
I recently meet a programmer in his 50s, still working on Cobol. Sure, you aren't gonna hire him, but do you think he has any worries about his job?