|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
Canada971 Posts
On December 20 2012 21:50 icystorage wrote:i actually answered some incompletely. i was like 'the main difference about c and c++ is mainly about c++ being OOP' 'how?' boom. stumped. yeah i got the 'final' one correct tho  i first answered to make it abstract and he said it was wrong (i was about to bang my head on the desk) then i said convert it to final. yeah he also asked me the difference between array and ArrayList
fuck me, you must be kicking yourself.
|
i actually felt very dumb after that
|
On December 20 2012 21:50 icystorage wrote:i actually answered some incompletely. i was like 'the main difference about c and c++ is mainly about c++ being OOP' 'how?' boom. stumped. yeah i got the 'final' one correct tho i first answered to make it abstract and he said it was wrong (i was about to bang my head on the desk) then i said convert it to final. yeah he also asked me the difference between array and ArrayList
Yeah, abstract is definitely the wrong answer there . That does the precise opposite of making a class uninheritable.
Seriously don't stress it, though. Everyone has flop interviews. You'll do better the next time. In the meantime, you should write up a nice little object-oriented C++ program and then translate it into C. I did that my senior year (I wanted to implement a multi-processor version of a program I'd written earlier and we couldn't find a C++ compiler that was compatible with the old 8-proc machine I was given) and I now have the fundamental differences between the two languages burned very permanently into my brain.
Edit to add: Something that helps me a lot is that I go to interviews to have fun. That's not very hard for me because I don't get nervous easily, I enjoy interviews, and I've never been in a position where I needed the job I was interviewing for, but if you can get into the mindset that you're just having a fun chat about a subject you're passionate and knowledgeable about, then you'll flub a lot less answers. By all means act professional and respectful, but if your state of mind is that of a supplicant begging for favor, you're not going to come off as confident in your abilities.
|
yeah, that was a very nice eye opener for me to get back to the fundamentals and the basics. i was even surprised that i got asked about javascript, how to access an html textbox using javascript and i answer use getdocumentbyid where in fact it was actually getelementbyid, its like 2 years since i touched javascript, ive been using java and c# for years now. that really hit my confidence.
thanks i actually got a second interview tomorrow morning, im hoping i wont fuck up again.
|
assuming the string input for the calc problem is flawless, solve just by stacks
+ Show Spoiler + stack it up in postorder format w/ respect to the hierarchy of operators (mdas). if the incoming value is an operator then instead of stacking, solve the last two numbers using the operator then stack the answer...
and if you still need to prune the string i think the number of operatos correspond somehow to the actual count of ur numerals, so that's one way of validating if some retarded input got in eg. 1++++++++++++++++++++++++++++++++++++++++1.
if the incoming value ended as an operator then most likely it's fucked. sorry im drunk atm
|
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same.
|
On December 21 2012 09:37 waxypants wrote:
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same.
Yeah, I think some interviewers lose track of what they're actually looking for. Then again, some jobs simply aren't that challenging so most of the skillset they need is simply knowing what X function is called in Y language. Overall though, I think people asking language trivia in interviews and not trying to evaluate how you think is a sign of a bad company that you don't want to work for.
|
On December 21 2012 13:12 tec27 wrote:Show nested quote +On December 21 2012 09:37 waxypants wrote:
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same. Yeah, I think some interviewers lose track of what they're actually looking for. Then again, some jobs simply aren't that challenging so most of the skillset they need is simply knowing what X function is called in Y language. Overall though, I think people asking language trivia in interviews and not trying to evaluate how you think is a sign of a bad company that you don't want to work for.
I agree.
Those interview questions are plain stupid imho, they can be solved in 5s through googling (which even the best programmers do all the time) and they don't actually test how you approach and solve problems.
Any question that asks "What ...?" - like "What is the method name that does X?" or "What is the difference between X and Y?" or "What keyword makes a class uninheritable?" - are generally bad. Questions starting with "How ...?" or "Why ...?" - like "How would you solve problem X?" or "Why would you want to make a class uninheritable?" - are usually the good questions that end up actually revealing how good the programmer that you are interviewing is.
If a company asks you lots of bad questions, you will end up having lots of co-workers that are actually horrible programmers and working there will drain your soul until you are merely an empty shell.
|
Canada971 Posts
On December 21 2012 17:19 Morfildur wrote:Show nested quote +On December 21 2012 13:12 tec27 wrote:On December 21 2012 09:37 waxypants wrote:
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same. Yeah, I think some interviewers lose track of what they're actually looking for. Then again, some jobs simply aren't that challenging so most of the skillset they need is simply knowing what X function is called in Y language. Overall though, I think people asking language trivia in interviews and not trying to evaluate how you think is a sign of a bad company that you don't want to work for. I agree. Those interview questions are plain stupid imho, they can be solved in 5s through googling (which even the best programmers do all the time) and they don't actually test how you approach and solve problems. Any question that asks "What ...?" - like "What is the method name that does X?" or "What is the difference between X and Y?" or "What keyword makes a class uninheritable?" - are generally bad. Questions starting with "How ...?" or "Why ...?" - like "How would you solve problem X?" or "Why would you want to make a class uninheritable?" - are usually the good questions that end up actually revealing how good the programmer that you are interviewing is. If a company asks you lots of bad questions, you will end up having lots of co-workers that are actually horrible programmers and working there will drain your soul until you are merely an empty shell.
Or you end up with a monopoly on intellectual/programming capital within the company... get noticed immediately and get promoted really quick so you can inspire newer better practices under your leadership.
|
Those questions are very good for interviewers. They don't directly test your problem solving skills, but they show how much experience you have. Consider this:
OOP concepts are not something that you can "quickly read up on". Yes you can look up how to create a class, how to do inheritance, etc., but that's completely irrelevant. If you don't have thorough experience working with object oriented systems, you're gonna suck at designing, implementing, and refactoring them. It takes years of experience with these systems before you're gonna be able to design a big system that doesn't completely suck.
And when you say in your application that you\re experienced with C++, and then don't even know immediately by heart these very basic syntax rules for using OOP, it's blatantly obvious that you don't have a clue about OOP because you barely worked with it, and thus it's a heavy indicator that you're going to suck for the company. Or you've lied to them about being experienced with C++ and all you've ever worked with is another OOP language, which isn't exactly good either since you're being dishonest from the very beginning.
Some one who is actually experience with OOP and thus a good choice for a company that looks for someone who is good at problem solving using OOP will answer these questions very fast because they're trivial. It's a filter for the worst candidates, so to speak.
The same rule basically applies to language specific tougher questions, e.g. questions about performance in C++. These kinds of questions probably get asked at places where you're going to need to be familiar with them, because they are not things that you can quickly read up on without an extensive learning period. If an interviewer asks you why a code section with lots of "new"s is bad and you don't immediately know the answer to it, or how to circumvent those problems caused, it's again blatantly obvious that you've never worked with high-performance systems, and thus are going to cause problems in fields of work where performance matters.
IMO the same thing even applies to the easier language-specific questions, e.g. those which target your knowledge about standard language libraries, e.g. the STL in C++. If an interviewer asks you to search for a value using a simple linear search in C++ and you don't know that std::find exists, or if he asks you to sort and you dont know that std::sort exists, it's again blatantly obvious that you don't have a lot of experience with the language. And even though those library things are actually things you could look up quickly and answer with literally 5 seconds of googling, that does not mean that you're going to be a smart programmer and look for standard library implementations for typical problems, especially when it comes to cases which can not be boiled down to just one function call, but which could be solved elegantly with the combination of a couple of existing standard library components. It also indicates that code that you touch won't be exactly succinct and might be harder to maintain.
At the end of the day, the company has to pick the candidate that seems most suited to them. Actually having deep knowledge of the language you're working with is an advantage that can save you and the company significant man-hours when implementing something. Of course language knowledge isn't everything, but it's one of the many things an interviewer should check, imo. And if there's another candidate who's as good as you in all other aspects, but on top of it actually has a lot of experience with the language that the company works with, they're the most logical choice for the company. Without those language specific questions, they wouldn't have that additional information and would have to make a blind pick, possibly picking you even though you're worse for the job than the other candidate.
Of course all of these things shouldn't apply to completely entry level positions, for fresh BAs or even less, or for jobs which are not about programming and more about architectural design (e.g. business software) or algorithmic design (e.g. research), but for everything else it's imo pretty sensible to include those things as basic standard questions.
|
On December 21 2012 17:19 Morfildur wrote:Show nested quote +On December 21 2012 13:12 tec27 wrote:On December 21 2012 09:37 waxypants wrote:
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same. Yeah, I think some interviewers lose track of what they're actually looking for. Then again, some jobs simply aren't that challenging so most of the skillset they need is simply knowing what X function is called in Y language. Overall though, I think people asking language trivia in interviews and not trying to evaluate how you think is a sign of a bad company that you don't want to work for. I agree. Those interview questions are plain stupid imho, they can be solved in 5s through googling (which even the best programmers do all the time) and they don't actually test how you approach and solve problems. Any question that asks "What ...?" - like "What is the method name that does X?" or "What is the difference between X and Y?" or "What keyword makes a class uninheritable?" - are generally bad. Questions starting with "How ...?" or "Why ...?" - like "How would you solve problem X?" or "Why would you want to make a class uninheritable?" - are usually the good questions that end up actually revealing how good the programmer that you are interviewing is. If a company asks you lots of bad questions, you will end up having lots of co-workers that are actually horrible programmers and working there will drain your soul until you are merely an empty shell.
Not if you're hiring someone fresh out of schooling. If they're applying for a position that requires certain skills, they ought to have memorized enough of the basic methods, classes, etc. that they can rattle them off to answer those basic questions. There are plenty of people with degrees who know fuck all about any language, so this is a useful way to weed them out immediately.
The more general questions of "how would you go about solving this problem" is just the next step that tests one's critical thinking crossed with programming knowledge to see their ability to come up with elegant solutions and effective approaches, rather than trying to do "manual" tests for each case.
If you're hiring someone with a years of experience then I imagine you care less about specific methods because you have reason to believe they already are well-versed in that (by virtue of their years of experience) and instead care more about the high level way of going about the problem.
It doesn't hurt to ask both and you definitely want to be thorough if you're going to commit to having someone around for months or years.
Every applicant at my company is interviewed by multiple people from numerous backgrounds on a variety of subjects and since these interviews are often separately conducted (i.e. one immediately after the other) you can get repeat questions and the way the answers differ can be very telling; Consider if in a later interview the applicant has managed to think through the problem and come out with a much better answer. Being nervous in an interview is hardly a new thing and certainly nothing employers haven't seen before, but the ability to improve upon a solution is a useful skill. Incidentally I had 3 back-to-back in-person interviews and 1 or 2 phone interviews.
|
On December 22 2012 11:40 Craton wrote:Show nested quote +On December 21 2012 17:19 Morfildur wrote:On December 21 2012 13:12 tec27 wrote:On December 21 2012 09:37 waxypants wrote:
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same. Yeah, I think some interviewers lose track of what they're actually looking for. Then again, some jobs simply aren't that challenging so most of the skillset they need is simply knowing what X function is called in Y language. Overall though, I think people asking language trivia in interviews and not trying to evaluate how you think is a sign of a bad company that you don't want to work for. I agree. Those interview questions are plain stupid imho, they can be solved in 5s through googling (which even the best programmers do all the time) and they don't actually test how you approach and solve problems. Any question that asks "What ...?" - like "What is the method name that does X?" or "What is the difference between X and Y?" or "What keyword makes a class uninheritable?" - are generally bad. Questions starting with "How ...?" or "Why ...?" - like "How would you solve problem X?" or "Why would you want to make a class uninheritable?" - are usually the good questions that end up actually revealing how good the programmer that you are interviewing is. If a company asks you lots of bad questions, you will end up having lots of co-workers that are actually horrible programmers and working there will drain your soul until you are merely an empty shell. Not if you're hiring someone fresh out of schooling. If they're applying for a position that requires certain skills, they ought to have memorized enough of the basic methods, classes, etc. that they can rattle them off to answer those basic questions. There are plenty of people with degrees who know fuck all about any language, so this is a useful way to weed them out immediately. The more general questions of "how would you go about solving this problem" is just the next step that tests one's critical thinking crossed with programming knowledge to see their ability to come up with elegant solutions and effective approaches, rather than trying to do "manual" tests for each case. If you're hiring someone with a years of experience then I imagine you care less about specific methods because you have reason to believe they already are well-versed in that (by virtue of their years of experience) and instead care more about the high level way of going about the problem. It doesn't hurt to ask both and you definitely want to be thorough if you're going to commit to having someone around for months or years. Every applicant at my company is interviewed by multiple people from numerous backgrounds on a variety of subjects and since these interviews are often separately conducted (i.e. one immediately after the other) you can get repeat questions and the way the answers differ can be very telling; Consider if in a later interview the applicant has managed to think through the problem and come out with a much better answer. Being nervous in an interview is hardly a new thing and certainly nothing employers haven't seen before, but the ability to improve upon a solution is a useful skill. Incidentally I had 3 back-to-back in-person interviews and 1 or 2 phone interviews.
A far more effective way to gauge someone's skills is to simply ask them to solve a problem in a language of their choosing. By limiting their language choice in the beginning you're weeding out candidates who could be valuable to your company for no real gain, and by letting them choose the language you're still weeding out people who don't know what they're doing. I value my co-workers' critical thinking abilities and would want any new ones to have those same abilities, so valuing memorization of a specific language's mechanics, libraries, naming, etc. is detrimental to my hiring goals.
|
On December 22 2012 12:51 tec27 wrote:Show nested quote +On December 22 2012 11:40 Craton wrote:On December 21 2012 17:19 Morfildur wrote:On December 21 2012 13:12 tec27 wrote:On December 21 2012 09:37 waxypants wrote:
Bleh, how to do very language-specific stuff in interviews is dumb unless they can't afford to give you a learning period for some reason. Even so... I forget shit all the time and just Google it, no big deal. And I consider myself a pretty good programmer (better than most of my coworkers...). Although to admit my bias, my languages of choice are C and Python and I hate C++, so I forget a lot of the fancy OOP crap. However if I was forced to program with a highly OOP code-base, I would relearn it pretty quickly. I imagine most good programmers are the same. Yeah, I think some interviewers lose track of what they're actually looking for. Then again, some jobs simply aren't that challenging so most of the skillset they need is simply knowing what X function is called in Y language. Overall though, I think people asking language trivia in interviews and not trying to evaluate how you think is a sign of a bad company that you don't want to work for. I agree. Those interview questions are plain stupid imho, they can be solved in 5s through googling (which even the best programmers do all the time) and they don't actually test how you approach and solve problems. Any question that asks "What ...?" - like "What is the method name that does X?" or "What is the difference between X and Y?" or "What keyword makes a class uninheritable?" - are generally bad. Questions starting with "How ...?" or "Why ...?" - like "How would you solve problem X?" or "Why would you want to make a class uninheritable?" - are usually the good questions that end up actually revealing how good the programmer that you are interviewing is. If a company asks you lots of bad questions, you will end up having lots of co-workers that are actually horrible programmers and working there will drain your soul until you are merely an empty shell. Not if you're hiring someone fresh out of schooling. If they're applying for a position that requires certain skills, they ought to have memorized enough of the basic methods, classes, etc. that they can rattle them off to answer those basic questions. There are plenty of people with degrees who know fuck all about any language, so this is a useful way to weed them out immediately. The more general questions of "how would you go about solving this problem" is just the next step that tests one's critical thinking crossed with programming knowledge to see their ability to come up with elegant solutions and effective approaches, rather than trying to do "manual" tests for each case. If you're hiring someone with a years of experience then I imagine you care less about specific methods because you have reason to believe they already are well-versed in that (by virtue of their years of experience) and instead care more about the high level way of going about the problem. It doesn't hurt to ask both and you definitely want to be thorough if you're going to commit to having someone around for months or years. Every applicant at my company is interviewed by multiple people from numerous backgrounds on a variety of subjects and since these interviews are often separately conducted (i.e. one immediately after the other) you can get repeat questions and the way the answers differ can be very telling; Consider if in a later interview the applicant has managed to think through the problem and come out with a much better answer. Being nervous in an interview is hardly a new thing and certainly nothing employers haven't seen before, but the ability to improve upon a solution is a useful skill. Incidentally I had 3 back-to-back in-person interviews and 1 or 2 phone interviews. A far more effective way to gauge someone's skills is to simply ask them to solve a problem in a language of their choosing. By limiting their language choice in the beginning you're weeding out candidates who could be valuable to your company for no real gain, and by letting them choose the language you're still weeding out people who don't know what they're doing. I value my co-workers' critical thinking abilities and would want any new ones to have those same abilities, so valuing memorization of a specific language's mechanics, libraries, naming, etc. is detrimental to my hiring goals.
But you can ask the language questions in addition, so that out of two otherwise equally suited candidates you can pick the one with the better language specific skills for your company.
|
|
|
R1ch isn't the only one who works on TL, but he also is salaried at their HQ.
You don't necessarily want random devs doing things on a website and TL does not fit the model for an open source project.
|
On December 27 2012 02:37 Craton wrote:
R1ch isn't the only one who works on TL, but he also is salaried at their HQ.
You don't necessarily want random devs doing things on a website and TL does not fit the model for an open source project.
Yeah I agree with you but those things can be mostly avoided if you organize your team / community well. Read one of my posts on the thread I linked.
|
Damnit... I got bored of Learnpythonthehard way so I tried my hands on Project Euler. The first problem wasn't a problem(^.^) but the second problem I just can't figure out. I´ve been trying for hours to create a Fibonacci series in Python but I keep failing. Atleast I learned the while loop and how to get an element counting backwards from a list.
n = [1,2]
while len(n) < 100:
def function1(x):
z = x[-1] + x[-2]
n.append(z)
print function1(n)
Nothing happens :/
|
On December 27 2012 05:23 Recognizable wrote:Damnit... I got bored of Learnpythonthehard way so I tried my hands on Project Euler. The first problem wasn't a problem(^.^) but the second problem I just can't figure out. I´ve been trying for hours to create a Fibonacci series in Python but I keep failing. Atleast I learned the while loop and how to get an element counting backwards from a list. n = [1,2]
while len(n) < 100:
def function1(x):
z = x[-1] + x[-2]
n.append(z)
print function1(n)
Nothing happens :/
That code is awesome. :D
Nothing happens, because you don't call the function, thus it is never applied. The program will be stuck in the while-loop.
And please define functions in advance.
On the other hand, your function is working, I just tested it.
And please don't call functions in a print statement.
|
On December 27 2012 05:32 Perscienter wrote:Show nested quote +On December 27 2012 05:23 Recognizable wrote:Damnit... I got bored of Learnpythonthehard way so I tried my hands on Project Euler. The first problem wasn't a problem(^.^) but the second problem I just can't figure out. I´ve been trying for hours to create a Fibonacci series in Python but I keep failing. Atleast I learned the while loop and how to get an element counting backwards from a list. n = [1,2]
while len(n) < 100:
def function1(x):
z = x[-1] + x[-2]
n.append(z)
print function1(n)
Nothing happens :/ That code is awesome. :D Nothing happens, because you don't call the function, thus it is never applied. The program will be stuck in the while-loop. And please define functions in advance. On the other hand, your function is working, I just tested it.
Yeah, I just renamed it to "createFibonnaci" sorry for that.
So it works? Still doesn't do anything for me  I already thought it was in an infinite loop. However I didn't understand why. I'm quite sure I am calling the function right? with "function1(n)"
And please don't call functions in a print statement.
Ok.
|
Use only lower case characters, underscores and numbers for function names.
A style guide for Python can be found here: http://www.python.org/dev/peps/pep-0008/
It covers many aspects of formatting and how to name stuff.
Calling is not renaming it. You define a function and you can call it. That's applying it. The code, which is included in your function is not applied until you call or apply the function. In your example, it would be done after the while loop, but can't reach the end of it, because n never reaches 100, since you don't call the function inside the while loop.
It will become very clear to you, I have no doubt.
|
|
|
|
|
|
EPT
