![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Job Market
- Thread starter mikeblas
- Start date
william_fontaine
Gawd
- Joined
- Oct 26, 2006
- Messages
- 744
Well, mikeblas is part of the true elite, and he did start the thread.
What is very different than what? I'm not sure what you're comparing. Meanwhile, the techniques for reversing a linked or traversing a binary tree haven't changed in a couple decades.
Sorry -- what is it that happens? What is usually a management screw-up?
this is usually a management screw up. not paying them their worth, not giving them position advances, treating them poorly.
I'm not sure what type of software you guys are talking about but in web development or design the technology is simply moving too fast to expect a new hire out of college to have anything but basic understandings, just the sad truth.
Last edited:
We have a super-low voluntary turnover rate, so there's no "management screw-ups". The problem is instead of betting on the employee's proven track record, you're suggesting we bet on their future ability to learn and perform and continue to grow. That makes hiring far more difficult -- predicting future performance with no track record and no ability to demonstrate skills in an interview setting is lots harder than predicting future performance with a track record and the ability to show those skills.
We're not trying to hire fresh out of college for any discipline. We're not asking about things that have recently changed or are new techniques -- simple memory allocation questions and managing data structures are techniques that have existed for twenty years in the C and C++ communities.
Though the solutions are often less than optimal, websites that show common interview questions demonstrate the question and the solution:Example One, Example Two, Example Three.
When you ask questions like "how do you traverse a binary tree" are you asking them for every precise step in C++ or are you just looking to see that they know the gist of it all?
Exactly how many potential hires do not end up qualify? The pickings are definitely slim...
Exactly how many potential hires do not end up qualify? The pickings are definitely slim...
Zangmonkey
Supreme [H]ardness
- Joined
- Jul 6, 2005
- Messages
- 5,065
I'm willing to bet that most couldn't answer "what is a binary tree?"
Zangmonkey
Supreme [H]ardness
- Joined
- Jul 6, 2005
- Messages
- 5,065
A competent developer should be able to contribute significantly within a month.
The point of being a developer is not to know "a language" but to understand the principles behind software and sustainable development in general.
This is what college training is for... not whatever language is trendy.
I would fully expect a skilled COBOL developer to be able to understand the fundamentals of .NET in a relatively short period of time.
What makes you a good developer is your ability to translate business problems into programmatic solutions, using repeatable, reliable and sustainable practices.
Nobody is complaining here that somebody uses a Collection.Count > 0 rather than Collection.Any. For the most part we're not talking about "gotcha" questions.
Forget language. Most "programmers" cannot explain the logical steps in solving a problem like FizzBuzz, let alone code it.
Societal pressures and ethical breaches are not mutually exclusive; clearly in the case I posted they were both necessary components in what transpired. Saying that moral breaches *can* occur in all societies doesn't speak at all to their frequency or the factors that motivate them.
In any case, I view that particular anecdote as just a symptom of a larger issue, which is high levels of academic pressure can be extremely unpleasant and probably have diminishing marginal utility. The methods of creating academic excellence in certain countries is, in my opinion, not worth the cost.
I suppose I meant North America. I am not from the US. I think our countries rank fairly comparably on these measures and have similar education systems given my conversations with friends and coworkers.
I think we have to be careful to say that simply because we rank low on a certain metric it necessarily requires action.
Last edited:
Perhaps that frustration reflects as elitism...
Perhaps you should broaden your search parameters... go head hunt at Google/Amazon/Apple.
Sure, you may not find a C++ god, but a competent developer should be able to catch on within 1-2 months. If not, just fire them within their 90 day probationary period.
mikeblas, I wanna see just how high your expectations are of computer science grads right out of college. Come up with an assignment that should take an hour to code from scratch, I wanna see if I can do it lol. Btw, you work at Valve correct?
Wiseguy2001
2[H]4U
- Joined
- Nov 28, 2001
- Messages
- 3,470
Yeah I have a hard time believing that, this is at the very basic end of loops and applying logic. Anybody who is doing a computing degree who can't do that should really just stop and reassess their options.
nameless_centurian
Gawd
- Joined
- Apr 4, 2003
- Messages
- 836
I'm writing with the specific discipline of software engineering in mind: The blame is threefold: students, schools/programs, companies who hire engineers.
Students are narcissistic. When they get a bad grade on an exam, most of them do not look to themselves as the source of the problem. In their minds, the problem isn't that they've been bonging beers all week instead of studying (because very few actually work outside of school). In their minds, they are naturally talented enough to figure out every problem the professor could ask, as long as they are "fair" questions. If they bombed an exam, then the exam wasn't "fair."
I taught an introductory course on CS concepts to non-majors. I started each semester with 100 students but usually had only about 20 who actually had a serious commitment to working in the class. These students would all get A's. If a student got less than an A but still passed, it was because he had coasted in the class and subsisted on the inordinate amount of extra credit I was required to give (10% of final grade... I was a T.A., not the primary instructor). The class had a 50% failure rate. This was fairly consistent across several years and dozens of instructors, with each year performing slightly worse than the prior for the past 10 or so years.
Secondly, schools are not run as institutions of learning; they are run as businesses. Their goal is to keep enrollment up so that their departments don't end up firing professors. To do this, they lower the standards expected from their students. They put up with the laziness, sleeping in class, and beer-bonging. They make the curriculum easier. They accept mediocrity in their own programs to keep enrollment up.
3 years after I graduated from my undergraduate institution, I visited the CS department after a job interview I had in the area. I spoke with the department chair, who was grieved because she was under pressure to either increase enrollment or lay off a non-tenured professor. The department answered by offering an alternate CS track to an already-weak CS program. The new track focused much more on programming than the topics one would consider as part of a traditional CS program. Under the new track, students were required to take only 2 semesters of Calculus (this adds up to learning the basics of differential and integral Calculus), plus one semester of discrete math. The rest of the CS requirements would be fulfilled in a combination of intro to programming, intro to architecture, intro to systems programming, intro to Java, intro to artificial intelligence, intro to data mining, etc. However, because the math prerequisite to these courses is now so sparse, they can only cover the programming techniques and very, very little theory. When the main thrust of a class becomes how to program a given set of algorithms, students take that as the end goal rather than the baseline it was meant to be. The result is that students aren't left to figure much out on their own and indeed complain quite a bit when the are asked to do so. This "figuring things out" by one's self is what promotes the ability to generalize knowledge, at least in my own pet theory.
The last part of the problem lies with the companies. Companies, in general, have their risk decision protocols defined poorly and are usually not inclined to hire entry-level workers to entry-level positions with the intent of grooming them into a more prominent role. Browse monster.com and see how many companies require x number of years experience in a specific language or framework, or with a specific type of programming, as if assuming that intuition does not carry at all between sub-disciplines. The number will be smaller, but also look how many companies demand a certain GPA from their entry-level students. Generally speaking, companies also demand almost instantaneous productivity upon hire, and there is no time to learn a discipline that is similar to another related discipline. Companies settle for a poor engineer who has at least a little knowledge in an area rather than a solid, intelligent engineer who has very little knowledge in the topic. I think this is one thing that has changed tremendously since about the early 1990's, but I am not qualified to be given any weight on this statement. I was too young to notice and care about such things at that time.
Together, these comprise a very difficult set of criteria for an entry-level engineer, but I think the same applies to experienced engineers as well. To combat this, your typical applicant will lie to you (and make the rest of us look BAD. I tend to remove things from my resume as time goes by... for instance, I haven't used .NET in two years and only used it for a year when I had it on my resume, so I think that if I place this on my resume alongside the technologies I have used daily for the past 3 years, a potential employer will get the wrong idea of my ability if they ask me questions on the wrong topic). They will work to gain a large breadth of knowledge amongst many sub domains in software engineering so as to be able to intelligently answer an interviewer's questions. This may manifest itself as learning multiple languages but mastering none, or learning to define the basic problems of a few sub-disciplines (UI, code architecture, system architecture) rather than learning one topic well enough to apply hard-earned intuition in a new subject. The result is that the applicant is unable to generalize knowledge to new tasks and can only do what he/she has done in the past. Additionally, it is common that a company would rather hire a new developer with a certain skill set than allow an existing developer to broaden his own skill set (presumably because to do this takes time). Developers are then caught in a cycle where they become specialized at the exact tasks they are given, and developers are given the tasks they are most efficient at completing. Because a company may be unwilling to eat some overhead as a developer learns a new technology, they do not gain the worth that this employee may add to the company under a different set of circumstances (but at this point, I digress).
The problem also remains that schools encourage their students to have breadth but little generalizable knowledge so that students can lie to potential employers, be hired, and the schools can advertise an incredibly high post-graduation hire rate to keep up enrollment!
Specifically regarding your linked-list code example in an interview, I think that's a very poor way to test candidates to see if they know how to code. There are a ton of factors that determine a candidate's success in this test, and the smallest is probably whether or not they know how to do it in the first place. Do you really think that an experienced developer who sounds reasonably intelligent when they speak to you cannot reverse a linked list? Are you sure it's not an intimidating atmosphere that temporarily blocks the ability to think clearly? I failed a polygraph for the same reason once.
I think a better test is to give them a larger task, a couple days to complete it, and see how they do. They can work at their own pace in their own setting and have no reason not to complete the task you've given in the time allotted. I've done this with applicants in the past, and it works well. You get to see how they solve a more realistic problem and you get to ask them about it at the interview. It gives you much more insight into a candidate's thought and work process than does a simple problem that a 15-minute creative block can kill. Admittedly though, you have interviewed and hired MANY more people than me (I'm actually not even in the position where I can decide to ultimately hire someone). I'm sure in your position I would be content with what has worked in the past, but for me right now I wouldn't even think of having someone write actual code in an interview.
Students are narcissistic. When they get a bad grade on an exam, most of them do not look to themselves as the source of the problem. In their minds, the problem isn't that they've been bonging beers all week instead of studying (because very few actually work outside of school). In their minds, they are naturally talented enough to figure out every problem the professor could ask, as long as they are "fair" questions. If they bombed an exam, then the exam wasn't "fair."
I taught an introductory course on CS concepts to non-majors. I started each semester with 100 students but usually had only about 20 who actually had a serious commitment to working in the class. These students would all get A's. If a student got less than an A but still passed, it was because he had coasted in the class and subsisted on the inordinate amount of extra credit I was required to give (10% of final grade... I was a T.A., not the primary instructor). The class had a 50% failure rate. This was fairly consistent across several years and dozens of instructors, with each year performing slightly worse than the prior for the past 10 or so years.
Secondly, schools are not run as institutions of learning; they are run as businesses. Their goal is to keep enrollment up so that their departments don't end up firing professors. To do this, they lower the standards expected from their students. They put up with the laziness, sleeping in class, and beer-bonging. They make the curriculum easier. They accept mediocrity in their own programs to keep enrollment up.
3 years after I graduated from my undergraduate institution, I visited the CS department after a job interview I had in the area. I spoke with the department chair, who was grieved because she was under pressure to either increase enrollment or lay off a non-tenured professor. The department answered by offering an alternate CS track to an already-weak CS program. The new track focused much more on programming than the topics one would consider as part of a traditional CS program. Under the new track, students were required to take only 2 semesters of Calculus (this adds up to learning the basics of differential and integral Calculus), plus one semester of discrete math. The rest of the CS requirements would be fulfilled in a combination of intro to programming, intro to architecture, intro to systems programming, intro to Java, intro to artificial intelligence, intro to data mining, etc. However, because the math prerequisite to these courses is now so sparse, they can only cover the programming techniques and very, very little theory. When the main thrust of a class becomes how to program a given set of algorithms, students take that as the end goal rather than the baseline it was meant to be. The result is that students aren't left to figure much out on their own and indeed complain quite a bit when the are asked to do so. This "figuring things out" by one's self is what promotes the ability to generalize knowledge, at least in my own pet theory.
The last part of the problem lies with the companies. Companies, in general, have their risk decision protocols defined poorly and are usually not inclined to hire entry-level workers to entry-level positions with the intent of grooming them into a more prominent role. Browse monster.com and see how many companies require x number of years experience in a specific language or framework, or with a specific type of programming, as if assuming that intuition does not carry at all between sub-disciplines. The number will be smaller, but also look how many companies demand a certain GPA from their entry-level students. Generally speaking, companies also demand almost instantaneous productivity upon hire, and there is no time to learn a discipline that is similar to another related discipline. Companies settle for a poor engineer who has at least a little knowledge in an area rather than a solid, intelligent engineer who has very little knowledge in the topic. I think this is one thing that has changed tremendously since about the early 1990's, but I am not qualified to be given any weight on this statement. I was too young to notice and care about such things at that time.
Together, these comprise a very difficult set of criteria for an entry-level engineer, but I think the same applies to experienced engineers as well. To combat this, your typical applicant will lie to you (and make the rest of us look BAD. I tend to remove things from my resume as time goes by... for instance, I haven't used .NET in two years and only used it for a year when I had it on my resume, so I think that if I place this on my resume alongside the technologies I have used daily for the past 3 years, a potential employer will get the wrong idea of my ability if they ask me questions on the wrong topic). They will work to gain a large breadth of knowledge amongst many sub domains in software engineering so as to be able to intelligently answer an interviewer's questions. This may manifest itself as learning multiple languages but mastering none, or learning to define the basic problems of a few sub-disciplines (UI, code architecture, system architecture) rather than learning one topic well enough to apply hard-earned intuition in a new subject. The result is that the applicant is unable to generalize knowledge to new tasks and can only do what he/she has done in the past. Additionally, it is common that a company would rather hire a new developer with a certain skill set than allow an existing developer to broaden his own skill set (presumably because to do this takes time). Developers are then caught in a cycle where they become specialized at the exact tasks they are given, and developers are given the tasks they are most efficient at completing. Because a company may be unwilling to eat some overhead as a developer learns a new technology, they do not gain the worth that this employee may add to the company under a different set of circumstances (but at this point, I digress).
The problem also remains that schools encourage their students to have breadth but little generalizable knowledge so that students can lie to potential employers, be hired, and the schools can advertise an incredibly high post-graduation hire rate to keep up enrollment!
Specifically regarding your linked-list code example in an interview, I think that's a very poor way to test candidates to see if they know how to code. There are a ton of factors that determine a candidate's success in this test, and the smallest is probably whether or not they know how to do it in the first place. Do you really think that an experienced developer who sounds reasonably intelligent when they speak to you cannot reverse a linked list? Are you sure it's not an intimidating atmosphere that temporarily blocks the ability to think clearly? I failed a polygraph for the same reason once.
I think a better test is to give them a larger task, a couple days to complete it, and see how they do. They can work at their own pace in their own setting and have no reason not to complete the task you've given in the time allotted. I've done this with applicants in the past, and it works well. You get to see how they solve a more realistic problem and you get to ask them about it at the interview. It gives you much more insight into a candidate's thought and work process than does a simple problem that a 15-minute creative block can kill. Admittedly though, you have interviewed and hired MANY more people than me (I'm actually not even in the position where I can decide to ultimately hire someone). I'm sure in your position I would be content with what has worked in the past, but for me right now I wouldn't even think of having someone write actual code in an interview.
Last edited:
We already do.
We'd expect a competent developer to be a permanent hire.
Yes, I work at Valve. You might try problems from this post, or think about some of the problems identified in this list. The first list has a few other interesting problems in the thread where it lives. Note, though, that we don't hire entry-level employees -- we don't consider CS grads right out of college, normally, unless they have exemplary work that has received wide acclaim.
We're asking for working C or C++ code. We're not sticklers about syntax; we don't chase people out of the room for a missing semicolon. Someone who's an experienced C or C++ developer should be able to write code to traverse a binary tree in 60 minutes, no problems.
I'm not sure I have exact numbers, and if I did, I'm not sure I'd be comfortable sharing them. If I receive 100 resumes, I might screen five to seven of the applicants. Of those seven, one or two might pass to an interview loop. Of the interview loops, maybe one of 50 gets hired. 7/100 * (2/7) * (1/50) = 14/35000 which is 0.04%, unless I'm having a bad math day. That number might be artifically low because we receive lots of unsolicited resumes from people who don't meet the minimum qualilfications we list for employment or aren't applying for positions we actually hire.
What do you think they might be? If someone really knows how to do a rudimentary task, I don't think pressure is a factor in completing that task. Be mindful that we're not flunking people because they forgot a semicolon -- we're flunking people because they simply can't come up with a working algorithm that they can translate to some kind of code that mostly looks correct.
We end up interviewing such people all the time. I would've hoped that experienced developers wouldn't have such problems, but they do.
Yes, I'm sure it's not an intimidating atmosphere. Interviews are tough, and everyone knows that. We do everything we can to keep the candidate calm. Being able to think clearly in tough situations is important, and people who are successful can do it.
Writing code to reverse a linked list is trivial; even if done wrong, it's only a dozen lines of code. I assert that candidates who can't complete something like this in 60 minutes aren't developers who know C or C++. There's nothing creative about this, and they've got lots longer than 15 minutes to solve it.
If that sounds harsh or elitist, I'm not sure I can help that as I can't imagine what less demanding gauge of basic competency might be substituted but still be a meaningful predictor of on the job performance.
We've considered doing things like this, but it's something we eschew for a few reasons:
We don't know if they did the work themselves or not over the time allotted. We don't know how much time they spent on it; did they do it in an hour, did they spend all waking hours between now and then doing it? They did it along, so we don't know what it was like to work with them when they did it. If it's an interesting task, they'll have questions -- how can they get them answered? What questions are they asking, and how do they react to the answers and advice they get? What was their thought process like?
Above all, though, it seems like most professionals wouldn't have the kind of time necessary to devote to such a test.
If you don't ask a programmer to program, how do you know they can program? Why would you hire them without knowing if they can, and how they would, develop on their advertised skill? If you don't know if they a rank beginner or a world master, how do you decide how to structure their compensation?
Last edited:
nameless_centurian
Gawd
- Joined
- Apr 4, 2003
- Messages
- 836
It's situational and cumulative. Did they have their coffee that morning? Did they sleep the night before after their travel? Were they concerned that the interviewer was watching everything they wrote on the paper? Were they giving more attention to their outward appearance to an interviewer than the problem at hand? Was it in their mind that this was their one shot and if they missed some simple gotchya then it was all over, so they were concerned more with trying to determine if it really was as easy as it sounds?
As I said, I failed a polygraph once. I failed on questions of violent crime, drugs, releasing intelligence to others, and a host more. If you knew me, you'd find this laughable. my mind was full of things like this.
Assuring people that they're in a friendly environment is probably not going to get them past this.
I must have passed over this part. I didn't realize they had an hour to complete the task. If they are given as much time as they need (up to an hour, seems more than accommodating) and don't have someone asking them questions about the problem incessantly and reminding them of things and asking what their favorite color is, then I think this is more than reasonable. In this instance, I wouldn't place much of an emphasis on time to completion, though.
If you are grading to absolute completion, then yes it will be difficult. If you are examining overall architecture of the solution and leaving the minutiae as a secondary consideration, and giving the applicant appropriate prompting as to where they should spend their time, then I don't see why time should be an issue. A lot of this depends on the position though. This would be much more difficult to pull off with a theoretical position than a sw architectural position.
I don't think you're going to determine this from coding questions. When it comes to this level, you're either going to have a pre-qualification test or you're going to be asking questions verbally and getting verbal responses.
Last edited:
Whatsisname
[H]F Junkie
- Joined
- Nov 15, 2000
- Messages
- 10,201
polygraphs are bullshit and meaningless.
while mikeblas might sound "elitist", he is not being overly critical of many of the applicants he sees, and is correct: most "programmers" can't program. It's actually not exclusive to programmers. Most EE graduates can't analyze many simple op-amp circuits, many ME graduates can't do common force balances, etc.
It's complicated, for a variety of reasons:
while mikeblas might sound "elitist", he is not being overly critical of many of the applicants he sees, and is correct: most "programmers" can't program. It's actually not exclusive to programmers. Most EE graduates can't analyze many simple op-amp circuits, many ME graduates can't do common force balances, etc.
It's complicated, for a variety of reasons:
- People that are incompetent are unaware that they are incompetent
- Many companies have people completely unfamiliar with the subject matter do the hiring
- Schools program the desire to learn out of students
- People go to universities for a degree instead of an education
Zangmonkey
Supreme [H]ardness
- Joined
- Jul 6, 2005
- Messages
- 5,065
#1 is absolutely true.
#2 I don't buy... software companies that have HR reps do engineer hiring probably don't last very long.
#3 I also don't buy... enthusiastic programmers are enthusiastic regardless of their education. School teaches you common solutions and proper practices and design patterns. If that ruins your enthusiasm then this isn't the field for you. Software companies live and die on the sustainability of their code base.
#4 totally agree
Whatsisname
[H]F Junkie
- Joined
- Nov 15, 2000
- Messages
- 10,201
Of all the degreed students a CS program produces, a very, very small sliver of them are enthusiastic programmers.
Education is not the same is schooling. Education is learning stuff, which is good. But schooling in the US removes the desire to learn from most people. By the time most kids get to be college, the drive for As and Gold stars is their primary goal, and learning is just a means to an end. It's no longer "I want to fill my head up with all this cool knowledge" that little children have, it's "I want to keep my GPA up". As soon as the GPA restriction is lifted, learning stops. Now that's not everyone, but it's most of them.
As for #2, there are still lots of companies, especially outside of software, that hire engineers and it's done by HR only. If you're lucky one engineer will be there with the HR folks. Consider the vast number of programmers that don't work for shrink wrap software companies. Many folks I know interviewed at Delta and Northwest for engineering positions. They got the same interview they give to Flight Attendants, Ticket Agents and Mechanics.
Education is not the same is schooling. Education is learning stuff, which is good. But schooling in the US removes the desire to learn from most people. By the time most kids get to be college, the drive for As and Gold stars is their primary goal, and learning is just a means to an end. It's no longer "I want to fill my head up with all this cool knowledge" that little children have, it's "I want to keep my GPA up". As soon as the GPA restriction is lifted, learning stops. Now that's not everyone, but it's most of them.
Mark Twain said:
As for #2, there are still lots of companies, especially outside of software, that hire engineers and it's done by HR only. If you're lucky one engineer will be there with the HR folks. Consider the vast number of programmers that don't work for shrink wrap software companies. Many folks I know interviewed at Delta and Northwest for engineering positions. They got the same interview they give to Flight Attendants, Ticket Agents and Mechanics.
Then I'm not sure what more we can do. What are your suggestions?
In a way, we don't. Some candidates reverse the list in 5 minutes. Some stumble through it in half an hour. Others burn 45 or 60 minutes and, at the end, don't have working code, can't see the problem, tied their pointers in knots, and can't recover. It's the last band of candidates that trouble me -- these are people who claim to be professional C or C++ programmers.
A coding question is a verbal question. We ask lots of other questions which gauge our offer. Point is, if we don't ask even a coding question, we've got no real idea of the skill for which we'd be paying the candidate.
I'm sorry that nameless had a problem with a polygraph, but I struggle to relate it to this situation. An interview is stressful, but it's not as stressful as many situations which might arise at work day-to-day. If the servers go down, do you want someone who panicked in the interview and is panicking now, or do you want someone who's grabbing a stack of hard drives and a tool kit and driving to the data center?
Polygraphs can be very meaningful if you're applying for a security clearance. You're just not going to get the job if you stand up and say "I'm not lying about the nukes! Really! Trust me!"
Some people are incompetent and aware of it; there's conscious incompetence and unconscious incompetence. Unconscious incompetence is bad; in that mode, a person doesn't improve (they don't know they need to, and don't know how) and is resistant to feedback. Feedback is the only thing -- next to a sudden personal realization -- that will switch them from Unconscious incompetence to conscious incompetence. Conscious incompetence is actionable.
nameless_centurian
Gawd
- Joined
- Apr 4, 2003
- Messages
- 836
I'm inclined to agree with you that if your goal is to see if they are able to manipulate pointers and correctly implement (within a certain tolerance) a simple algorithm, then I think you're being fair. I did not realize when I initially posted that you were giving such a generous portion of time. Given an hour of time, and not being pestered while working on this (perhaps even having the interviewer leaving the room or sit off to the side and work quietly, out of the candidate's view) would allow me to clear my mind enough to work. 15 minutes may not be enough, but 60 is more than plenty and conveys that you mean what you say when you tell the candidate that it's not the interview equivalent of a police interrogation.
I've let this part go on long enough. Please don't let my curiosity and my asking you to make sure your environment isn't the issue the primary thing I brought to this conversation. Regardless of your interview practices, there are real issues that you allude to in your original post.
I'm much more interested on your take on the other things I said in my first (massively edited) post. The things that I mentioned before asking you about your interview environment are experiences that I've had and observations I've made. I'm interested to hear your interpretation of these things.
nameless_centurian
Gawd
- Joined
- Apr 4, 2003
- Messages
- 836
It's a different type of stress. I work fairly well under stress. I drink coffee and work through the night(s) to meet a deadline. I often feel most accomplished when I meet a deadline that seemed impossible at first. I even seemt o manage the stress of my wife asking me when I'll be home and I need to keep telling her "one more day."
The stress from a polygraph or an interview is different because I cannot affect the outcome of someone else's thoughts. I can fight machines and programs and they always behave according to the same laws. Humans do not and are often unreasonable in their assumptions. So if anything that may make me a poor candidate as a businessperson, but as a technical lead or programmer, I do well (or so I'm told; I might do poorly in a different organisation).
The polygraph is water under the bridge. The NSA was taking too long to schedule another session for the contractor I was going to work for, so I took another job that did not require a TS/SCI security clearance, and I've flourished here.
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,808
The only thing about this particular question (and a few of the others I saw on the thread you linked), is that it's really a "know the trick and implement it" question. Sure, I had to figure out how to do it the first time I was asked, and it did only take a few minutes, but now that I've done that, I wonder how much more I should be doing for due diligence. I mean, if I verify it's, for example, a null-terminated list (versus circularly linked, which has fewer edge cases), is it okay to say "I've seen and done this before, so I apologize that I'm not having to figure it out on the spot. Simply start at HEAD, set its next to NULL, iterate through each node, caching the previous one and setting the pointer of each node you get to to the previous one. When you get to a NULL node, the cached previous node is now HEAD."? Of course, implementing it bug-free on a whiteboard or piece of paper is the next step, but I don't know how much thought process you're going to get from me for that.
One of the better questions I saw from you was this one:
Write a function to reverse the words in a sentence. If it gets "Good day to you", it returns the string "you to day Good".
I like that there is more than one way to do it, depending on language used and need for performance. There are questions that can be asked, such as handling newlines, tabs, double spaces, etc. In my mind, it seems to be a better question than the reversing a linked list one.
I can see why it would concern you that there are programmers who can't do the linked list reversal. That *should* trouble you. However, I do wonder just how difficult the interviews get once you get past the basics. When you say you're having trouble finding "good" engineers, at what point does the transition from the obviously incompetent to the "can program, but not well enough to work here" occur? What other traits make the distinction between the 50 "made it to interviews" candidates and the 1 hire?
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,808
nobody_here
[H]F Junkie
- Joined
- Feb 1, 2006
- Messages
- 8,878
Good engineers are typically egotistical and prideful. Not a slight towards anyone in the business, just a fact. Most good engineers are either A. already employed or B. not going to jump at any old offer, they will want a sweet deal, because they are good and they know it. You have to offer something the other suitors are not. Pay, benefits, prestige, contractual obligations or exemptions, or hold patents critical to something they are particularly interested in.......you cannot come in half assed with average pay and benefits and nothing that sticks out.
nameless_centurian
Gawd
- Joined
- Apr 4, 2003
- Messages
- 836
Yes.
nameless_centurian
Gawd
- Joined
- Apr 4, 2003
- Messages
- 836
I don't even know where to begin with this, you're so confused.
The phases of competence aren't unique to handgun training. They're rooted in education theory -- I think they were developed by a corporate training company back in the 1970's. They're applicable in learning almost any new skill, and in continuing education. I've encountered them in sports where I have taken coaching or lessons, and I think I first found out about them in some management training retreat years ago.
I couldn't disagree more. There's no trick to the question at all -- I don't think there's a trick to any of the others in my posts, either. The only goal is demonstrating competence, and perhaps doing so in a question that's difficult to take someone a little time to implement so we can talk over what they're thinking and how they approach the problem.
You can reverse a linked list in three or four different ways, and none are tricky. They're just ways to manipulate the list.
Yep. But at that point, we might not be into thought process. we'd agree to the algorithm -- like the one you verbally described here -- and ask the candidate to implement it. If they're not able to implement it, then they're not a programmer.
At that point -- programmer or not? -- the difference is huge. Programmers understand the reality of implementation. Some of the other questions drive squarely at that. The one that asks for the median of a list of 500 trillion integers is one: candidates fail because they don't know what a median is. We explain it, then they go on to say that they'll just sort the list and pick the middle.
But if you have 500 trillion integers, how much memory and time do you need to perform the sort? Saying "just load the list and sort it" is easy -- writing working code to actually do that takes insight and talent.
I agree, as it offers more room for exploration. We usually ask the linked list question (or one like it) during a screen -- when we just want to establish that the candidate is worth an interview loop in the first place. There are lots of interesting questions to ask.
But there's surface area on the linked list question, too. Of the three or four working solutions, there's always room for more questions about performance, stability, maintainability, debugging, testing, threading performance, and so on.
It's a trivial question -- anyone who's taken C++ and Data Structures (and passed, LOL) should be able to do it. But you can ask candidates with advanced skills more questions about it. If the candidate claims the be a multi-threaded scale-out genius, how would he approach the problem on a computer with 400 processor cores and a list size of a billion?
I don't have (and wouldn't share, anyway) rates for specific reasoning. We ask harder programming questions, and that helps us scope how good of a programmer people are. We ask questions about deciding what to work on -- writing code is the easy part; deciding what code to write is harder. We ask questions that help show idea generation, and that's more about raw intelligence and problem solving. We ask questions about product focus -- like comparing competing products, and that goes a bit towards customer interest, too. There's also something for personality fit. I guess we'll lose candidates very (very!) occasionally to visa issues or compensation problems, but those are the rarest of issues.
There are plenty of good jobs in the private sector that don't require a polygraph.
Well, it's a pretty giant post.
I guess I'd agree about students not taking responsibility for their problems. I've often seen posts here blaming the school or the professors for "not even teaching the class", or having an accent, or having inconvenient office hours, or whatever.
As far as I can tell, the student being interviewed here dropped out just because engineering is, like, hard, and stuff.
Thing is, I'm not sure how to address it. It's not something endemic to all students, because many do well and study and pass. Some excel at thinking out of the box, get passionate about their studies, and do great. They end up with a bunch of personal projects, internships, and jam through their first couple jobs.
What makes them different? Is it simply personal choice? But who consciously chooses failure -- or, at least, to minimize their potential for success?
I'm not sure I believe your assertions about schools being run as businesses. I haven't read studies about it or reports that substantiate it, and I guess the notion scares me a bit so I'm reluctant to believe it without evidence.
I have heard about universities running their sports programs in the interest of generating profits to run the rest of the university, and I guess that makes sense. But I've also read about schools with astronomically large endowments. The interest and investment income on those monies can pay for dozens of professors at healthy six-figure salaries ... and they're all at large schools, with more than 35,000 students, I think.
OTOH, schools seem like they might be diploma mills. People are programmed to think that they "need" a diploma, and they really don't. They go into debit paying for school, which moves a lot of money around, and that creates an industry.
You could make the argument that the schools should fail students more. They'd then pay for more time at school -- more credit hours, more books, more housing -- to try again and pass. That improves their education and their bottom line, right?
It's all suspect, I think, but I'm not sure what I'm inclined to believe.
Lots of companies do hiring in lots of different ways, so I'm not sure I can comment on that even as a generalization. I like the way that my company hires. We've made some great hires, though I'm terribly frustrated with the ability to find more engineers.
Blazestorm
Supreme [H]ardness
- Joined
- Jan 17, 2007
- Messages
- 6,940
Got bored and thought about the reverse list problem everyone was fussin over.
You can obviously see that I'm awesome and should be hired right away...
Code:
void ReverseList( Node* node, Node* prev )
{
if( node )
{
ReverseList( node->Next, node );
node->Next = prev;
}
}
int main ( void )
{
List list;
for( int i = 0; i < 10; ++i )
list.push_back( new Node(i) );
list.print();
ReverseList( list.Head, NULL );
std::swap(list.Head, list.Tail);
list.print();
}
Output:
C:\>g++ test.cpp -enable-auto-import
C:\>a
0 1 2 3 4 5 6 7 8 9
9 8 7 6 5 4 3 2 1 0You can obviously see that I'm awesome and should be hired right away...
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,808
Indeed, they appear to have been made by Gordon Training International in the 1970s. For some reason I attributed them to Cooper, as his Modern Technique came out in the 50s, and the current iteration of that largely emphasizes that kind of competency. Ah well, point still applies, at some point you cross that line in different areas of your skillset, though regression is possible when out of practice.
The linked list loop (rabbit and hare iterators) is definitely an "aha" problem. Sure, you could theoretically solve it other complicated ways involving hash tables and such, but two iterators is the only one that I think (slash have heard) is commonly considered the "right" solution. Am I missing something (NO HIRE!)?
Fair enough. Other ways I could think of would be to create a second copy in memory then reassign head, still roughly the same algorithm, but with the bonus of being thread safe and the downside of being memory inefficient. Hm, there's also recursive, but that is essentially the same as iterative (if using tail recursion). Can't really think of any others, do you have one?
I enjoyed thinking about this one before checking if my solution was close to the optimal one (though it could probably be tuned for a larger set, I'd have to test it). There were other things I thought of, but they all came out roughly the same - divide and conquer. Still, I do need to find time to play with some of the others you've posted, they are a lot of fun to mentally work out on the drive home and then try to implement.
Curl up in a ball and cry?
At that point (well, even from the start, the algo I used was definitely not thread-safe - helloooo inconsistent list), you're starting to get into questions (for which I am not fully prepared to answer - I will not claim to be that genius
) about paging, memory utilization, cache coherency, etc. I'd, personally, start to wonder what the real-world analog is to this problem.Understandable. How does job placement work at Valve, if you're allowed to disclose? There are "job openings" posted on the website, but they seem much more generic and broad than the ones here at MS.
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,808
Try that algorithm with a list that is 1000 items long.
I haven't touched C++ in many many years and I only took 2 classes in high school, but I could easily solve all of those in an hour or two and I don't claim to be a C++ dev on my resume lol. So that is very scary... I think it's what that other guy said, a lot of people are desperate for work and are just lying on their resume to try and look good for their interview. It's pretty scumbag that people would try and do that to work at a company like Valve
Blazestorm
Supreme [H]ardness
- Joined
- Jan 17, 2007
- Messages
- 6,940
You cheeky bugger... pointing out flaws in that flawless algorithm...
Here's an iterative version...
Code:
void ReverseList( Node*& head, Node*& tail )
{
Node* list = head;
Node* prev = NULL;
while( list )
{
Node* next = list->Next;
list->Next = prev;
prev = list;
list = next;
}
std::swap( head, tail );
}
int main ( void )
{
List list;
for( int i = 0; i < 1000; ++i )
list.push_back( new Node(i) );
list.print(100);
ReverseList( list.Head, list.Tail );
list.print(100);
}
C:\>g++ test.cpp -enable-auto-import
C:\>a
0 100 200 300 400 500 600 700 800 900
999 899 799 699 599 499 399 299 199 99