Opposite view
“smart and gets things done”
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
When it’s time to interview, interviewers ask for results. That’s the entire “R” in answering interview questions in STAR format.
“smart and gets things done”
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
When it’s time to interview, interviewers ask for results. That’s the entire “R” in answering interview questions in STAR format.
Does anyone have techniques for that?
My job was not to go out and sale the product whether the product made $0 or $1 million dollars I had no control over.
The other thing I need to communicate is that I am capable of working at the level of scope, impact and ambiguity required for the job.
https://www.levels.fyi/blog/swe-level-framework.html
I didn’t understand that myself until a decade ago. Before the gatekeeping starts (not by you), yes it got me through a 5 round behavioral loop at BigTech (AWS’s consulting department) and after leaving, now a “staff software architect” at a third party consulting company (both full time direct hires).
The issue with this is that the bounds are drawn by someone else, the best you can do is 'meet them'. No one really cares if you save 90% of the budget, it was already allocated and will just get funnelled off somewhere else. It doesn't matter if it's early, because they probably didn't need it until they said they needed it, and 'meets requirements' is a given.
Compare this to a sales job or something more outward facing, a sales person might have targets but can blow them out of the water with some luck and skill (and get paid commission). They aren't operating within someone else's small framework, but a free variable against the open market.
Your leverage comes from working on larger more impactful projects that have more impact and scope.
As a mid level employee I was responsible for smaller projects, now I’m responsible for larger projects with multiple “work streams”, more people under me and closer to the “business” and sales”
But at the end of the day, did money get put in my account?
Course language:
This is why it's important not just to ask about previous results. This is also why you see so many "solve this random programming problem" type interviews - they hope (wrongly) that it's less fakeable and somehow gives you an idea of how they will do in the future.
I don't find those particularly useful (like many), i instead try to understand how they think and approach things.
If this is a manager, for example, give them real organizational problems you've seen, and ask them how they would approach them, and walk you through their thought process, etc. You will often start to get "weird" answers with fakers or spinners, especially if you start to ask about anything related to performance or improving it (again, in my experience, YMMV, etc). One idle theory (IE i don't claim this is correct in any meaningful way) i had about this was that a lot of the didn't actually know how to help people or organizations, so if you force them to try to explain how they approach it for real, they start to fall apart. Instead of thinking about that stuff, they were thinking about how to progress or spin things for themselves. Meanwhile, good managers often spend lots of time thinking about how to help their people and organizations, and whether they are good or bad or whatever, it's not a topic that tends to trip them up.
For IC's, for example, you can get them to teach you something real they learned on the project they claim was a great success, ideally a thing that helped make the project successful. In my experience, this also will lead you fairly quickly to discover if they believe they are smarter than everyone else. The best people i ever found (in retrospect) were usually the ones who would teach me things they learned, but usually not things they came up with. They would teach me something they learned from someone else during the project, but was still critical to the success of the project.
Everything in an interview is, of course, fakeable with enough preparation. The above things for sure - but it is harder for people to fake approaches, fake teaching, and spin results successfully all at the same time, etc.
You start to get into the "this person is in the 99% percentile of all fakers" kind of thing that is probably not worth trying to solve ;)
Whether they can code or not isn’t indicative of whether they can get things done. The last time I had an open req last year, the coding part was ChatGPT simple. It was for a green field initiative. I needed to be able to throw any random thing that came up - a complex deliverable - and know they could run with it - talk to the stakeholders, disambiguate the problem space, notice XYProblems, come back with a design and a proposal and learn what they needed to learn with a little direction. I needed a real “senior developer”. Not someone that “codez real gud”.
I actually turned down a “smart” candidate who was laid off from the AWS EC2 service team I think dealing with Elastic Block Storage (EC2 encompasses more than just VMs).
I knew he could code. But he didn’t show me any indication that he could deal with the ambiguity on the level I needed or the soft skills.
I'm thinking that as long as someone finishes projects you start, it's easy to take credit for all of it from start to finish, when interviewing elsewhere?
At your current job, your history of both successes and failures are well known, even if the failures happened early on and you learned from them. You never get a second chance to make a first impression
1. Smart and GTD is good enough hiring criteria
2. but for Unicorns™, you need to source and hire hyper-productive visionaries who nurture the right culture on top of having #1
And he says you get #2 by luck or polling friends for the alpha 10x developers they know.
Not very actionable, but hard to disagree that it seems to be a common denominator.