An employment interview

[pyesetz]

From:	[me]
To:	[recruiter]
Date:	August 9, 2006
Subject:	Interview

[Name] Industries is a squat building in an industrial area outside of [Town] PA.  The building's entrance leads to a small waiting area containing four plush chairs, a plant, a receptionist behind a glass window, a stairway leading up, and a door with a digital combination lock.  On the walls are framed pictures of the company's products.  In the plant pot there is a diagram showing the layout of the building from the alarm system's point of view.  There is no other reading material.

While I am waiting, a young woman in jeans exits from the locked door and greets the receptionist on her way out of the building  Along with another fellow-employee greeting later, it is the only idle conversation overheard during my two hours at the company.  Either everyone at [Name] uses email for *everything*, or this is a company of taciturn people.

[VP-HR] lets me in through the locked door.  The contrast is extreme: the inside hallways have not been refurbished in quite some time.  I pass by some cubicles, including one that appears to be the official shingle for a one-desk company residing within [Name]'s offices.  The cafeteria has some of [Name]'s machines in it and employees are playing with their own products.

[VP-HR] takes me to [VP-Software], then returns to his own office.  [VP-Software] gives me the "five cent tour".  The QA department seems reasonable enough.  The software development area is extremely dark, with table lamps on some desks; something about the mood in that area brings a smile to my face.  There is no talking.  The production area is not air-conditioned.  There is little or no talking.  There is a ramp leading up to the second floor, but I am told it is "just for storage" and the tour does not include any of the various stairways to the upper floor.

[VP-Software] gets [Director-Software] and we find a conference room.  [VP-Software] is quite talkative, while [Director-Software] says almost nothing.  [VP-Software] repeats some questions from the phone interview.  It seems the job basically involves refactoring some software that has been patched to death over the last five years.  [Director-Software] asks about my first refactoring job back in 1983, and about [a Company ℱ product] (which unfortunately is an engine to help people take tests, not a method of automated QA that he was looking for).

For the "whiteboard" part of the interview, I was supposed to talk about software encapsulation.  I chose [another Company ℱ product], which I haven't worked on for six years.  And it was written in C and [VP-Software] believes C is obsolete and everyone should use C++.  So I'm not sure how well this part went.

[VP-Software] has strongly-held beliefs about software methodology which are more aligned with academic thought than with what the world's leading sofrware engineers actually do.  It is not clear how much a VP's opinion on such things really matters, but [Director-Software] neither supports nor opposes what [VP-Software] says.  After the interview, [Director-Software] can't wait to take his leave and run back to his desk.  It seems he has real work to do.

[VP-Software] brings me back to [VP-HR], who asks typical HR questions ("What do you like in a manager?  What do you dislike in a fellow employee?")  [VP-HR] is proud that people who leave [Name] often come back to their jobs, but the same thing used to happen at [Company ℱ] — I think it indicates a workplace with many minor irritations that are never resolved.  The company's core hours are 10-4, but [VP-HR] disagrees with his own company's policies and believes there is no reason why every employee can't get to work at 9 AM.  (In college I got poor grades in every class that met before 10.)  He also contradicts what [VP-Software] said in the phone interview about [Name's owner] being a conglomerate of troubled companies.  No no, [Name] isn't troubled!  [Conglomerate] bought [Name] as a cash cow!  He downplays the declining-industry aspect of tavern gaming by eliding the differences between [Name] and its sister company [Other name].  I would not want to take this job if it involved frequent contact with [VP-HR], but it probably doesn't.

Useful nugget from [VP-HR]: the refactoring project is [VP-Software]'s baby; he went to [Conglomerate] and got them to authorize it.  Since [VP-Software] is so new, I suspect that [Conglomerate] brought him in as a turnaround specialist.

Overall, the two main demerits I see are the lighting in the software development area (which strongly suggests that no one ever sits back to read a printout) and the VP-HR's attitude towards work hours.  Neither seems a strong enough reason to reject a job offer.  I think the main demerit that I presented to the company is that I am not the strong advocate of C++ design patterns that [VP-Software] seems to be looking for.  I prefer to do what works, what can be maintained, what scales well to large projects.  I expect that I would work well with [Director-Software], if that is what the day-to-day job actually entails.

In my previous email to [Recruiter], I forgot to give as a reference my current employer, [Company 𝔾] of [Town] California [Telephone number].  He recently wrote: "I am really enjoying the rapid pace of progress working with you".

Comments

[shockwave77598.livejournal.com]

C is NOT obsolete! Especially in the embedded systems world. When you have small flash and small ram spaces, the last thing you want is some program that takes up lotsa ram or code space. Forget overloading - just write the routine to work on exactly the data you want and that's that. Don't throw a 16K rock at a 512byte problem when 32K of codespace is all you have!

[pyesetz]

The Linux people have a FAQ about why they don't use C++.  The L4 people are using C++ in a kernel, but it's C++ with a lot of strange-looking source code to prevent all the wasteful behind-the-scenes stuff that C++ tends to introduce.  If you're not doing fancy stuff behinds the scenes, C++ is just C with syntactic sugar to represent packages as classes.  I find plain C much easier to read.

C is much better for shared libraries.  C++ stupidly requires the *caller* to know at compile-time how big the class-object will be, which means a class in a shared library can't be altered to add more private variables.  Also C++ has the virtual-function tables compiled into the *caller*, preventing a shared library from adding new class members in future revisions.

Another reason not to use C++ in embedded systems: it has many arcane rules for when objects marked "const" are *really* read-only and when *only the compiler* is allowed to alter them, which makes it difficult to create data structures that will be stored in ROM.  In some cases the only way to force an object into ROM is to define it in a C module that will be linked into an otherwise-C++ system.  It's just not a well-engineered language.