|
Reminds me of a note I left in code about twenty years ago because I had been given documentation for a newer version of a third-party system than the client had:
// The version of PI we are currently running does not include pisn_sendexcepstruc which we want to use
// so it is commented out and pisn_sendexceptions is used instead.
// When pisn_sendexcepstruc becomes available, this should be changed
While looking for this I also found:
tag_type *tag; // tag will be allocated dynamically, but treated
} line_type; // like an array (C is such a neat language)
Ah, youth.
You'll never get very far if all you do is follow instructions.
modified 26-Mar-14 21:59pm.
|
|
|
|
|
My two favorite comments of all time:
ld (HL),00h and
enum Types
{
Types_end };The first one was in a piece of code a friend of mine wrote in school. It copied a piece of memory into a graphics board buffer. The second one is mine, which I added after a *cough* younger *cough* developer kept adding new values to the enumeration in the wrong place.
Software Zen: delete this;
|
|
|
|
|
|
My whimsical comment of an xml parser (in C++) I wrote 3 years ago:
|
|
|
|
|
When I see comments like that I think "What an effing illiterate idiot. I hope that person doesn't still work here."
|
|
|
|
|
You know the bit where the interviewer(s) turn to the candidate and ask "Do you have any questions for us?"
I think next time I'm going to ask to see some code. You see - as a developer the application source code is a very significant component of my working environment and if it is like the aftermath of an explosion in a Scrabble(tm) factory I'd rather not get involved.
|
|
|
|
|
Where will I sit?
Do I get dual monitors?
If they answer those correctly your already home.
|
|
|
|
|
Indeed. One place I interviewed at asked me to see if I could find a bug in their code -- everything was a Singleton(!) -- one job I was glad to not get.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
"Which one did you mean?"
Should do that... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
They had a list and asked me to pick one to track down.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: One place I interviewed at asked me to see if I could find a bug in their code
One place I worked at, the owner ran ads saying he was looking for someone to take his place at running the company.
He'd give them the tour and spend a day with them, at the end he'd ask, "How would you do things differently?"
After the applicant had spilled his guts, hoping to get what he thought was going to be a high paying job, my boss would thank them and show them the door.
The ad was a cheap way to get one day consultants and he'd have multiple applicants for each ad.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
modified 27-Mar-14 11:03am.
|
|
|
|
|
Haha: that is an excellent question. 
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Problem is, they might let you look at some of their code, but they won't you the code you're being hired to deal with.
It was broke, so I fixed it.
|
|
|
|
|
Could be interesting to sit in on a code review. 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Remind me - what's a code review ?
|
|
|
|
|
Code review? I forgot too.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Code review?
I think it is a big musical show with lots of girls in bathing suits. At least that is what I remember from watching TMC 
|
|
|
|
|
Let's go with that then.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
At one of my interviews, they pounced on the fact I had helped at code reviews and gave me some code to review.
To me, there is a completely different mindset reviewing code and debugging it. They wanted me to catch the code errors when I was trying to figure out if the flow was logical, the intent clear and followed and if there might be a better way to do it.
When I do a code review, I expect it to already have been compiled and at least a first level test of the code has been made. (IE They compiled it, ran through the logic without blowing up using the simplest data combinations.)
|
|
|
|
|
Since I prefer generating code from my UML tool, I'd like to sit in on a design review instead 
|
|
|
|
|
S Houghtelin wrote: Problem is, they might let you look at some of their code, but they won't you the code you're being hired to deal with.
One place I applied to, they wouldn't even give me a hint as to what I'd be working on, for fear of revealing their next product. They would just quiz you about certain programming skills you had and your depth of knowledge.
I did not mind not getting a call back.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Besides the typical employment questions, I ask:
What source control system do you use?
Is your database schema normalized?
What's the spec's on the dev's workstations?
Who does your testing?
Do you even do testing?
What's your code coverage? (I love the "well, that's really hard to measure" dance)
How do I work from home?
And then for the real fun question:
I'd like to see an example of some specification / requirements documents.
And one more:
Do you pay for your employees to go to training seminars or to take online courses?
Marc
|
|
|
|
|
Oh Marc, Marc... I wish I had this list a few years ago. I'm in a very nice arrangement now, but I would have loved to see this interviewer prick squirm.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I've been on the other side of the desk for some years now (I'm not a good interviewer, I think it is pure luck we have a quality team) and have never heard these type of questions. I've even had a few who have no questions at all. I hate interviewing, from either side of the desk.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: and have never heard these type of questions.
That's because people don't know how to interview the company. And you've never interviewed me. I ALWAYS ask the version control question (and even a couple years ago, I've heard the answer "we haven't gotten around to it." TFS, Git, etc., have helped a lot with that though.
I also always ask the remote work question. It gives me a good read on the management style.
I also always ask the "what are the specs on the dev computers" question. It's amazing how often I will discover that the devs are not happy with their computers, and if there's a QA department, they have even older hand-me-downs. Again, a good read on the priorities of the company (at least from my perspective, hahaha.) It's also interesting to see the managers (who are often in the interview along with a dev or two) raise their eyebrows when the devs answer honestly.
People who have no questions in an interview I would never hire. They most likely also don't ask questions when they're hired, and that can lead to some real big problems and a lot of wasted time. I have some horror stories about that.
There's really two parts of an interview: the technical skills and the personality skills. I am often appalled at the poor technical questions, but good technical questions are hard to come up with. I've done some interviews that have a "homework problem" -- I quite enjoy doing these exercises, and if I were interviewing someone, I think that is absolutely the way to go. It gives the interviewee the time and space to put something together with relaxed constraints, and it gives the interviewer a really good read on their skills. Another more "high pressure" but fun thing is to do a simple pair programming exercise -- sit with the interviewee, give them a problem, see how they communicate, ask them why they're doing things a certain way. Lots of good stuff is revealed that way.
Personal skills (mainly communication) are hard too, but again, the pair programming exercise reveals a lot.
Anyways, that's my 2c!
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
