advice for interview
category: general [glöplog]
hi all, i applied at a software company and got an interview, the interview was iwht the president of the company, The interview went pretty well and his response was this email
That second interview is tommorow, and i'm freakin... I've been working pretty hard on a freelance project and havent even had time to read that first chapter... I actually read the full appendix, and about 3 quarters of the first chapter... I really wanna go in there and show him i've got more passion for coding than the others (and skill)..... what kind of advice can you guys give me?
Code:
Thanks for coming in to see me on Friday. I really enjoyed our conversation and I feel you are a very strong candidate for our .NET programmer position.
Even though we have one more interview on Wednesday this week, we'd like to invite you to a second interview where you can meet -name- our lead programmer and -name- our full time .NET programmer.
We are inviting one or two other candidates for second round interviews and quite frankly the other candidates have more .NET experience than you, but I don't think they have your passion for programming.
One of the things we want to go over in the interview is your comprehension of Object Oriented programming principles. So I'd like to ask you to read up on the subject. The questions will come from the first chapter and the appendix "Welcome to Objectville" in the O'Reilly Head First book called Object Oriented Analysis and Design.
We have an extra copy of the book here. You can come by anytime (M-F) from 8:30 to 5:30 to pick it up.
Hint: If you go the extra mile and read more and talk passionately about what you've read, it will really help your chances of getting the programming position.
Ideally, we'd like to meet with you later this week or next week. So please email me and let me know if and when you'd like to come in for a second interview and when you'd like to pick up a copy of the OO programming book.
Thank you,
That second interview is tommorow, and i'm freakin... I've been working pretty hard on a freelance project and havent even had time to read that first chapter... I actually read the full appendix, and about 3 quarters of the first chapter... I really wanna go in there and show him i've got more passion for coding than the others (and skill)..... what kind of advice can you guys give me?
object programming has made programmers :
1) write tons of superfluous classes and methods.
2) waste tons of CPU and RAM cycles.
3) expendable.
though i'm not sure that's what the guy wants to hear ;>
1) write tons of superfluous classes and methods.
2) waste tons of CPU and RAM cycles.
3) expendable.
though i'm not sure that's what the guy wants to hear ;>
Do you feel that you roughly know the OOP principle? You could always just go for it, chances are that you'll do alright. As the guy said, you seemed to have more passion try to focus on that.
What about that freelance project? You should absolutely tell him more about it, and why it took the time it did from you, even if it doesn't match the position you're aiming for to 100%.
What about that freelance project? You should absolutely tell him more about it, and why it took the time it did from you, even if it doesn't match the position you're aiming for to 100%.
I was thinking mentioning the freelance project could be good.... Its within the same relm of what i'd be doing with thim, but not so much so that if they didnt hire me i'd be competeing. I cant exactly tell him I dont like oop, but i'm with ya on the oop being wasteful, procedural is the only way to go ;) if you want to write truely elegant and efficient code..... oop == mass production && procedural == quality
oh, sorry, didnt answer the question... i feel pretty solid in oop programming :) on a 1 to 10 scale i'd say 6 or 7
You say you have pretty solid OOP knowledge so why do you need advice then? Somehow this is contradictory.
advice on how to handle the interview, not advice on code ;)
more specifically
I'm not quite sure what he see's in me to make me seem passionate, i mean, i know i enjoy coding, and i told him that... told him my history with code and all... i just wonder how to keep that up w/out recapping i suppose
more specifically
I'm not quite sure what he see's in me to make me seem passionate, i mean, i know i enjoy coding, and i told him that... told him my history with code and all... i just wonder how to keep that up w/out recapping i suppose
i had an interview a few days ago, and offered to tell them about myself but the second i said that i realised that i had nothing to say so i said, " i dont know why i just said that i would prefer if you asked me some quesitons" and it worked out ok, they want to hire you, so just ask them what they want to know about you specifically and then tell them about it...
And if you want to seem enthusiastic about code, i sudgest a t shirt that says "I FUCKING LOVE CODING" or one of these:
with CODING # 1 spraypainted on it.
And if you want to seem enthusiastic about code, i sudgest a t shirt that says "I FUCKING LOVE CODING" or one of these:
with CODING # 1 spraypainted on it.
oh god!!! "I FUCKING LOVE CODING" i'd pay some good money for a shirt that said that
Quote:
I cant exactly tell him I dont like oop, but i'm with ya on the oop being wasteful, procedural is the only way to go ;) if you want to write truely elegant and efficient code..... oop == mass production && procedural == quality
Seems you're not so familiar with OOP after all. I've about 1 month experience with C# and 10+ years of C, and I can already tell that C# is the elegant one. C is damn ugly but fast. Or that's what you should say at the interview atleast :)
Quote:
I cant exactly tell him I dont like oop, but i'm with ya on the oop being wasteful, procedural is the only way to go ;) if you want to write truely elegant and efficient code..... oop == mass production && procedural == quality
That is so wrong. C code is everything but elegant. If you want quality code, you'll have to cope with oop in the end, unless you work on little projects or on limited hardware.
As soon as you want to mess with complex stuff, pure procedural languages become a nightmare to write, read and above all, maintain. If parts of your project are critical speedwise, use inlines, avoid virtual functions and other oop usual overhead for those specific parts.
I think Skal/Bomb once said that in order to gain speed, the first step was to think again your algorithm before trying a lower level approach like assembler or C. I totally agree with that.
someone call up zest and tell him he's an idiot.
there's no inherent reason why oop code is any slower or faster than procedural code. (although some languages based on oop principles are slower because of their implementation.)
if you're interested in writing fast code the same rules apply to any language - know what the features actually mean and what their underlying results are.
there's no inherent reason why oop code is any slower or faster than procedural code. (although some languages based on oop principles are slower because of their implementation.)
if you're interested in writing fast code the same rules apply to any language - know what the features actually mean and what their underlying results are.
I think it's a bit odd that he points to a specific chapter of a book and tells you he is going to ask questions about that. Could it be that during the first interview you gave him the impression that you're not that skilled in OOP and that he now is testing how quickly you can pick up something new from a book? Or it could also be that the book has some flaws and he is now testing whether you'll be able to spot them. Maybe the book only mentions the positive sides of OOP and he know wants to test whether you know the limits of OOP as well?
Trust me- this guy is pulling your leg. They're gonna do a full day of interviews, and invited you just to have a good laugh inbetween boredom. If you're smart, you'll skip the interview and send them a note asking ransom for the book. Alternatively, you could go to the interview, but then you must insist on showing him all those great prods you added to this site, especially this one.
oh man, i was so drunk last night... what was i thinking... when i said about oop, to clear things up
i'm familiar with oop, but i grew up on procedural stuff.when i say ellagant, i'm talking about final product, not how easy it is to read the code, as said, procedural is damn fast (at runtime) whereas oop is damn fast (at design/code time). I dont want to seem like an idiot, i'm not saying one is right and another is wrong... they both work, and i'm fairly familiar with how to code with both.... Anyways, this isnt ment to be a post about oop vs procedural, so i'm gonna leave it alone after this post, but my status if someone asks me if i'm a procedural or oop coder is middle, the demo system i'm working on with fr0zen is using oop principals, but we've been talking about doing our own engine in a more procedural style....
anyways, thanks for the advice everyone, i'm gonna go do the interview and see what comes of it.... If i get the job, it'll make for some great experience professionally.
i'm familiar with oop, but i grew up on procedural stuff.when i say ellagant, i'm talking about final product, not how easy it is to read the code, as said, procedural is damn fast (at runtime) whereas oop is damn fast (at design/code time). I dont want to seem like an idiot, i'm not saying one is right and another is wrong... they both work, and i'm fairly familiar with how to code with both.... Anyways, this isnt ment to be a post about oop vs procedural, so i'm gonna leave it alone after this post, but my status if someone asks me if i'm a procedural or oop coder is middle, the demo system i'm working on with fr0zen is using oop principals, but we've been talking about doing our own engine in a more procedural style....
anyways, thanks for the advice everyone, i'm gonna go do the interview and see what comes of it.... If i get the job, it'll make for some great experience professionally.
@havoc thanks man :) that'll be the first one i'll show him...
I could change my nic and hide from that, but i'm more interested in showing everyone that i can do better
I could change my nic and hide from that, but i'm more interested in showing everyone that i can do better
Quote:
I think Skal/Bomb once said that in order to gain speed, the first step was to think again your algorithm before trying a lower level approach like assembler or C. I totally agree with that.
I reckon being able to quote famous coders would be good if you're trying to show you're passionate about coding.
right on, hehe...
> i'm familiar with oop, but i grew up on procedural stuff
You can do (if not netter) procedural coding using oop !! Overriding methods is sometimes very procedural-looking to my mind.
the suffs to know for oop is obvisously Design patterns
You can do (if not netter) procedural coding using oop !! Overriding methods is sometimes very procedural-looking to my mind.
the suffs to know for oop is obvisously Design patterns
psonice: I'm not that passionate though, it's just that we used to talk every now and then when he was active :)
Design patterns is most of what that book they having me read is... the appendix is an overview of how oop works, and then in the first chapter they dive into design strategies and how oop ties in.
I'm not sure I agree on the books design stratagie though, for example... In the first chapter their is a broken app, and they talk about first, how its not following the first rule, that the software doesent do what the customer wants.... so they fix it... then they say, the customer wants more, so they add to it.... then they go through the code and iron out redundancies using oop, then they go through and make sure its modular and extendable... Personally, I would want to strive for that modular design early on rather than having to go back and work with the base of my app after its some 10k loc.... I mean, their is no way to make it perfect the first time I suppose, and you'll have to backtrack sometimes to see whats been done, but to totally retrofit the thing with OOP afterward seems silly.... The book is about professional procedure though, so who am I to question it... This may be where my lack of professional experience comes in, lord knows i'm not trying to make an ass of myself, and i've got lots to learn...
I'll roll with it for the sake of getting the job
I'm not sure I agree on the books design stratagie though, for example... In the first chapter their is a broken app, and they talk about first, how its not following the first rule, that the software doesent do what the customer wants.... so they fix it... then they say, the customer wants more, so they add to it.... then they go through the code and iron out redundancies using oop, then they go through and make sure its modular and extendable... Personally, I would want to strive for that modular design early on rather than having to go back and work with the base of my app after its some 10k loc.... I mean, their is no way to make it perfect the first time I suppose, and you'll have to backtrack sometimes to see whats been done, but to totally retrofit the thing with OOP afterward seems silly.... The book is about professional procedure though, so who am I to question it... This may be where my lack of professional experience comes in, lord knows i'm not trying to make an ass of myself, and i've got lots to learn...
I'll roll with it for the sake of getting the job
Keops: You lie! And I have proof!
Arg. Ok maybe a little bit then :))
ugh.. 8:30 now... interview at 9:30 ...