Who would you hire and why?
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
Hiring manager: The one who asks for smaller paycheck. Me: I would give A some time and read up about one of the algorithms that you might be using. If he can pick it up in say 30 minutes (at least bare basics) I would know if he is a quick learner. And by pick up I do not mean cram it up; I mean if he can at least tell me why are we doing what we are doing for at least first two steps. For B, I would ask him to write a complex algorithm. I guess he will be done with it fairly quickly. Then I can ask him to refactor it and make it cleaner. Post these two tasks, I might have a better understanding of whom to hire.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
-
Maybe we have different experiences ;)
cheers Chris Maunder
Well, they actually depend on each other. If you don't understand what you're doing, the code will certainly appear as unclean
Wrong is evil and must be defeated. - Jeff Ello
-
Neither, because they are both figments of your imagination. If you ever do have the good fortune to meet such people in the future ensure that you breed with them.
I'm sorry but you aren't the right candidate at this time but would you care for a marriage with my daughter instead? ;P
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
Depends on the work they have to do. Personally, I've never needed to write a (complex) algorithm in my professional life (as they're all already implemented in .NET), so candidate A would be my pick. Other algorithms, like file compression or whatever, written by people who can code AND know their algorithms, can be downloaded from GitHub :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
I'd hire A. From my experience, algorithms can be taught, high-levl mentality can't. While A surely will simply use std::vector, B will run a custom variant of everything except malloc (and maybe even that) resulting in an unmaintainable mess of code. A, on the other hand, will produce clear, reviewable and debugable code. While B's solution may squeeze a couple of milliseconds runtime out of the same platform, A's solution will squeeze out man-years or productivity of actually getting things done.
-
Well what's the rest of the team like? Do we already have a "data structures and algorithms"-guy in this hypothetical sitation? If not, no amount of clean code is going to make the hypothetical application non-shit.
-
Also conversely, no amount of efficient algorithms and data structures is going to make that spaghetti code testable and maintainable in the future but clean code can allow replacement of algorithms or data structures with little effort :cool:
Sure. But it's just one guy, it's not like the entire code base is going to be spaghetti just because he's touching it. You can fix his style now, or you can fix his badly performing code now. Or later, but let's do it now. Which one you can actually do depends on the rest of the team.
-
Candidate A. You can teach algorithms. You can't teach extremely clean and readable code.
cheers Chris Maunder
Agreed, to add to that: - Algorithms and data structures are topics easy to look up and teach. - OO and SOLID concepts are somewhat abstract and open to interpretations, some people never get it, others take a long time to really understand how to leverage it. Much harder to teach. - Clean and understandable code is on of the rarest trait to find. It's a gem and I would surely not waste it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Candidate A. You can teach algorithms. You can't teach extremely clean and readable code.
cheers Chris Maunder
That's who I'd for, but I'd add that most basic data structures have already got perfectly good implementations. You don't normally need to know how a HashMap works inside, only what circumstances that you should use it for.
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
Something's wrong with your interview process. It seems unlikely that a candidate could have mastered object oriented design without understanding encapsulation of algorithms. It seems like someone willing to learn should have picked up object oriented design. You clearly didn't ask the right questions at interviews. Don't hire either of these unqualified candidates. In addition, fire the interviewers.
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
-
Sure. But it's just one guy, it's not like the entire code base is going to be spaghetti just because he's touching it. You can fix his style now, or you can fix his badly performing code now. Or later, but let's do it now. Which one you can actually do depends on the rest of the team.
True true. I'm just playing devil's advocate. Personally I think it would be rare to find two people with such a dichotomy in skill set. Having recently read Clean Code there was a real-life example of some spaghetti code that ended up effectively corrupting the entire code-base because people didn't have time or will to fix it. But it also depends on what the product is. If the entire product and architecture depend on an algorithm then obviously the metrics change. A bad algorithm would be equivalent or worse to spaghetti code.
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
As a manager or architect, I would personally hire A, since again, algorithms can be taught, and clean code will provide the right structure to allow the most appropriate algorithm to be used in the most appropriate place. That being said, the industry seems obsessed with hiring B. In many cases, and I have personal experience here, you can't make it through the final interview if you aren't B.
-
Hire the girl, they can be a pleasure to work with and we need some gender balance in our industry. If one is not a girl then throw em back until you get one.
Never underestimate the power of human stupidity RAH
Well, you could always ask who of the two is willing to undergo a gender transformation ;P
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
main(I,Il)
lOL*Il[];
{ FILE *L;
unsigned lO;
int Q,OL[' '^'0'],llO = EOF,O=1,l=0,lll=O+O+O+l,OQ=056; lOL\*llL="%2x "; (I != 1<<1&&(O1O(QI\[0\]),O10(1011-1010))), ((L = QLQ(Il\[O\],"r"))==0&&(O1O(QI\[O\],Il\[O\]),O10(O))); lO = I-(O<<l<<O); while (L-l,1) { QO0(Q = 0L;((Q &~(0x10-O))== l); OL\[Q++\] = OlQ(L)); if (OL\[0\]==llO) break; O1O("\\0454x: ",lO); if (I == (1<<1)) { QO0(Q=Ol0(QI\[O<<O<<1\]);Q<Ol0(QI\[0\]); Q++)O1O((OL\[Q\]!=llO)?llL:QI\[lll\],OL\[Q\]);/\*" O10(QI\[1O\])\*/ O1O(QI\[lll\]);{} } QO0 (Q=0L;Q<1<<1<<1<<1<<1;Q+=Q<0100) { (OL\[Q\]!=llO)? /\* 0010 10lOQ 000LQL \*/ ((D(OL\[Q\])==0&&(\*(OL+O1Q(Q-l))=OQ)), OlO(OL\[Q\])): OlO(1<<(1<<1<<1)<<1); } O1O(QI\[01^10^9\]); lO+=Q+0+l;} } D(l) { return l>=' '&&l<='\\~';}
What are you trying to say?
In this present crisis, government is not the solution to our problem; government is the problem. ~ Ronald Reagan
Holy crap - is this your best work :)
-
You're a hiring manager. You are responsible for picking a candidate who will be in a long-term position with the company and who you know you will be able to mold/teach. Both candidates are friendly and willing to learn. But there's a slight challenge. Candidate A writes extremely clean and readable code, follows SOLID principles, writes great unit tests, and overall has the software engineering side of things down, but he knows nothing about algorithms or data structures aside from just using what is provided in the standard libraries. Candidate B knows all of the sorts, trees, and hashes like the back of his hand and is able to whiteboard them out no problem and answer all of your questions quickly under pressure. However, Candidate B has no experience with object-oriented design, SOLID principles, has a few demo apps which are only procedural in nature, and has never written a unit test in his/her life. Both candidates are friendly and both seem like they have potential to learn. Your firm uses object-oriented programming in either C# or Java and produces applications that must meet a efficiency standard and also meet OOP design guidelines. Who do you hire and why?
You are filling a void. You mention nothing of the team, or the size of the team. Which of the two candidates is likely to GIVE and TAKE from the team in positive ways. How amenable to tutoring are the two candidates? Code Reviews will help keep the clean code function, which is easier to teach algorithms. Which candidate is most likely to appreciate the growth they need to do the most? Which one has the longest work cycles and the best references? I could hire either, depending on the impact I am willing to absorb, and the effect on the team. If one is a self-righteous SOB, then he will fit right in (LOL, just kidding), we would pass. Bring them both in. Toss them in a conference room with a butter knife and ONE envelope... :-) Inside the envelope: "You are too aggressive for our team, choose the other person!" LOL
