Category: career
-
This is a great read about a particular decision framework to think about switching jobs. -
I’m looking for a list of best practices, (maybe mechanics) with data to back up recommendations:
For example, starting with resume reviews all the way to closing the candidates. (some random thoughts )
1) In the resume tool: Do you create a set of standard templates to send? Do you try to respond by a certain number of days? Do you contact the candidate directly, or always let the recruiter do it?
2) In the resume review, what assumptions do you make? Do you assume that you have biases, the resume may not present the candidate perfectly? Whose time do you optimize for? Meaning, would you rather cast a wider net and have your screeners pick out the candidate from the phone screen?
3) Each part of our funnel (resume review, technical phone screen, recruiter phone screen) what are we optimizing for?
4) When we are hiring for a single position, do we keep the hiring panel the same so we can easily calibrate? Who are our best interviewers, and why are they good?
5) For the interview panel, which managers make you feel your time is well spent? And why? Is it because they set the expectations, they give you good questions to ask? Does the hiring manager have good follow up, clear decision-making process on whether they move forward with a candidate?
6) Finally, within our own company, who has gotten this hiring pipeline down to a science and doing it really well? (and how do we know when we are doing a good job for ourselves and for the candidate applying?)
7)
-
It is often not possible to get all three
1. job satisfaction and meaning
2. money
3. lifestyle
Most jobs can give you 2 out of 3. You may have to adopt a side hustle to fullfil the missing piece.
-
When I graduated from Berkeley with a computer science degree in 1992, I just wanted to write code. The professor at the time whom I admired the most was a super C hacker who loved to use C pre-processor to build super macros. I would sometimes pass by his desk and just listen to his keyboard flying, typing code non stop. He was my hero at the time. The ability to think about code and type without stopping, what a gift!
After 18 years in the computer industry, I’ve written a lot of code in C, Perl, PHP, C++, Assembly, Pascal, Fortran, Java. The languages themselves were picked to fit the particular job at the time and my job responsibility was pretty simple. Build software, write code.
Now my job at Yahoo! is a Senior Principle Architect and I am no longer judged on the code I write, but on other aspects that are not particularly easy to measure immediately, but usually surface 1-2 years after a system is built. This year, I’ve lead a team to design and rebuild Yahoo! Media’s content system. While the system has launched, I am curious whether the system itself meets all of the criteria below. I have also been reflective on how well I’ve carried out my job description. Of course, one other factor why I’m reflective: I am also writing my own self assessments and 18 other peer reviews this year.
Officially, my job summary is as follows.
- Responsible for the technical designs of products and infrastructure
- Balances the need for deliverables to meet customer requirements, to be built on time with the available resources and to comply with principles such as modularity, scalability, testability, availability, operability, security and global deployability.
- Communicates about designs through the use of tools such as logical system diagrams, sequence diagrams, entity relationship diagrams, standards documents and formal interface specifications
- Organizes, drives clarity and reduces the complexity involved in the implementation work of engineers and other architects
- Works across organizations: responsibilities typically extend beyond hard-line reporting relationships
- Advances the state of the art of technology and does enough implementation to keep current with technology trends inside and outside the company
- May be responsible for technology strategy, including vision, mapping customer needs to technical solutions, competitive analysis, third party technology evaluation, organizational alignment and evangelization
-
The photo is of my holding my Treo phone, my daughter Cate was taking a photo of me taking a photo of her.
My dad was the person who pushed me into software engineering in college (I was drifting a bit with no goals)
But after working for 5 years in SGI, my dad saw how crazy my hours were and commented to me to start preparing myself to exit the industry and find another line of work because I couldn’t sustain the long hours.
He thinks that the new grads from college will just take over my job because they can work faster and longer than I could at 30 years old.
Then came the reports of the jobs moving overseas to India, he again told me to prepare myself to be replaced.
Now I’m 34 years old, he tells me I’m over the hill and how I can possibly compete with the young kids coming out of college?
I could see his point, does experience really matter in software engineering? Since we are supposely working in the bleeding edge of technology, does what I learned 10 years ago really matter now?
Yes and no is my answer
- experience matters because you know what worked and what doesn’t work and you can make a decision quickly
- software engineering is still stuck in the dark ages, every project pretty much starts from the ground up usually. in C I still have to start with main(). I still use my editor to start writing code
- you would think that software engineers like to change, but NO! How many engineers are still using variants of VI, Emacs, using GNU? my guess is 90% of yahoo engineers. I don’t know why, but we are very set in our ways, especially when we get old. I guess we are all human :-)
- I am an optimist and I do hope that new grads can come in a bring all the new cool stuff they learn from school and jump in and be able to replace me. But given the large number of resumes we go thru trying to hire someone, that is not happening any time soon
- coding fast doesn’t make you a good engineer, usually coders are not the most important members of the team. Planning, architecting, explaining your ideas is more valuable skills. coding can always be farmed out once the design is finalized
- writing software has not changed since I was college (1992) 13 years since I graduated. The programming languages have changed but they have gotten simpler not harder. Today software systems are more connected, bigger, more complex, but the language is simpler. Think assembly, pascal, c++, c compare with PHP, Perl, Java. If you ever programed for the Atari 800XL (PEEK and POKE)
- It seems like everything I learned in the last 13 years has only made me better, every year I grow as a software engineer. I guess experience does matter. One day when I’m not longer growing, then a young stud will come along and tell me to get lost. Then I’ll head over to live in France. Can’t wait!
Tony Tam 