Humility At Work

Leave a comment

This article was emailed out across the office on Friday. I thought it was a pretty good read and it spoke to me in many ways. If I had to summarize the article in one word, it would be humility. I recommend this article to anyone who’s in the working world, not just software engineers. Original post is HERE

 

On Being A Senior Engineer

by allspaw on October 25, 2012

I think that there’s a lot of institutional knowledge in our field, especially about what makes for a productive engineer. But while there are a good deal of books in the management field about “expert” roles and responsibilities of non-technical individual contributors, I don’t see too many modern books or posts that might shed light directly on what makes for a good senior engineer. One notable exception is of course Kate Matsudaira, who has been posting quite a good deal recently about the cultural sides of engineering.

Yet at the same time, a good lot of successful engineers whom I have known all remember the mentor who taught them what it meant to be “senior”.

I do, however, agree 100% with my friend Theo’s words about being “senior” in his chapter of the Web Operations book by O’Reilly:

“Generation X (and even more so generation Y) are cultures of immediate gratification. I’ve worked with a staggering number of engineers that expect the “career path” to take them to the highest ranks of the engineering group inside 5 years just because they are smart. This is simply impossible in the staggering numbers I’ve witnessed. Not everyone can be senior. If, after five years, you are senior, are you at the peak of your game? After five more years will you not have accrued more invaluable experience? What then? “Super engineer”? Five more years? “Super-duper engineer.” I blame the youth of our discipline for this affliction. The truth is that there are very few engineers that have been in the field of web operations for fifteen years. Given the dynamics of our industry many elected to move on to managerial positions or risk an entrepreneurial run at things.”

He’s right: this field of web operations is still quite young. So we can’t be surprised when people who have a title of ‘senior’ exhibit unsurprisingly immature behavior, both technical and non-technical. If you haven’t read Theo’s chapter, I suggest you do.

Having said that, what does it actually mean to be ‘senior’ in this discipline? I certainly have an opinion of what it means, given that I’m charged with hiring, supporting, and retaining engineers whom are deemed to be senior. This notion that there is a bar to be passed in terms of career development is a good one, but I’d also add that these criteria exist on a spectrum, as opposed to a simple list of check-boxes. You don’t wake up one day and you are “senior” just because your title reflects that upon a promotion. Senior engineers don’t know everything. They’re not perfect in their technical knowledge, and they’re OK with that.

In order not to confuse titles with expectations that are fuzzy, sometimes I’ll refer to engineering maturity.

Meaning: I expect a “senior” engineer to be a mature engineer.

I’m going to gloss over the part where one could simply list the technical areas in which a mature engineer should have some level of mastery or understanding (such as “Networking”, “Filesystems”, “Algorithms”, etc.) and instead highlight the personal characteristics that in my mind give me indication that someone can influence an organization or a business positively in the domain of engineering.

Over on Quora, someone once asked me “What are the attributes (other than technical ability/experience) that makes a great VP of Technical Operations?”. The list of attributes that I mentioned in the answer came with the understanding that they are perpetual aspirations of my own. This post is similar to that answer.

I might first argue that senior engineers in web development and operations have the same characteristics as senior engineers in other fields of engineering (mechanical, electrical, chemical, etc.) in which case The Unwritten Laws of Engineering are applicable. Again, if you haven’t read this, please go do so. It was originally written in 1944, published by the American Society of Mechanical Engineers. A good excerpt from the book is here.

While the book’s structure and prose still has a dated feel (“…refrain from using profanity in the workplace…” or “…men should pay particular attention to shaving habits and the trimming of beards and mustaches…”), it gives a good outline of the non-technical expectations, responsibilities, and inner workings of an engineering organization with respect to how both managers and mature engineers might behave.

Obligatory Pithy Characteristics of Mature Engineers

All posts that attempt to give insight to aspirational characteristics must have an over-abundance of bullet points, and the field of engineering has a fair share of them. Therefore, I’m going to give you some, some mine and some pulled from various sources, many from the Unwritten Laws mentioned above.

Mature engineers seek out constructive criticism of their designs.

Every successful engineer I’ve met, upon finishing up a design or getting ready for a project, will continually ask their peers questions along the lines of:

  • “What could I be missing?”
  • “How will this not work?”
  • “Will you please shoot as many holes as possible into my thinking on this?”
  • “Even if it’s technically sound, is it understandable enough for the rest of the organization to operate, troubleshoot, and extend it?”

This is because they know that nothing they make will ever only be in their hands, and that good peer review is what makes better design decisions. As it’s been said elsewhere, they “beg for the bad news.”

Mature engineers understand the non-technical areas of how they are perceived.

Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you. Mature engineers know that no matter how complete, elegant, or superior their designs are, it won’t matter if no one wants to work alongside them because they are assholes. Condescension, belittling, narcissism, and ego-boosting behavior send the message to other engineers (maybe tacitly) to stay away. Part of being happy in engineering comes from enjoying the company of the people you work with while designing and building things. An engineer who is quick to call someone a moron is someone destined to stunt his or her career.

This also means that mature engineers have self-awareness when it comes to their communication. This isn’t to say that every mature engineer communicates perfectly, only that they have some notion about where they could be better, and continually ask for a gut-check from peers and managers on how they’re doing. They aim to be assertive, not passive or aggressive in how they get their ideas across.

I’ve mentioned it elsewhere, but I must emphasize the point more: the degree to which other people want to work with you is a direct indication on how successful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with.

Now this isn’t to say that you should shy away from giving (or getting) constructive criticism on the work produced by engineering (as opposed to the engineer personally), for fear of pissing someone off. There’s a difference between calling someone a moron and pointing out faults in their code or product. In a conversation with Theo, he pointed out another possible area where our field may grow up:

“We as an industry need to (of course) refrain from critiques of human character and condition, but not shy away from critiques of work product. We need to get tougher skin and be able to receive critique through a lens that attempts to eliminate personal focus.

There will be assholes, they should be shunned. But the attitude that someone’s code is their baby should come to an end. Code doesn’t have feelings, doesn’t develop complexes and certainly doesn’t exhibit the most important trait (the ability to reproduce) of that which carries for your genetic strains.”

See also below #2 and #10 in The Ten Commandments of Egoless Programming.

I think this has a corollary from the Unwritten Laws (emphasis mine):

Be careful about whom you mark for copies of letters, memos, etc., when the interests of other departments are involved.

A lot of mischief has been caused by young people broadcasting memorandum containing damaging or embarrassing statements. Of course it is sometimes difficult for a novice to recognize the “dynamite” in such a document but, in general, it is apt to cause trouble if it steps too heavily upon someone’s toes or reveals a serious shortcoming on anybody’s part. If it has wide distribution or if it concerns manufacturing or customer difficulties, you’d better get the boss to approve it before it goes out unless you’re very sure of your ground.

This of course underscores the dated feel of the book, but in the modern era, I still believe the main point to be true. Nothing indicates that you have a lack of perspective and awareness like a poorly thought out and nonconstructive tweet that slings venomous insults. It’s a junior engineer mistake to toss insults about a piece of complex technology in 140 characters.

I certainly (much like Christopher Brown mentioned in his keynote at Velocity London) pay attention to those sorts of public remarks when I come across them so that I can note who I would reconsider hiring if they ever applied to work at Etsy.

Mature engineers do not shy away from making estimates, and are always trying to get better at it.

From the Unwritten Laws:

Promises, schedules, and estimates are necessary and important instruments in a well-ordered business. Many engineers fail to realize this, or habitually try to dodge the irksome responsibility for making commitments. You must make promises based upon your own estimates for the part of the job for which you are responsible, together with estimates obtained from contributing departments for their parts. No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.”

Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.” All businesses rely on estimates, and all engineers working on a project are involved in Joint Activity, which means that they have a responsibility to others to make themselves interpredictable. In general, mature engineers are comfortable with working within some nonzero amount of uncertainty and risk.

Mature engineers have an innate sense of anticipation, even if they don’t know they do.

This code looks good, I’m proud of myself. I’ve asked other people to review it, and I’ve taken their feedback. Now: how long will it last before it’s rewritten? Once it’s in production, how will its execution affect resource usage? How much so I expect CPU/memory/disk/network to increase or decrease? Will others be able to understand this code? Am I making it as easy as I can for others to extend or introspect this work?

Mature engineers understand that not all of their projects are filled with rockstar-on-stage work.

However menial and trivial your early assignments may appear, give them your best effort.

Getting things done means doing things you might not be interested in. No matter how sexy a project is, there are always boring tasks. Tedious tasks. Tasks that a less mature engineer may deem beneath their dignity or their job title. My good friend Kellan Elliot-McCrea (Etsy’s CTO) had this to say about it:

“Sometimes the saving grace of a tedious task is their simplicity and maturity manifests in finishing them quickly and moving on. Sometimes tasks are tedious because they require extreme discipline and malleable attention span. It’s an odd phenomena that the most tedious tasks, only to be carried out by the most senior engineers, can also be the most terrifying.”

Mature engineers lift the skills and expertise of those around them.

They recognize that at some point, their individual contribution and potential cannot be exercised singularly. They recognize that there is only so much that can be produced by a single person, and the world’s best engineering feats are executed by teams, not singularly brilliant and lone engineers. Tom Limoncelli makes this point quite well in his post.

At Etsy we call this a “generosity of spirit.” Generosity of spirit is one of our core engineering values, but also a primary responsibility of our Staff Engineer position, a career-level position. These engineers spend the time to make sure that more junior or new engineers unfamiliar with the tech or processes we have not only understand what they are doing, but also why they are doing it. “Teaching to fish” is a mandatory skill at this level, and that requires having both patience and a perspective of investment in the rest of the organization.

Therefore instead of: “OK, move over, lemme just do it for you”, it’s instead: “Ok, let’s work on this together. I can show you how I’m writing/troubleshooting/etc. Then, you do it so I can be sure you know why/how we’re doing it this way, etc.”

Related: see below about getting credit.

Mature engineers make their trade-offs explicit when making judgements and decisions.

They realize all engineering decisions, implementations, and designs exist within a spectrum; we do not live in a binary world. They can quickly point out contexts where one successful approach or solution could work and where it could not. They know that one cannot be both efficient and thorough at the same time (The ETTO Principle), that most projects engineers work on exist on an axis of optimality and brittleness, and that whether the problems they are solving are acute or chronic.

They know that they work within a spectrum of ideal and non-ideal, and are OK with that. They are comfortable with it because they strive to make the ideal and non-ideal in a design explicit. Later on in the lifecycle of a design, when the original design is not scaling anymore or needs to be replaced or rewritten, they can look back not with a perspective of how short-sighted those earlier decisions were, but instead say “yep, we made it this far with it and knew we’d have to extend or change it at some point. Looks like that time is now, let’s get to work!” instead of responding with a cranky-pants, passive-aggressive Hindsight Bias-filled remark with counterfactuals (e.g.. “those idiots didn’t do it right the first time!”, “they cut corners!”, “I TOLD them this wouldn’t work!”)

Many pithy quotes exist that shine light on this notion of trade-offs, and mature engineers know that there are limits to any philosophy-laden quotes (including the ones I’m writing here):

  • “Premature optimization is the root of all evil.” – a very abused maxim, and I’ve written about it before. A corollary to that might be (taken from here) ‘Understanding what is and isn’t “premature” is what separates senior engineers from junior engineers.’
  • “Right tool for the job” – another abused one. The intention here is reasonable: who wants to use a tool that isn’t appropriate? But a rare perspective is that this can be detrimental when taken to the extreme. A carpenter doesn’t arm himself with every variation and size of hammer that is available, even thought he may encounter hammering tasks that could be ideally handled by each one. Why? Because lugging around (and maintaining) a gazillion hammers incurs a cost. As such, decisions on this axis have trade-offs.

The tl;dr on trade-offs is that everyone cuts corners, in every project. Immature engineers discover them in hindsight, disgusted. Mature engineers spell them out at the onset of a project, accept them and recognize them as part of good engineering.

(Related: Your Code May Be Elegant, But Mine Fucking Works)

Mature engineers don’t practice CYAE (“Cover Your Ass Engineering”)

The scenario where someone will stand on ceremony as an excuse for not attempting to understand how his or her code (or infrastructure) could be touched by other parts of the system or business is a losing proposition. Covering your ass sends the implicit message that you are someone willing to throw others (on your team? in your company? in your community?) under the proverbial bus at the mere hint that your work had any flaw. Mature engineers stand up and accept the responsibility given to them. If they find they don’t have the requisite authority to be held accountable for their work, they seek out ways to rectify that.

An example of CYAE is “It’s not my fault. They broke it, they used it wrong. I built it to spec, I can’t be held responsible for their mistakes or improper specification.”

Mature engineers are empathetic.

In complex projects, there are usually a number of stakeholders. In any project, the designers, product managers, operations engineers, developers, and business development folks all have goals and perspectives, and mature engineers realize that those goals and views may be different. They understand this so that they can navigate effectively in the work that they do. Being empathetic in this sense means having the ability to view the project from another person’s perspective and to take that into consideration into your own work.

Goal conflicts are inherent in all engineering work, and complaining about them (instead of embracing them as requirements for success) is a sign of a less mature engineer.

They don’t make empty complaints.

Instead, they express judgements based on empirical evidence and bring with those judgements options for solving the problem which they’ve identified. A great manager of mine said to never go to your boss with a complaint about anything without at least one (ideally more than one) suggestion for a solution. Even demonstrating that you’ve tried working the problem on your own and came up empty-handed is better than an empty complaint.

Mature engineers are aware of cognitive biases

This isn’t to say that every mature engineer needs to have a degree in psychology, but cognitive biases are what can limit the growth of an engineer’s career at a certain point. Even if they’re not aware of the details of how they appear or how these biases can be guarded against, most mature engineers I know have a level of self-awareness to at least recognize they (like everyone) are susceptible to them.

Culturally, engineers work day-to-day in empirical evidence in research. Basically: show me the data. The issue with cognitive biases is that we can be blissfully unaware of when we are interpreting data with our own brains in ways that defy empirical data, and can have a surprising effect on how we get work done and work on teams.

A great list of them exists on Wikipedia, but some of the ones that I’ve seen engineers (including myself) fall prey to are:

  • Self-Serving Bias – basically: if something is good, it’s probably because of something I did or thought of. If it’s bad, it’s probably the doing of someone else.
  • Fundamental Attribution Error – basically: the bad results that someone else got from his work must have something to do with how he is, personally (stupid, clumsy, sloppy, etc.) whereas if I get bad results, it’s because of the context that I was in, the pressure I was under, the situation I was in, etc.
  • Hindsight Bias – (it is said that this is the most-studied phenomenon in the history of modern psychology) basically: after an untoward or negative event (a severe bug, an outage, etc.) “I knew it all along!”. It is the very strong tendency to view the past more simply than it was in reality. You can tell there is Hindsight Bias going on when descriptions involve counterfactuals, or “…they should have…”, or “…how did they not see that, it’s so obvious!”.
  • Outcome Bias – like above, this comes up after a surprising or negative event. If the event was very damaging, expensive to clean up, or severe, then the decisions or actions that contributed to that event are judged to be very stupid, reckless, or negligent. The judgement is proportional to how severe the event was.
  • Planning Fallacy – (related to the point about making estimates under uncertainty, above) basically: being more optimistic about forecasting the time a particular project will take.

There are plenty of others, all of which I find personally fascinating and I can get lost in learning more about them. Highly suggested reading, if you’re at all interested in learning about how you might be limiting your own effectiveness.

The Ten Commandments of Egoless Programming

Appropriate, even if old…I’ve seen it referenced as coming from The Psychology of Computer Programming, written in 1971, but I don’t actually see it in the text. Regardless, here are The Ten Commandments of Egoless Programming, found on @wyattdanger‘s blog post on receiving advice from his dad:

  1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
  2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. (Allspaw note – related: see below, number #10, and the points Theo made above.)
  3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
  4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
  5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
  6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
  7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.
  9. Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.
  10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

Novices versus Experts

Now I generally don’t follow too much on knowledge acquisition as a research topic, but I do believe it’s hard to get away from when talking about the evolving nature of a discipline. One bit of interesting breakdown comes from a paper from Dreyfus and Dreyfus called “A Five Stage Model of the Mental Activities Involved in Directed Skill Acquisition” which has laid out characteristics of various levels of expertise:

Novice
  • Rigid adherence to rules or plans
  • Little situational perception
  • No (or limited) discretionary judgment
Advanced Beginner
  • Guidelines for action based on attributes and aspects, which are all equal and separate
  • Limited situational perception
Competent
  • Conscious deliberate planning
  • Standardized and routine procedures
Proficient
  • Sees situations holistically rather than as aspects
  • Perceives deviations from normal patterns
  • Uses maxims for guidance, whose meanings are contextual
Expert
  • No longer relies on rules, guidelines or maxims
  • Intuitive grasp of situations
  • Analytic approach used only in novel situations

The paper goes on to state:

Novices operate from an explicit rules and knowledge-based perspective. They are deliberate and analytical, and therefore slower to take action, they decide or choose.

(which means that novices are deeply subject to local rationality)

Experts operate from a mature, holistic well-tried understanding, intuitively and without conscious deliberation. This is a function of experience. They do not see problems as one thing and solutions as another, they act.

(which means that experts are context driven)

I don’t necessarily subscribe to the notion of such dry lines being drawn between skill levels, because I think that there is a lot more granularity and facets of expertise than just those outlined above, but I think it’s helpful to be aware of the unfortunately over-simplified categories.

Dirty secret: mature engineers know the importance of (sometimes irrational) feelings people have. (gasp!)

How people feel about technologies, technical decisions, and technical directions is just as important (if not more) than the facts about the details. Mature engineers know this, and adjust accordingly. Again, being empathetic can help you understand how another person on your team feels about a technical decision, even if they themselves don’t have an easy time articulating why they feel that way.

People’s confidence in software, architectures, or patterns is heavily influenced by past experience, and can result in positive or negative reactions to using them. Used to work at a mod_perl shop that had a lot of mystifying outages? Then you can’t be surprised to feel reluctant to use it in a different company, even if the supporting expertise and use cases are entirely different. All you remember is that mod_perl = major headaches, so you’re going to be wary of using it in any context again.

Mature engineers understand this phenomenon when making a case to use technology that carries baggage, even if it’s irrational. Convincing a group to use tools and patterns that they aren’t comfortable with isn’t a straightforward task. The “right tool for the job” maxim also has (sometimes unquantifiable) comfortability as a parameter.

For an illustration of how people’s emotions drive technical decisions and opinions, read any flame war about anything, ever.

“It is amazing what you can accomplish if you do not care who gets credit.”

This quote is commonly attributed to Harry S. Truman, but it looks like it might have first been said by a Jesuit priest in a different form. In any case, this is another indication you’re working with a mature engineer: they hold the success of the project much higher than the potential praise they may get personally for working on it. The attribution of praise or credit can be the source of such dysfunction in an engineering-driven organization, and I believe it’s because it’s largely invisible.

The notion is liberating, and once understood and internalized, a world of progress and innovative thinking can flourish, because the engineer isn’t overly concerned with the personal liability of equating the work to their own career success.

Not The End

I’m at the moment blessed to work with a number of mature engineers here at Etsy, and it’s quite humbling. We are indeed a young field, and while I think we can learn a great deal from other fields of engineering on this topic, I also think we have an advantage. The web is inextricably tied to the notion of publishing and sharing information, globally. We need to continue pointing out what it means to be a “senior” and “mature” engineer if we have a hope of progressing the field into a true discipline.

Many thanks to members of the Etsy Operations team, Mike Brittain, Kellan Elliott-McCrea, Marc Hedlund, and Theo Schlossnagle for reviewing drafts of this post. They all make me a more mature engineer.

Still an ISTJ

Leave a comment

Haven’t taken this test since high school. Got ISTJ then and am still ISTJ now.
Results from humanmetrics:
ISTJ
Introvert(33%)  Sensing(25%)  Thinking(50%)  Judging(33%)
  • You have moderate preference of Introversion over Extraversion (33%)
  • You have moderate preference of Sensing over Intuition (25%)
  • You have moderate preference of Thinking over Feeling (50%)
  • You have moderate preference of Judging over Perceiving (33%)

ISTJs are often called inspectors. They have a keen sense of right and wrong, especially in their area of interest and/or responsibility. They are noted for devotion to duty. Punctuality is a watchword of the ISTJ. The secretary, clerk, or business(wo)man by whom others set their clocks is likely to be an ISTJ.

As do other Introverted Thinkers, ISTJs often give the initial impression of being aloof and perhaps somewhat cold. Effusive expression of emotional warmth is not something that ISTJs do without considerable energy loss.

ISTJs are most at home with “just the facts, Ma’am.” They seem to perform at highest efficiency when employing a step-by-step approach. Once a new procedure has proven itself (i.e., has been shown “to work,”) the ISTJ can be depended upon to carry it through, even at the expense of their own health.

ISTJs are easily frustrated by the inconsistencies of others, especially when the second parties don’t keep their commitments. But they usually keep their feelings to themselves unless they are asked. And when asked, they don’t mince words. Truth wins out over tact. The grim determination of the ISTJ vindicates itself in officiation of sports events, judiciary functions, or an other situation which requires making tough calls and sticking to them.

His SJ orientation draws the ISTJ into the service of established institutions. Home, social clubs, government, schools, the military, churches — these are the bastions of the SJ. “We’ve always done it this way” is often reason enough for many ISTJs. Threats to time-honored traditions or established organizations (e.g., a “run” on the bank) are the undoing of SJs, and are to be fought at all costs.

2012 First Half Recap: Part III

Leave a comment

Graduation

The engineering commencement was bright and early at 9AM in the morning at Drake Stadium. Had to show up at 8:15 to  get a name card so there was a lot of loitering. Thankfully I was able to spot a few EE buddies and talk/take pictures with them.

As for the ceremony – it was painful at times, especially when the sun started to come out about an hour in. And after the first hundred or so PhD and master students walked, it started to get really boring. It was a test of patience. There were a couple speeches thrown in; one by a graduating senior and one by a guest speaker. The senior’s speech was so cheesy and it seemed like she was reciting her speech from memory. I enjoyed the guest speaker’s talk a lot more mainly because she spoke from the heart.

About three hours into the service it was finally time for the undergrads to walk. As I went up it felt like my cap was about to fly off but thankfully it didn’t. I was trying to fix it while I was standing in line to walk. It felt great walking on stage and getting my “diploma”. It was hard to believe that this is it – I am done with college and probably done with school forever. At the time it didn’t hit me. I still don’t think that it has totally sunk in.

Thankful for the people that came to celebrate with me at the reception. My mom brought her camera and took lots of pictures. I’m glad I was able to see some of the old ICA people and that some of the USC brothers and sisters were able to make it out.

Then some of us went to a graduation lunch at Chipotle! The rest of the day was spent hanging out and going to a couple other graduation ceremonies. Was able to catch Joe at the end of the neuroscience commencement and visited Mark at the end of his ceremony. Then everyone who was still around went to dinner at the Cheesecake Factory. I forgot how expensive that place is.

 

2012 First Half Recap: Part II

Leave a comment

Meant to get this done earlier but have been pretty busy with work and what not but I’ll blog about that later. Continuing on…

Intel

So about 30 minutes before I got the rejection letter from Qualcomm at sushi night, I got an email from Intel in Irvine about setting up a phone interview. I had seen their opening for a pre-silicon validation engineer on BruinView a few days ago and applied.

The phone interview went pretty well. The interviewer asked a couple of technical questions but most of the questions were about school projects, my passions, and interests. At the end of the interview, the interviewer invited me for an onsite interview that Friday.

It took me a while to find the Intel building since all the buildings at the UCI University Research Park are identical. Thankfully I was able to find the building with enough time to down a couple Jack and the Box breakfast sandwiches. The onsite interview was similar to the one I had at Qualcomm. I interviewed with four engineers but each interview at a different focus.

The first interview was focused on digital design. The interviewer asked me to use a D flip-flop to divide the clock by 2. I was struggling throughout the whole problem and had to get a couple of hints from the interviewer before I got an answer. It was a pretty easy question in my opinion so I felt pretty dumb.

The questions in the second interview were more on hardware – transmission lines, CMOS, noise, power. The interviewer was really intimidating and I hadn’t taken a EE class since junior year so this interview was the hardest by far. I just answered all the questions I could but had no clue about a few of them.

Then I met with another engineer who asked me a bunch of programming questions. He asked me a few problems and told me that I could answer the problem in any language I wanted. I chose C. I was able to answer all the questions but needed a little help on the last one. The interviewer said the last problem is the hardest and that almost everyone needs a few hints to solve it.

The last interview was the most chill. The interview was focused on teamwork so I was asked a lot of “how would you respond if…” questions. I answered with a few references to the logic design lab and V-SET. Yay for no technical questions! Afterwards the manager came to chat for ten minutes or so. He let me know that I will likely hear a response in 2-3 weeks since a few people are flying out from New York to interview next week.

While I was waiting for Mike to pick me up after the interview, I sat at a table outside at Starbucks and started writing out all the questions I couldn’t answer. I wanted to remember the questions so I could look up the answers over the weekend and not make the same mistakes again. I had plenty of time too because apparently Mike got into a little accident on the way over. He later told me that he was praying that God would humble him.

When we got back to Mike’s place, we had about an hour to kill before praise night. I played Monopoly Deal with Jimmy while Mike was looking through insurance stuff. At praise night when people asked me how the interview went, I told them it was like a hard exam. “Hopefully the curve saves me”.

During the weekend I wrote a thank you note to the manager and asked him to forward it to the engineers I interviewed with. The next Monday the manager wrote me an email thanking me for the note and offering me a position. I was in shock for a good 30 minutes. It all happened so fast. Literally a week before I was back at square one after being turned down from Qualcomm. Now I had a full time job offer from Intel, a company electrical/computer engineers would kill for. Crazy! I was wondering if they made a mistake and had me confused for someone else.

They gave me until that Friday to make a decision about the offer. I spent a lot of extra time in the Word and prayer that week asking Him if this is where He wants me to go. Taking this job would keep me from serving in Bruin ICA next year and from serving the guys in the bible study. When I talked with people from ICA about my decision, I got the feeling that they wanted me to stay.

After much thought, prayer, and talks with people I decided to take the offer. After the decision was made, I felt that other people were ‘disappointed’ in my decision. People started treating me differently for a while. But I stand beside my decision. I know what I’m getting myself into and I know what I have to give up, but I’m confident this is where God wants me to be.

Mom

So I was informed a few days before I went off to V-SET (Summer 2011) that my mom had a few tumors on her head and that one of them was cancerous. The parents said they wanted to wait to tell us during summer break so that we wouldn’t worry while we finish our projects and cram for finals.

While I was on V-SET my mom was visiting doctors in LA and having a couple of operations to remove the malignant tumors on her cheek. I would pray for her whenever God brought her to mind.

During the 2012 winter quarter, my mom flew out to Boston to spend a couple of months getting radiation treatment. Apparently this hospital in Boston specializes in this rare form of cancer. My dad even flew out and stayed with her for a week. Mom and dad would send out email updates every once in a while to family/friends/church. I think I even posted one of them on this blog.

Now my mom is back in California, done with all the radiation treatments. She still has to go get checked up every once in a while to make sure the tumor doesn’t come back. But for now, she seems to have made a full recovery and has regained all her strength. Mom and dad both seemed very calm throughout the whole process. It was very evident that my mom knew that this whole situation was part of God’s plan and that He was in control. I never saw her freak out or break down and cry. She was just calm like she always is.  She was always giving glory to God through this whole mess. Props.

2012 First Half Recap: Part I

Leave a comment

I know that it has been over half a year since I last posted on this thing. I don’t know what happened but I just never got around to blogging. Hopefully I will post on this blog a little more regularly but for now, I just wanted to give a quick update on what has been going on the past six months.

Laserfiche

I first talked to Laserfiche at the fall career fair at UCLA and was one of the companies that seemed pretty interested in me. They asked me some conceptual CS questions at the fair and then sent me a couple of coding problems that I had to solve within a week. Then I got a phone interview but it was mostly behavioral. I remember bringing up V-SET for a lot of my answers.

A few days later I got invited to an onsite interview for a software engineering position– my first one ever! It was scheduled near the beginning of my winter break. It was raining pretty hard that day but I got to the building safely. I first met with two HR people who showed me a fifteen minute video of the company and what they do. Then I met with two engineers who asked me a few technical questions. First, they asked me to write a program that would take a number (n) as input and output all the prime numbers from zero to n. They actually handed me a keyboard and wanted me to code it on a computer. I expected to just write my code on a whiteboard, which is the norm at every other company. Basically, I froze and messed up. It took me a while to come up with a solution and even that wasn’t a fully functional one. They then asked me a brainteaser type puzzle that I actually saw before online. I gave the answer pretty quickly but they then changed the problem a little and made it more complicated. I couldn’t solve the new problem in time.

Walking out of the office, I was kind of disappointed in how I interviewed but viewed it as a learning opportunity. It was my first on-site interview after all. Three weeks later, I got an email letting me know that I wasn’t chosen for the job.

ICA Tahoe Trip

A couple days after the Laserfiche interview, I was off to the annual ICA Tahoe trip. It was a very much needed time of fun and fellowship after the very stressful finals week and interview prep. This year we had a packed cabin with around twenty people. I was glad Josh and Xiao were also able to make it out and get to know the ICA family a little better.

The first day at Tahoe we did a lot of driving, sightseeing, and picture taking. We spent the rest of the evening hanging out in the cabin playing games and fellowshipping. The next day we hit the slopes. We got a student discount, which means all day lift tickets for $15. I spent the first half of the day on the bunny slopes helping out and encouraging the first-timers. I still had a good time on the bunny slope and I fell a good number of times myself. I then went on the intermediate slopes a few times and got in my groove. I feel like it’s easier to snowboard on the intermediate slopes since you have enough speed to actually carve.

One thing I really appreciate about the trip this year is the amount of hangout time that we got at night. I rarely get to play games/hang out/fellowship much during the quarter so I enjoyed the evenings a lot. The last night we played Jenga with crazy punishments. As the game went on, the turns got longer and longer and the suspense kept growing. Fabian lost the first couple of games and we made him do a bunch of pushups. He lost again and then we made him go out in the snow and do a snow angel on both his stomach and back. He lost another time and made him stick his head in the snow for five seconds. He was screaming pretty loudly :D. Even though he lost a lot, Fabian did have a bunch of epic grabs. Jessie then lost and she had to do a snow angel on her back. We loosened the punishment because she was a girl. The last game I lost and had to stick my head in the snow for ten seconds. It didn’t hurt as bad as I thought it would. Maybe because I didn’t bury my head as deep as Fabian did.

Winter Conference

At the winter conference servant’s meeting I was asked to be the UCLA prayer coordinator. I was a little reluctant in accepting because I rarely ever pray out loud and in front of people. I held a few prayer meetings at UCLA for winter conference. Even though I didn’t really know what I was doing, God answered a lot of our prayers J

The biggest thing I took out of winter conference was the power of prayer. As prayer coordinator, I would hold prayer meetings before each session with Jimmy and Helen. Very few people showed up to pray before the first few sessions but we had a pretty large group the last couple of sessions. Throughout conference we prayed for at least one person to accept Christ and that we would all experience His power and healing. The last day at winter conference, David came up to the microphone and declared that he accepted Christ. I remember him saying that he was wrestling with Christianity for a while but he didn’t know why he finally decided to make the decision at conference. I believe that it’s evidence for the Holy Spirit at work.

The speaker, Ron York, shared some pretty crazy stories of how he experienced God in his life. These examples challenged me to remove the boundaries I placed on God’s presence/power in our lives today. During conference we were able to put these applications into action by going on a prayer walk at 5AM in the morning and making a short term prayer list. I also wanted to continue to grow in prayer after conference by setting time aside every morning just to pray and by holding prayer meetings every week. I feel that through a deeper and more consistent prayer life, I am able to see God’s working hand in every aspect of my life whether good or bad.

The last night of conference is usually reserved for hanging out and writing care-bear cards for people. I remember hanging out with Mark, Josh, and Xiao that night. I didn’t get a chance to talk to them much, but I realized after about five minutes of talking with them that they changed. Their faces were a lot brighter and we were actually talking about more spiritual things. It’s hard to explain. It’s just one of those moments where you had to be there. Glad they were blessed.

Phillip

By the start of winter quarter, Mark and I were able to share the bridge illustration with everyone in our IBS except Phillip. I had been praying for an opportunity to share with him. One week, only Phillip was able to come out to bible study that night so we saw this as the perfect time to finally share with him. We found a couple seats on the second floor of De Neve and I shared the bridge with him there. He agreed that there was a lot of emptiness in his life that the things of this world could not fill. After I finished the bridge, he asked some questions and then wanted to invite Christ into his life. I knew he was genuinely seeking God but I didn’t expect him to want to accept that very day. I thought he would be a #2 like everyone else but God surprised me. This was the first time for me seeing someone accept Christ in the US through the bridge illustration. Looking back, it’s easy for me to see God’s working that night.

On the walk back to our apartment, we agreed that Mark would follow up with Phillip.

Qualcomm

I applied to Qualcomm online and got a one hour phone interview with them during winter break. It turned out that the interview went okay and they invited me to an onsite interview for a software engineering position in the QGOV sector. I skipped class on a Friday and drove down to San Diego early in the morning for the 9AM interview. Unlike Laserfiche, I would be having six rounds of interviews so the entire day would last over five hours.

I first met with an HR guy who went over all the benefits and perks of working at Qualcomm. He was basically trying to sell the company to me. For this job, I would have to get a thorough security clearance since I would be working on very confidential government stuff and wouldn’t be able to tell anyone what I work on.

 The next five interviews were all technical. I slipped up on one of the problems I should’ve been able to solve. I thought, on the whole, the other interviews went pretty well. I felt like I did especially well on the last two interviews and these were with the senior engineers.

One of the interviews was actually done over lunch. My fourth interviewer tried to drive me out to a restaurant that he likes in Torrey Pines. I would’ve liked to enjoy cruising through San Diego but unfortunately the guy was throwing technical questions at me for most of the time. It turns out that the road to the restaurant was closed due to the Torrey Pines golf tournament going on. We decided to go back and eat at the Qualcomm cafeteria. It was alright – not as good as UCLA.

It was a pretty intense day but I walked out of Qualcomm thankful for the energy to make it through the day. The people I met there were very nice, I was excited about the work Qualcomm was doing, and San Diego seemed like a very nice place to live. I was waiting and praying for a long time. I told God that I wanted this job but only if it’s according to His will. About three weeks later, while all the guys were chilling at Nahsung before sushi night, I got an email informing me that I wasn’t chosen for the position.

I feel that I got carried away as I was hoping in this job. I wanted to stay around ICA but it was hard to find anything that would allow me to since a lot of the engineering jobs were away from LA. I started becoming desperate for something after applying for a bunch of jobs and getting a bunch of interviews but coming up short. After the Qualcomm interview, I was drawn by the attractive living environment in San Diego, the good pay, and interesting work. It was all about me, me, and me. I thought I had a decent chance at getting the position so I saw Qualcomm as a real possibility and put a lot of my hope in the job – but God shut the door.

The List

Leave a comment

Taken from Activate Your Faith by Russ Johnston

Do this: make a list of what you would like to be doing or have accomplished in three months if resources of any kind were no problem. Write what has been on the back burner of your mind from a week to ten years. In fact, go ahead – write some of those right now:

  1. Become a discipler and enjoy pouring out to him/them
  2. Be fully committed to God and His plan for me after graduation
  3. God willing, that I would know God’s calling for me
  4. Regularly keep in touch with overseas missionaries and V-SET students
  5. Bring at least one person to Christ
  6. Daily quiet times and consistent prayer (30 minutes in the morning, 15 minutes in the evening)

The Rich Fool

Leave a comment

Luke 12:13-21

Someone in the crowd said to him, “Teacher, tell my brother to divide the inheritance with me.” But he said to him, “Man, who made me a judge or arbitrator over you?” And he said to them, “Take care, and be on your guard against all covetousness, for one’s life does not consist in the abundance of his possessions.” And he told them a parable, saying, “The land of a rich man produced plentifully, and he thought to himself, ‘What shall I do, for I have nowhere to store my crops?’  And he said, ‘I will do this: I will tear down my barns and build larger ones, and there I will store all my grain and my goods. And I will say to my soul, “Soul, you have ample goods laid up for many years; relax, eat, drink, be merry.”’ But God said to him, ‘Fool! This night your soul is required of you, and the things you have prepared, whose will they be?’ So is the one who lays up treasure for himself and is not rich toward God.”

Older Entries Newer Entries