The reality for most engineers is that it depends on outside factors 99%. Engineers try to be rational. Here is what the real-world answers to your questions look like and I bet you never heard them.
Are you diligent and consistent with your work? IF it's being rewarded, yes. If I get yelled for missing the deadline, then no. Do I get credit for doing diligent work or the credit goes to somebody else who managed to get more visible things done less dilligently?
Are you the kind of person that bursts through work in a flash? That's a straight-out stupid question. There is work that should be done in a burst(like a fix) and there is async work that can be done in chunks or in the background(planning, monitoring or support). Nobody is exclusively committed to burst/no-burst, or at least it's very rare.
Do you prefer to work alone or in a team? Nonsense question. It's more of a question for you rather than the interviewee. Everybody wants to be on a good team and everybody hates to be on a bad team. Also is teamwork rewarded, how are politics resolved? How do you manage politics? Who gets credit/blame for the teamwork?
How do you feel working with people below your position or above it? Same as the previous question. How do you manage politics? How is credit/blame distributed? What power do I have to push changes up and down the chain? How would you handle an under-performing member up the ranks?
I dont see any correlation between "bullshitters" and providing information. I definitely dont see a correlation between "non-bullshiters" and utter lack of information. And also I don't know the correlation between "bullshiters" and actual technical knowledge.
The questions above were phrased quickly, and as i mentioned, its the questions you dont ask in an interview, but an information blank you have to fill out.
There are many ways you can answer and provide information about your work and professional that aren't empty phrases.
"I made this cool site with Rails, Angular, CSS transitions" -> purely technical
"I made this cool site with Rails, Angular, CSS transitions with consistent monthly releases, coordinated with open source contributors @ github. I also assisted community members in the technical setup of the project." -> technical + diligent + teamwork. And verifiably so.
Remember that we are talking about resume screening here, its a piece of paper that could be all lies , technical or non technical, its all about standing out and finding the right fit.
There you go, what did you learned about me?
If you base your hiring on what people wrote about their own personality, you will hire plenty of great salesmen. They will all be able to guess what the boss might like and generate nice sounding sentences to him.
They can still be poisonous jerks. And if they do, they will be perfectly able to hide the toxic culture they created from you.
Also, its delusional to believe a resume is not a selling tool. There are good and bad resumes and its pure salesmanship. Finally, you will have to prove that there is a correlation of any kind between salesmanship and technical ability.
A hire is a full package deal. If you interview a total wiz, but he comes to the interview naked, you will not hire him. Well, I doubt I would vote for a hire.
It's up to the interviewers to make that determination with the help of professional references.
What in the actual fuck. What do you expect to see? "I am clean and not a raging asshole"?
For all the fear of being "culturally unfit" for a company, highlighting what kind of role you play and how you interact with your coworkers is fundamental.
Are you diligent and consistent with your work? Are you the kind of person that bursts through work in a flash? Do you prefer to work alone or in a team? How do you feel working with people below your position or above it? etc.
These questions have the issue, however, that you rarely ask them in an interview. You just gauge them from a conversation, that really doesnt speak to any of them. If someone is a complete technical ace, but is silent 100% of the interview besides technical points, i still get red flags. A co-worker is not a cog in a machine, its someone you will be spending 40 + hours a week with.
I disagree with hard theory NOT being important. Im a drop-out but i still went through all the algorithms and data structures classes out there and they gave me knowledge to communicate about hard problems, even though Im not the one solving them (we got some phds for that). And above all, at least in our case currently, several of the algorithm questions we do are actual problems we had in our product. In particular i wouldnt even call O(n) "hard". Its maybe the single most important performance computer science knowledge you need, and its not hard to calculate for the vast majority of applications.