61–70 of 145 posts
Warren Buffett practices, "praise by name, criticize by category." This is the opposite.
It's good advice, because criticizing people in public (i.e. in front of their peers) always backfires -- it just makes the criticized person defensive, so they stop being open to learning from their mistake.
You actually have to a analysis to determine this though, and not just load it off on someone.
The top answer has it exactly right. This should be Root Cause, since ultimately even bugs caused by human errors are really caused by systemic flaws. Some examples: * SQLite has 1177 times as many tests as code (not a typo) * Live television is broadcast with a 5-10 second delay * IMVU automatically reverts commits pushed to the site if regressions are detected * Netflix implemented a system called the Chaos Monkey,…
I'm usually arguing against stereotyping management around here, but I find it a stretch to believe a boss who thinks "Person to Blame" is going to be willing to pay the cost for true root cause analysis. I have a feeling it's more like: ; "Oh, it's Bob's fault."
Earlier quoted context omitted.
I'm usually arguing against stereotyping management around here, but I find it a stretch to believe a boss who thinks "Person to Blame" is going to be willing to pay the cost for true root cause analysis. I have a feeling it's more like: ; "Oh, it's Bob's fault."
We actually had a tradition at one of the places I worked at, where someone along the way brought in a trophy and the title was changed to something along the lines of best bug write. Anytime a bug broke the system the trophy was passed to the person that broke the system. It was actually light hearted and effective. We would make a big deal of passing the trophy, but no one wanted that trophy. It was not punitive, b…
One tradition I really appreciate at Google is the post-mortem. Any serious outage or bug will be followed by a detailed post-mortem detailing a timeline of what went wrong and why. Sometimes this will go as far as establishing a "war room", possibly for weeks, dragging in people from a number of different areas to address a particular issue. It's not about pointing the finger or otherwise apportioning blame. It's ab…
I was sitting down with a team getting started on Agile/Lean, and I was trying to lighten things up.
"Well, the first thing to do is pick somebody to blame when it all goes south," I paused for effect, "and that's usually me, the consultant."
It was dead silent. Everyone in the room was looking at me seriously.
Tough crowd.
Earlier quoted context omitted.
Do more! Practice makes better.
[deleted]
1. Get a github account, publish code, keep a social media profile etc. At the very least, this gets you interview calls.
2. People are not that creative with tech questions. Even Google (at least these days) asks you questions that come out of a textbook. So go through one, say like Skiena's Algorithm Design Manual and solve all the problems on a white board. This sucks a ton because when I sketch out code for a project, I never go do it on a whiteboard. The trick is to get to the stage where you can mentally compose the main blocks of the problem in your head and then writing down the answer on the whiteboard. This means that when you hit the whiteboard with the engineer staring at you from back, you know pretty much what way you want to go at the problem.
2.1. Statistically speaking of the countless interviews I have done, I think a large proportion of questions have been on trees, graphs and dynamic programming. I feel like this is because "some people" think that these are exotic enough that solving these problems have some correlation with smartness. Again, solve a few problems from any textbook on these or maybe go through the TopCoder tutorials on the matter and they start getting as easy as a day to day programming problem.
3. Accept the fact that people are paranoid about false positives and don't really care about false negatives. Sometimes if you have a bad day, it is not you.
4. Someone mentioned this before but interview more. Talk to people you like, you hate and people whom you have no intention of working with. This will help you get over your insecurities and make you realize that interviews are just a game: You will get more confident, and believe me, that helps. (This is just like dating, the more you do of it the more you get better ;-)
4.1 Organize your interviews so that your dream bets are towards the end of your process by which time you will have done so many problems, attended so many behavioral interviews, talked to so many people that you will be absolutely amazing!
Eventually though after he turned over project management of the software to the employees, they responded to the constant bug reports about the lack of this feature and added the ability to have this field. I recall he made a note about it on his blog, but that the project belonged to them and it wasn't his project to micromanage, so now they have the feature whether he likes it or not.
Caution: I probably have half the details wrong, I'll try to find some links.
People filled it mostly with our boss (we agreed with him, that when it's hard to say whose bug it's - we assign it to him), or old workers, that work here no longer, that first made commits to the feature where bug is. Or people solving the bug assigned it to themselves. Only sometimes somebody assigned a bug to another programmer who still works here.
Now the field is optional again.