> These are fair enough, although you did say above that the other coworkers in your old scrappy startups were much worse. Nope, I said the engineers I work wi

> These are fair enough, although you did say above that the other coworkers in your old scrappy startups were much worse. Nope, I said the engineers I work with now are consistently better. "My current team is very good" is MUCH different from "my last team was very bad." (And I'm not in a job interview.) > Some people will struggle to take credit because of politeness. Isn't taking credit trivial to do? No, it's not so much about credit, it's about specificity and the ability to talk about the different parts of the project. A lot of people get stuck on, "We made a project that sold widgets." I want something more along the lines of, "In our widget selling application, I worked on backend services for payment processing and fraud detection." Some people get really stuck on generalities and won't dive into specifics. It just makes it impossible to evaluate your contribution. Maybe you didn't do anything. I have no idea, you're just not generating useful information for me. > Most people don't get to decide the general point of what they do unless they are the CTO. I totally disagree. So many tiny choices that engineers make from day to day have a tangible impact on customers. Even if you're a junior engineer, you have an impact on the latency of service calls you're responsible for, as an example. Do you pick the lightweight framework that loads quickly, or do you need the features of the bigger one? It's that kind of tradeoff that people should consider, and "I saw something shiny" is not a good answer. > The problem is that you cannot possibly know how well would the ones you rejected would have done. Yep, for sure. I'm positive that I've rejected good candidates. That's the side you want to err on though, especially if you have lots of good candidates.