|
Was wondering if anyone been in an interview (interviewer or interviewee) as example of the existing product code is used?
I wonder if should do this in next candidate interviews, to head off any snarkyness if they join then start off on a bad footing.
"I said in the interview it was a work in progress, lots to do"
But hey, interviews stressful enough, visual aid may help. This to protect wasted time on flaky new hires.
Job interviews should be a 2 way interview.
|
|
|
|
|
Well, I've fortunately never had the pleasure of interviewing a potential job prospect.
It seems to me, however, that it's your evaluating the interviewee, and not the reverse. Why should it matter to them what stage of development you're in?
If they get there and turn up their nose, there's always the door. Make sure there's a probationary period clause in any contracts/employment agreements - which allow dismissal without cause.
Oh - I forgot to ask . . . you are paying them for working if you hire them, right?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
No, I agree with the OP: the interview should be a two way process. The company is selling itself to you as much as you are selling yourself to them.
How many times have you met a company and thought "I'll work for them when hell freezes over"? I have, a couple of times - it doesn't matter how good the job might be if the company is sh*t and full of PHBes your just know will drive you round the bend to work for.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OK - badly phrased.
I was thinking too much in direct context of the interviewee approving of the current status of their code.
In real life (chemist days) they'd roll out a red carpet for the interview - show you their pretty stuff - but they would not read you into a project. They would talk about project types and techniques. So yeah - there's a two way street about it. Still - a lot hinged upon your own presentation (a seminar) and how you can discuss what you've done and/or are doing.
Where I had the distaste for the imaginary interviewee is that the needed to approve your the status of the code base.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
What Griff writes. There's plenty of work out there, don't take a job just to have a job, if you can sense you're going to hate it.
|
|
|
|
|
Yeah but I do not need to see their code, because code can be changed.
I have to get feeling what people are like in a company.
Unfortunately I am not good enough to assess it in 1 hour talk with someone.
I have to work there for a couple months to see if they are bunch of a*oles or there are tribal fights going on.
|
|
|
|
|
maze3 wrote: Was wondering if anyone been in an interview (interviewer or interviewee) as example of the existing product code is used?
Probably impossible - certainly if I were an employer I wouldn't.
On the other hand, if I, as a potential employee, could see what I'm getting into, in most cases I would run away screaming.
[edit]On the other hand, rather than looking at code, it's a lot more useful to ask about processes, procedures, documentation, source control, etc. And when I'd asked those questions, in most cases I run away screaming too.[/edit]
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I don't think you need to (or even should) show them the code. However, building a powerpoint slide deck describing the project and it's current state might be a step in the right direction. On the other hand, a new hire only needs to be at the desired level of skillset in order to work on your code. Maybe the design has been too difficult to grasp, and if that's always been the case, maybe you've inadvertently discovered that your app design needs to be re-imagined.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
JSOP, advocating the use of a PowerPoint slide desk for something other than to keep middle managers busy and out of his way?
WTF happened?
|
|
|
|
|
I'm not advocating, I'm simply suggesting an alternative to showing a potential new hire code .
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
But...but...but...suggesting PowerPoint has any real use beyond the one I mentioned will lead me to re-evaluate my belief system. No good can come out of that.
|
|
|
|
|
Trust the plan.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yes you should feel free to do so. Totally.
I do not think it is about the new hire ”approving the status of the code base”. It is about showing your culture. And being open with ”some of this multiple inheritance stuff has gone convoluted and we want to do it right the next time”. Such frankness can be highly appreciated, especially by people who already have a few battle scars. Or you can just ask him/her, wanna peek at our codez? and see their reaction... I have on occasions asked asked myself can i have a peek? With cooperative responses.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
One place I interviewed -- and would have declined if they had made an offer -- all the classes were singletons.
|
|
|
|
|
At least they're using design patterns a design pattern 
|
|
|
|
|
I'll say this much, if interviewers provide a prospect with some source code and tell him he's got the job if he can find/fix some bug they've been struggling with for months (they won't tell you that part), then...run.
|
|
|
|
|
maze3 wrote: Job interviews should be a 2 way interview.
They are, it's just that most interviewee's do not understand their own position and limit themselves.
Which is good for me, means less competition 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
maze3 wrote: Job interviews should be a 2 way interview.
It totally is.
I once took a job that sounded really good, microservices, Azure, CI/CD, everything I was looking for at the time.
But when I got there they had nothing of the sort.
Turns out their "architect" had read about microservices, went to the development team and shouted something like "we have to do microservices!" and the person who interviewed me just kind of mimicked it.
No one in the team was feeling anything for microservices though, and management forbid the use of "the cloud" because it was "not safe" 
And so I sat there, doing the exact same work as before without microservices or cloud, except I now did it a 100 km's further than my previous job 
I was a contractor so I would be off after six months, but after four months I gave them my notice and ultimately ended up finishing a project and left after seven months.
If it was up to them I'd still be there though...
|
|
|
|
|
Unless you have a non-disclosure agreement (NDA), signed by your prospective employee, before showing them the code, I suspect your company's lawyers or senior management might not be happy with you.
So, if for no other purpose than upsetting lawyers, I vote yes 
|
|
|
|
|
Showing the interviewee how the team they are being considered for works is fine. Let them, meet a few people in person before them having to make any decisions.
Showing code on the other hand is not as transparent in my opinion. Bad people can write good code, and I for one can work with bad code but not bad people. In fact the current project I'm doing (ASP .NET MVC 3.5) is so badly written (transferred from another co.) that I had to decide on my own to implement DI in 2018 along with upgrading the framework to MVC 5 (not getting paid for either). But I have stayed with the same team for 4 years now. They are great people and that is what really counts.
modified 15-Sep-18 9:06am.
|
|
|
|
|
thanks all for some interesting replies.
Some of them had me thinking if the server network manager showed me the servers in my interview, and all the cables were one color, that might make me want to run out screaming.
|
|
|
|
|
Let me ask a different set of questions?
1) How often do you review code? (Code Reviews)
2) Do you have a Wiki with the details of how all code should be written/formatted, etc?
3) Have you made the code reviews combative or helpful?
4) Do new programmers get to participate in Code Reviews?
Then, I would show the PROSPECTIVE new hire the Wiki, and ask what they agree and disagree with, and why?
We allow exceptions to almost EVERY rule, if it is justified, makes the block easier to debug/analyze/or validate. But we push for consensus in these cases. Some things are defensible, others are not.
And if you are not doing code reviews. THEN you have found your problem. Our experience shows that without code reviews, NOBODY will take full ownership of the code, and continue to blame the people before them. We make you cleanup EVERY FILE you touch. AND we are flexible. The entire file has to be reformatted with default settings (if they were not applied before), and then the section that was "truly updated" is reviewed in detail. (Meaning EVERYTHING newly written or truly changed MUST follow our coding standards).
The results are amazing! Errors/Fixes are way down. The size/scope of fixes are a great predictor of the project being "done" and "stable" (if the last few fixes have been One liners. And we see nothing else, and it is in use, there are usually few if any gotchas remaining, and these things don't come back to haunt us. But a major rewrite... Ugghhh...)
Fix your culture first, and hire people who gravitate towards the rules!
|
|
|
|
|
maze3 wrote: Was wondering if anyone been in an interview (interviewer or interviewee) as example of the existing product code is used?
I've never done that. I've been tempted, but the code is an implementation of an algorithm, and all real world code is messy. I never expect anybody to be capable of dealing with that kind of mess in the context of an interview. Besides, the algorithm is the interesting topic to ask about, so I distill out a simple example and ask about that.
When I ask questions like this, I'm almost never looking to see if they get the "right" answer because I don't ask about textbook problems. I do, however, look at how they approach providing an answer, what they see, what they consider important, etc.
|
|
|
|
|
Is mugging people in a multi-storey car park wrong on so many levels?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The police may think the mugger is gonif [^] they on the wrong level. May be necessary to ramp up the search.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
