The question you should ask at your next interview...
-
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 :-D
Let's go with that then.
You'll never get very far if all you do is follow instructions.
-
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.
Do you guys follow any ITIL methodologies and if so which functions do you implement and which tools do you use to help? This will show how joined up their thinking is from service requirement to delivery - the bits in-between should cover bug tracking etc etc...
-
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.
You should have questions. They should not be overly combative. As an interviewer I want to hear: Do you have coding standards? What are you code reviews like? How are new developers brought up to speed? Do the developers go to lunch together? How much latitude will I have in getting my job done? and... How do you deal with conflicts that arise? How does management view development? Do you pick release dates or feature sets? How? That last question will tell you a LOT about the company. I had a company that BRAGGED that they took out a magazine ad BEFORE the software was ready to DRIVE the developers to work harder. I did NOT take the job, never would. BTW, it failed, and they actually soiled their name in the process...
-
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.
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.
-
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.
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.
-
I'm not sure how relevant that would be – every company has some good code they could bring out for such purposes, and most of what they actually work on will be under IP agreements so they can't show it to you until you join anyway, I'd think. Having a look at where the devs actually work so you can get a feel for the place and the people is the most important, I think. Here at my company our second stage 'interview' includes the prospective new employee doing some coding on a computer in our main dev office, so they get to see how we all work and whether they like the working environment.
BobJanova wrote:
every company has some good code they could bring out for such purposes
Ahh, but there's the rub: the real insight from this experiment is: (1) If they know good code when they see it, (several of the organizations I've worked with over the years would stumble here), and (2) How easy it is for them to put their hands on (extra points if they offer to take you to a dev's desk as they pull up the version control repository, drill quickly through the code base and pull out some representative piece of code -- this will check off 3 or 4 items on the Joel Test right off the bat.)
-
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.
I doubt that they would show you any code. On the other hand, one time they wanted to see my code, so I brought it in on a thumb drive, and they said, "No way!" I guess they were worried that I implanted some virus on it. (Which in retrospect is a valid concern.) Since then, I always keep something on CodePlex, or TFS for everyone (or whatever they’re calling it now). One question I asked is what kind of source control do you use? One company said that they used to use VSS, but now they're not using any source control. I was a bit concerned to think that they could develop w/o source control, but what I didn't realize is that it was an indicator that they didn't use any project management SW, dev content management SW (i.e. SharePoint), nor did they even have any SOP for SDLC documentation in general (B/MRD, SRS, Design Doc, Test Plan). Looking back, I wish I would have really asked them about all of these items. Yes, I took the job. Some days I think, "What have I gotten myself into?" For example, someone asked me a question about IIS because a web app we wrote wasn't working the way it should. Together, we figured it out (default page name). I found out later this was all because she had simply moved it from a W2000 production server to a W2008 production server: no testing on a test server, because there is no test server and even if there was, there is no test plan. There probably never was even when it was originally written. Then on other days, I think, "Well, I'm gonna be that guy who shows them the way it's done (or at least how I think it should be done) :-)"
-
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.
As a qualified hobbyist, I did toy with the idea of becoming a professional developer once. I attended a couple of interviews, generally did very well, making it to the last stage, but I decided it just wasn't what I wanted in the end. Anyway, my point is that I felt exactly the same - I think asking to see sample code is an excellent idea, or asking to see coders at work. I had exactly the same idea, but never put into practice because of my change in career plans.
-
Do you really think that your shoes go well with this blouse you are wearing? :laugh:
Microsoft ... the only place where VARIANT_TRUE != true
"Is there chocolate?"
Will Rogers never met me.
-
Could be interesting to sit in on a code review. :cool:
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.)
-
The three question I always ask are: What's your beverage situation? (Do they provide free soda, or will I have to go to the corner deli for my Diet Coke needs) What provisions are there for my bicycle? (Is there is inside bike rack? Can I take it up the elevator and put it under my desk? (It folds)). Why is working here less evil than working at a bank? (Always interesting to see how creative their answers are)
Truth, James
James Curran wrote:
less evil than working at a bank?
Hey hey hey! None of that! Or are you saying that because you also work for a bank?
You'll never get very far if all you do is follow instructions.
-
I'm not sure how relevant that would be – every company has some good code they could bring out for such purposes, and most of what they actually work on will be under IP agreements so they can't show it to you until you join anyway, I'd think. Having a look at where the devs actually work so you can get a feel for the place and the people is the most important, I think. Here at my company our second stage 'interview' includes the prospective new employee doing some coding on a computer in our main dev office, so they get to see how we all work and whether they like the working environment.
BobJanova wrote:
every company has some good code they could bring out for such purposes
My favorite jobs have been the ones where there was no code yet; I had to write something completely from scratch based on just a rough idea of what it's supposed to do and the tools available. :cool: It's like being back in college. :badger:
You'll never get very far if all you do is follow instructions.
-
James Curran wrote:
less evil than working at a bank?
Hey hey hey! None of that! Or are you saying that because you also work for a bank?
You'll never get very far if all you do is follow instructions.
PIEBALDconsult wrote:
are you saying that because you also work for a bank?
I don't work for a bank ... anymore...
Truth, James
-
Could be interesting to sit in on a code review. :cool:
You'll never get very far if all you do is follow instructions.
Since I prefer generating code from my UML tool, I'd like to sit in on a design review instead ;P
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
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.
1. What are the hardware and software tools I get to use? 2. Can I add to that list? 3. Do you care about an ergonomic Workplace? How much are you willing to invest on behalf of your workers health and well-being? Bad code I can work with. But if the Employee isn't willing to invest in the right tools and environment, and understands that his opinion on 'right' doesn't necessarily match mine, then I can't work in that environment.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
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
-
"Is there chocolate?"
Will Rogers never met me.
-
Roger Wright wrote:
"Is there free chocolate?"
The only better thing than a chocolate is the free chocolate ;) But thank you i will add this question to my list. It is indeed needed.
Microsoft ... the only place where VARIANT_TRUE != true
Definitely an improvement, Argonia! :-D
Will Rogers never met me.