Interviewing tips for newbies

I've changed jobs about a dozen times (so far) in my career, and I've been on the other side of the coin many times as well.  So I think I've gained some insights into the interview process.  The last time I posted something on this topic was June of last year (and a follow-up as well).   So this topic came to mind when something else happened a couple weeks ago.

My udergrad alam-mater contacted me about a new alumni mentoring initiative they had started.  This is certainly nothing new - many colleges do it - nor was I special in being contacted.  I added my name to the list and filled out the online data form, and then I started thinking about what the heck I would actually tell someone if they contacted me.

One of the most intimidating aspects of getting a new job after college (at least for me) was the first job interview.  So here's a few things I jotted down.

1. Check out the company.  This should be obvious nowadays.  Check out the company website.  Then dig deeper: what division would you work for, what do they make, who are their competitors, etc.
2. Check out the interviewers.   Look at their LinkedIn profiles.  Look at any papers they've published.  Who do they report to?
3. Review the technology.  If you're not that familiar with the industry, spend a couple days and get familiar.  Download a PDF primer, read about it on wikipedia, whatever.
4. Consider what you'll be testing.   (This one is very specific to test engineering, but that's what I do.)     Find out what you'd be testing and spend some time thinking about how you would test it.  I guarantee you will be asked questions relating to that topic. 

If I do ever get contacted, maybe I'll write about the actual experience.

What comes after accelerators

A couple of weeks ago I wrote about my penchant for storing away articles I come across.  I've also talked many times about my continued interest (here or there, for example) in high energy physics.  It's been two decades since I left grad school, but I still have to credit my background in particle physics for my test engineering career.

A few days ago I came across a piece I had stored away from back in July about what might come after accelerators.  The author, Dr. Victor Stenger, pointed out that while ever more powerful accelerators may not be on anyone's radar right now, there are numerous other tests to expand our knowledge of the universe.

So I then looked up Dr. Stenger and found out he died back in August.  Depressing, but it looked like he lived a good life.  So I downloaded his last book God and the Multiverse and started reading it.  I'm only a chapter or so into it, but it's fascinating.

Black Friday flashback

I know Black Friday is still two weeks away, but can you imagine getting this as a Christmas present back in the day?

Interestingly enough, back in 2009 one of these sold for $4150 on eBay.

The geekiest part for me is the cloud chamber.  I remember reading about Wilson's work and playing with simplified cloud chambers back in undergrad.    Cool.

Reasons to test

I tend to be a packrat for interesting articles.  I'll come across something interesting, open the page, and then move on.  Consequently, I'll pile up 20, 30 or more open links on Chrome for iPad until I finally break down and binge read.

Today is a lazy Sunday morning, so I binged.  One of those stored links dated to way back in July about reasons to test.  It's a nice little summary of four canonical test types.  However, it missed at least two test reasons that are specific to volume manufacturing: binning and SPC.

Suppose your company makes thousands of widgets that have variations in a key parameter.  You therefore have two choices: spend time and money reducing that variation to acceptable limits, or find customers that desire those variations.  If you opt for the second one you spend time and money to implement the testing for that parameter, and you use the test results to put the parts into different categories for different customers.  That's binning.

I'm not going to try to describe statistical process control (SPC).  I've taken a couple of small courses in in it, and I've applied it to manufacturing testing at a couple of different companies.  But I'm no expert.  Go here for a good summary, and follow the external references for more detail.  All I will say is:

1. SPC is a requirement for high volume manufacturing.  
2. You need lots of data for SPC.
3. You have to test to get that data.

So why did the article's author leave out these items?  I can think of three reasons.  First, maybe he thought they fell under the verification or validation categories.  I could maybe buy the verification for SPC argument, but that's as far as I would go.  Second, his testing experience is in low-volume industries (i.e. - certain military markets) where SPC or binning isn't useful.  Third, he just wrote the article quickly to meet a deadline without thinking it through.

That last reason is a little harsh.  But this lazy Sunday morning is also kind of cold and overcast, so I'm a little morose.

(the internets love cats)

Matlab improvements

I went to a Matlab seminar a couple of weeks ago,  Actually, I thought that I would mostly hear about RF and microwave testing using Keysight (the company formerly known as Agilent) test equipment.  I knew they would throw in a little Matlab, especially since Keysight and MathWorks have becomes  BFFs (here or there).

I realized early in the day that it was shaping up to be a majority Matlab experience.  So I decided to roll with it and listen - besides which, I also scored a coffee mug.

My experience with mathematical software like Matlab is complicated.  Back in grad school I test drove  an early version of Maple, and I used MathCad to make some nifty models for my thesis.  But in the working world Matlab and Labview tend to conflict more than complement - google Matlab versus Labview to see what I mean.

I had used Matlab at several different companies the past decade and viewed it as a great tool if you're a researcher trying to put something together.  But when you have to get something to test shippable product, go with the more professional Labview.

That opinion was shaken up a bit with what I saw in the seminar.  The last version I used was Matlab 2007.  The latest version (2014) has quite a few new tools.  I'm not going to make this a Matlab commercial, but here's what caught my eye:

• Better debug support
• Source code control
• More tools fork converting what you just did into m-script or functions.
• OOP support
• Data highlighting tools

Of course, none of this means that I'll drop Labview and migrate to Matlab.  But the experience was an eye-opener...