💾 Archived View for gmi.noulin.net › mobileNews › 3702.gmi captured on 2023-01-29 at 06:35:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
2012-01-06 19:39:37
That's a function of the size of the company and industry you are in. In
general, the technical ladder (or stool) becomes steep very quickly. And as you
climb it up, you start to see that you do more management than actual hands-on
thingie-building. But do not delude yourself into thinking that this type of
management is of a non-technical nature.
Software Architect. Enterprise Architect. Technical Lead. Principal Engineer.
Technical Director. Chief Scientist. Let's call these upper-stool technical
positions.
These types of positions require you to do less hands-on stuff, but the
management you will have to do must be technical-oriented. How you assign
technical tasks to people and teams will depend on whether tasks are technical
feasible, on identifying the technical capabilities of your team, on
understanding the resources required to complete technical tasks.
Granted that a lot of people who get into these positions let go of themselves,
gradually detaching themselves from the technical realities on the ground,
where the pedal hits the metal. And as a result, their decisions are no longer
technical, with technical consequences that is beyond their grasp. But those
are examples of doing a bad job in their positions. And that exists at all
levels, from the uber-chief of technical reality down to the lowest code
monkey.
These are the fabled paper tigers.
That is, being detached of technical realities is not an inevitability of
working so high up the ladder/stool. Good technical people remain strategically
and tactically technical always, regardless of their pecking order. A good
above-the-clouds architect can drop back to code with only a few days to clear
the mental cobwebs. A good technical foot soldier can extrapolate the reasons
behind good high-level technical decisions, even if he/she does not have the
management experience (which naturally they don't at their entry level of their
careers.)
My suggestion to people who find themselves staring at the technical stool: put
another stool over it, secure it with nails, crazy glue or some other good
shit, and then climb it. That is, like a good engineer, you need to engineer
and build your technical ladder.
This can only be done without realizing first that to climb it, you will have
to gradually move away from hands-on work without losing your technical wits.
You cannot allow yourself to become a paper-tiger.
This will also means that when you find yourself at a company where there is
nowhere else to go but down (because the stool cannot go any higher for
whatever reasons), then it is time to go somewhere else where there is a chance
to nail/glue another stool over the one you have built so far.
These are my personal interview red flags for a software developer job,
starting with the most likely to result in me throwing the interview/leaving
early/declining any offer:
Hiring is based on brain teasers, $-based certifications, or other similarly
irrelevant criteria.
Wants to know my current salary. (Bonus point: Doesn't give any indication at
the same time of the likely compensation if I'm offered the job. Extra bonus
point: Makes clear that the salary range given in the job ad was wildly
optimistic.)
Won't show me an example of their production code, real documentation, etc.
when given a reasonable opportunity to do so.
In each case, someone is skirting what matters, instead of finding out as fast
as possible whether we are really a good fit and a mutually satisfactory hire
might result.
current salary?
try this: companies are now asking (expecting!) your WHOLE CAREER SALARY TRACK!
I laugh and refuse. I don't even give current salary, I give a range of what I
expect for THIS job.
one guy even asked if the # I gave for my salary was verifyable. I asked him
'this is a trick question or test question isn't it? there's no legal way you
can 'verify' my salary, so who are you trying to kid, here??'
of course, some actually want COPIES of your pay stub to prove it.
I walk away from such places. those are big red flags that there will be mgmt
trouble later on, at that kind of place.
look, if you want to hire me, stop playing games. but if you want to start
things off poorly, start DEMANDING I tell you private things, like how much I
made last year. that's none of your fucking business, mr corporate asshole
hiring mgr. talk about rude questions - and the fact that so many people just
give in and answer them! astonishing.
then again, its a horrible time for job seekers right now. they have us by the
shorties, as there is NO bargaining and NO unions to help us keep the big co's
in check and in their place.
This is the best advice out there. If you enter any job interview from a
position of needing the job rather than wanting it, you risk not being happy in
your role. And don't be afraid to turn the question back around - if someone is
asking you where you see yourself in five years, why are they asking that? Is
it because they want someone who will grow with the company, do they have a
specific path mapped out that they'd want you to follow, are they hoping for
someone who will stick in the one position forever, etc - ask them, if you got
the job, where they'd see your role in five years, because it depends more on
them than you at the end of the day (it doesn't matter if you see yourself as
CEO if they only see you in a junior role).
Ask them to program something specific
I guess we combine the two approaches: we send our candidates small coding
problems to solve. So we see real code they create and have a standardized way
of comparing it to what other candidates have provided.
It works really well at filtering out people we don't want to waste time
talking to, and gives us a starting point for the technical interview. It isn't
useful for deciding whether or not a candidate should be hired, since there are
many other factors that come into play.
I ask candidates puzzles
But the idea isn't to get an answer - and I am very up front that I don't care
about the answer, and I already know it anyway. What I do want to see is how
someone approaches a problem that they don't know how to solve. I had one
candidate ask me the answer, I already know it after all - immediately top of
my hiring list, and she was an awesome hire. Another asked if they could use
google on their phone - again a pretty much perfect answer. The puzzle is
completely irrelevant, the ability to question, put forward ideas and not just
say 'I don't know' or, even worse, go completely silent and get embarrassed
that you don't know, is pretty fucking critical. IMHO.
I also look at samples of previous work, and we make all candidates carry out
real world tasks along side us.
> If the candidate is embarrassed, you should find the reason why, what
emotion is interfering?
http://developers.slashdot.org/story/12/01/06/1334246/
are-brain-teasers-good-hiring-criteria