Interview preparation

Yes. Likewise, the company's layoffs suggest to me it has little or no interest in the success or otherwise of me. That in turn suggests that it has no interest in a long-term commitment of me.

I do have no interest in a more senior role. I'm not a politician, nor do I enjoy planning large projects without much hands-on work. I like learning new technologies at an intermediate level. It's enough challenge for me. I couldn't care less whether it's enough for other people or if it impresses other people, as long as they don't insult me like they do when they give stupid evaluations that only acknowledge ass kissing and politics.

That's true, but if I cared about the big picture, I wouldn't enjoy writing device drivers, especially not embedded device drivers. An architect can worry about that. I don't want to be an architect. I avoid any job postings that say "senior" or "principle".

Yes. Likewise, the company's own agenda will always be priority #1, and hence it's also likely that the company is not concerned about the individual. I'm proud to not be a team player. I'm an individual. To me, "team player" is a vulgarity more offensive than a Mexican donkey show.

That's okay. It's a very accurate description, and I take it as a complement. :-)

You see, my goal is not to get hired. It is to be, wherever that takes me. Those without faith may say it will take me to hell. I say those without faith are already in hell.

Reply to
BubbaGump
Loading thread data ...

Well, funny enough, my wife and I used to own our company as a partnership, but we are going through a divorce right now and I made her my employee. That solves many problems :-)

Meindert

Reply to
Meindert Sprang

"[..]

No-one would argue that engineers require not only a thorough technical background but [..] the willingness to adhere to strict and sometimes tedious processes. [..]

[..]"

Someone in Green Hills Software had an article published in the June

2006 or September 2006 issue of "Ada User Journal" (which is currently in the house but I can retrieve it tonight to post an exact quotation tomorrow if requested) in which it is admitted that Green Hills Software has been benefiting from not adhering to processes for more than the ten previous years, in contrast to:

"[..]

[..] It is [..] important that a company be able to manage changing customer requirements in a manner consistent with the DO-178B process, [..] [..]"

on

formatting link

Reply to
Colin Paul Gloster

I thought about it more, and I have a few disagreements with this particular conclusion. First, I see the biggest picture, that ultimately nothing (including me and the company) means anything. In the next biggest picture, I see that nothing in this world (including the company) means anything, but I do like a way to keep myself occupied and entertained.

I'm not sure if I already said this, but we have some commonality here. I do have an interest in the types of products a company produces, since I have an interest in the purpose of the work I do, what customers will do with it. One of the reasons I didn't like an old job was because the products didn't seem to have much purpose. That's not to say I didn't enjoy much of the work, but it's icing on the cake when the larger product is useful.

Don't even bring design into this. Design is always on my mind, but design stops at the single product on which I'm working, possibly touching other products that might interact with it. The company's "business", the collection of possibly unrelated products it sells, has nothing to do with design. The company's "business" is for the weak-minded, greedy stock holders. Design is for we intelligent engineers. How can we not design? Don't insult me.

Processes? Of course I'm looking for ways to improve processes, like getting rid of useless faux-managers and recruiter-type administrative people and only leaving the core leadership intact. I also think about how project schedules and project meetings are often a delusion and a waste of time that distract from actually doing the work. I'm not a team player so I do actually think about radical ways to change the status quo, constantly, but these are not things that can be resolved during an interview. These are things that evolve over time while actually working.

Anyway, the way that headhunter expressed his question just sounded off to me. It sounded like a generic way to ask how the company is going to make money, probably because money is all headhunter's understand. My interest is in the types of products the company is going to make, which for most companies will be similar to the types of products they currently make. For this reason, the question is pointless because the answer is obvious. The real question is, assuming a web site browse doesn't answer this fully, what type of products they currently produce and what type of software development work that involves. Only if they produce very few current products, will I be concerned enough that working for them might be boring to ask whether they ever plan on doing anything else, but that's my own curiosity. It's not some fake, made-up line generated in order to impress them into hiring me.

Reply to
BubbaGump

(snip)

I guess it all depends on the type of process you're talking about.

I was talking about processes such as formal review, simulation, regression-testing, revision control etc.

Anyone who claims they have "benefited" from not adhering to these processes is either a cowboy or a fool...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

Some processes are helpful. Some get in the way.

Design reviews are okay.

I've always found peer code inspections (reviews) get in the way. I find most of my own bugs through an intuitive, zen-like combination of inspection and testing, but this is only effective because I have an intimate relationship with the code. Another person won't feel the code as I do nor I his/her code without a lot of time spent, so much time that we would be distracted from our own work for an impractical length of time.

Simulation is useful, but I don't consider it a rigid process. I just consider it a technique to be used when desired.

Regression testing is okay to make sure the code doesn't fall over immediately, but I put little faith in scientific tests applied to something that is a mix of science and art.

Revision control is awesome. I do revision control even when there's no revision control system, with my own numbered directories.

Reply to
BubbaGump

Some more...

Mark McDougall posted:

"Col>Someone in Green Hills Software had an article published in the June

I guess it all depends on the type of process you're talking about.

I was talking about processes such as formal review, simulation, regression-testing, revision control etc.

Anyone who claims they have "benefited" from not adhering to these processes is either a cowboy or a fool..."

In the article "Subversion of the C language" in the April 2006 issue of "CVu", it is written:

"[..]

Now to something evil, especially if you don't read it carefully:

#define FOREVER for(;;); #define FOREVER while(1);

[..]

If you are allowed to, the best way of dealing with this nonsense it to remove the #define(s) and then fix the compile errors by putting in the correct idioms. If this is not permitted, you will need to remove the FOREVER one by one whenever the code changes for another reason and hope the process police don't catch you.

[..]

A third flavour, to give you real confidence about programmer knowledge and ability:

#ifdef FALSE /*if we included the standard header*/ #undef FALSE #define FALSE 0 /* use the standard definition */ #else #define FALSE 1 /* else use in-house definition */" #endif

Sometimes these errors are picked up at code review time, and the source code revision system recorded the change:

before: #define FALSE 1 after: #define FALSE (1) SCCS: Code review change - Coding standards say all #defines must use parentheses around all variables and all expressions.

You might note that this seems a particularly enlightened development team:

  1. They use code reviews.
  2. They use a source code control system
  3. They have coding standards containing useful advice
  4. They add comments at code check-in time.
  5. The comments are meaningful.

With all this going for them, you might be tolerant of a slightly dodgy #define!

[..]

Are we done yet? (slightly tongue-in-cheek) guidelines: [..]

  1. Code reviews are useless if they consist of the blind leading the blind - there must be at least one good programmer present!
  2. Don't allow Coding Standard Lawyers in to code reviews - they will use all the time to correct the code and leave no time to spot the errors."
Reply to
Colin Paul Gloster

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.