Earlier quoted context omitted.
Wait, only two strong online services? I can think of like five other excellent services including a maps site that is years ahead of the competition.
It seems we have different definitions of "excellent". Google Maps is certainly widespread, but it's hardly the only on-line mapping service available. They keep messing around with the UI, often not for the better. I often find the data itself and the live route planning/traffic news to be inaccurate. Maybe it's better for those in the US, but here in the UK it's exactly what I meant by unremarkable. The local data…
Google: 90% of our engineers use the software you wrote (Homebrew), but...
651–660 of 683 posts
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#652Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#653Earlier quoted context omitted.
> where another might ding you for not instantly knowing the answer While there certainly are incompetent interviewers, I think ones that extreme are rare.
I've definitely seen interviewers (both by reading other people's feedback, and in one rare case, being an interviewee) who expected a "correct" answer and wouldn't work with the candidate to get there if they didn't already know it. See also: overused brainteasers. I remember being asked the 5 litre / 3 litre / get 4 litres problem for my Microsoft intern interview, and honestly told them that I already knew the ans…
Once I notice that it's not really going well, I try to politely as possible suggest that maybe we adjourn, so as to not waste each others' time. That hasn't really ever backfired, and actually turned one rejection into an offer, but I find it's polite to respect everyones' time.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#654Earlier quoted context omitted.
> it is your god damn job to find a way to make it work. No, it isn't. This is why probation periods exist. If you hired someone and they aren't working out, then at the end of the probation period you don't keep them on. Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org. It doesn't make you a "good" manager to say to everyone "I know this sucks but deal with it because lettin…
> Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org. Doesn't this rather presume that your "team dynamic" is actually good to start with? Let's say you had a team of not very good engineers. Then you hired quite a good engineer who looked at all the terrible practices (e.g. no version control, shitty or nonexistent testing, poor build processes) and said to themselves "look, I…
Yes, if you have a team like this and you hire someone who has a higher standard, there is going to be some friction between them and the existing team members. Letting that person go isn't your concern, because as you said yourself:
> and said to themselves "look, I need to fix this shit or I'm leaving, and I've got ten better offers in my inbox".
I've been in that situation before. I was hired to a company and when I got there I found out that every single day they were fighting fires because of stupid decisions management made with little foresight into how it would affect the team. Funny enough none of this was mentioned during the interview, although it was a definite red flag that they had high churn for this particular position.
I stayed there for my probation period trying to fix things so the team would fire fight every day and change management's mentality, but it wasn't happening, so I gave notice and went somewhere better.
> So, you know, the best thing to do is to get rid of them for not being a culture fit or for not being good for the team dynamic...?
No, you took me too literally. Obviously if you've got someone who has friction with the team, but they're a hard working individual who is trying to make your team better and more efficient, you should try to work through those stressful periods because in the long run it will be better for your team's health and the company's health. If some of your low performers leave during this period, that's okay, they were only going to hurt you in the long run. That being said, don't burn bridges with your existing employees. Try to find a happy middle ground that results in a better work environment for everyone.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#655Earlier quoted context omitted.
I use xcode and use wxWidgets, but I grab these manually and compile them myself. I also use the Android SDK and NDK, cppcheck cloc etc like you I didn't realise that they could be kept up to date with homebrew?? Is that the case? Last time I looked at MacPorts (and perhaps homebrew) I saw it as a porting of BDS/GNU tools to OSX and therefore making the OS more Linuxy to my mind. I wanted a clean break from Linuxland…
Homebrew is really the default package manager. You don't need it, per se, but for the vast majority of people it'd be like trying to set up a Linux system without using apt-get or yum: an exercise in pain.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#656Earlier quoted context omitted.
This has got to be the biggest hiring fallacy I've ever heard. "It's better to reject a good candidate than hire a bad candidate." That's completely false, and anyone who says that is completely ignorant of Bayesian logic. Here are some simple numbers. Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad" candidate has a 1% chance of tricking you into hiring them anyway. Every time you pass on a "g…
Those are simple numbers, but they don't get at the real issue. People say that because 1 bad hire can have negative effects on the whole team, causing others to get less done and leave. Missing a good hire doesn't poison your team.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#657At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#658Earlier quoted context omitted.
Running git blame is faster than waiting 30 minutes for the results of a whiteboard test.
Running, then cleaning and then having a dataset that still needs interpretation. I'd take the 30 minute interview route and risk not hiring a clever programmer.
If a guy has some kind of a git-mutating program that makes it seem like he writes good stuff, he's probably a good programmer to be able to write such a thing.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#659Earlier quoted context omitted.
Running, then cleaning and then having a dataset that still needs interpretation. I'd take the 30 minute interview route and risk not hiring a clever programmer.
Aren't we trying to hire clever programmers? Isn't that the point? If a guy has some kind of a git-mutating program that makes it seem like he writes good stuff, he's probably a good programmer to be able to write such a thing.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#660Earlier quoted context omitted.
Aren't we trying to hire clever programmers? Isn't that the point? If a guy has some kind of a git-mutating program that makes it seem like he writes good stuff, he's probably a good programmer to be able to write such a thing.
...or knows how to download such a thing and run it.
If they can't talk about what problems they solved, they probably didn't solve any.