|
Obviously, the one without the degree.
Requires less investment in the short term, is immediatly productive and - because he has no degree - you get away with paying him less.
|
|
|
|
|
Depends upon whether I'm going to be hiring a junior or senior dev and you don't specify. You don't really say what kind of role the candidate would be going into. e.g. support, green-field development.
I'd be more inclined to hire developer B because of more experience, but experience doesn't mean as much as people make out when technologies keep changing every 5-10 years.
Consider, every software development team has its own 'culture'. That is to say, their own way of deployment, monitoring and managing faults, source control, standard coding habits etc.
Define what your own culture is and interview both against that criteria. That might be more informative than interviewing against qualifications or any other types of arbitrary indicators you've dug up off the internet.
|
|
|
|
|
Well, since you quite obviously WANT me to say B, I'll say B. Happy?
Now, let's see if we can make this a bit fairer...
- Does Candidate A also know "knows all of the sorts, trees, and hashes and answer all of your questions quickly under pressure."
- Does he also "write extremely clean and readable code, follows SOLID principles, write great unit tests and has good knowledge of Dev-Ops things."
Truth,
James
|
|
|
|
|
It has been quite unarguably revealed to me that my windows tablet cannot survive a fall of 750cm, if bouncing screen-first off a hotel central-heating radiator on the way down.
Points to consider:
1. It's &%$#@!* winio, which drives me up the &%$#@!* wall, it's so bad.
2. It could run programs developed for windows, and those are way more important than the operating system -- I don't buy machines because I want windows; I buy them because I want the programs that non-OS developers have written (who the Hell spends any time doing anything with an operating system?)
(Oh. Sorry. That's a stupid question, really; the response being: Anyone who's installed any windows version higher than weven spends a huge amount of time having to do stuff with the operating system, because that was the penultimate phase in the win-OS evolution, after which the operating system became more important than users and what users need).
3. It's &%$#@!* winio, which drives me up the &%$#@!* wall, it's so bad.
4. I haven't connected to my network back-uppy stuff since Sunday, and everything since then will take a Hell of a lot of effort to recover.
5. It's &%$#@!* winio, which drives me up the &%$#@!* wall, it's so bad.
6. It's &%$#@!* winio, which drives me up the &%$#@!* wall, it's so bad.
7. It's &%$#@!* winio, which drives me up the &%$#@!* wall, it's so bad.
8. Now I have to look for a new tablet (preferably one that will let me choose which OS to install).
9. It's &%$#@!* winio, which drives me up the &%$#@!* wall, it's so bad.
Hmm. I'm glad I vented. It's made things very clear.
It's time to celebrate!!!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
have you tried one of these
Mark_Wallace wrote: &%$#@!* winio
I hear its getting a bit of press lately...
|
|
|
|
|
I'm still trying to see the correlation between winio (I presume this is windows 10) and bouncing the poor bloody thing off a radiator.
Blaming the OS because the screen broke when you dropped the tablet seems a bit of a stretch to me.
I would refrain from chucking the tablet around when you get you new android tablet, try a samsung it will keep you lap/hands warm in those cold winter evenings.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
It's a pros and cons thing.
i.e. I now don't have a tablet that runs programs built to run on windows, which is nice to have -- but, on the plus side, I now don't have a machine that runs &%$#@!* winio.
The pro far outweighs the cons. I should have thrown the bloody thing off a cliff a year ago.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: my windows tablet cannot survive a fall of 750cm
You mean you dropped it from a height of ~2.5 floors (stories, for USians)?
Very few consumer electronic devices could survive that!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Whoa! You guys really Don't know metric!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
750cm = 7.5m = ~8.2 yards. Given a height of ~3m per floor, that would give the 2.5 floors that I mentioned.
Perhaps you meant 75cm = ~29.5 inches?
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Daniel Pfeffer wrote: Perhaps you meant 75cm Whoa! Us guys really don't know metric
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
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?
|
|
|
|
|
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-sh*t.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Clear code, readable and solid (not SOLID) code is very important.
I'd rather be phishing!
|
|
|
|
|
Since it is a long-term position, rather than a short-term or consultant position, I would choose the candidate that would be the best fit long-term. Not every candidate will know everything, if they did, then they'd probably get bored or want a raise and leave. To be the best long-term, I'd think they'd need to show a history of following through on their goals. Candidate A most likely does not have a B.S. programming degree as he/she does not know anything about algorithms and data structures. Candidate B obviously does and was on a learning path prepared from a university, rather than self study.
The 2 candidates both have a place in the industry, but my pick would be Candidate B, because he/she has proven themselves they follow through with their goals and obviously learned something and will continue to learn in the future. Also, I'd choose a candidate from an average to hard program as they have proven problem solving skills; which is what we do.
|
|
|
|
|
B.S. programming degrees vary a lot according to university, region etc...
Today there are many universities that tell all about OOP, SOLID principles etc and yet the teachers themselves don't know much about algorithms... so you cant assume one is self-taught and the other isn't.
|
|
|
|
|
I would take B. As you need efficiency, it may not be enough to use the common algorithms so he will help you there. As for the OO/SOLID/Unit test things - those are easy (relatively) to learn, while learning the secrets of algorithms can be more complicated and may need some affinity+. Be straight and tell him all your concerns and learn what he have to tell about, if he is convincingly ready to learn you probably have the winning hand...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
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?
|
|
|
|
|
Candidate A appears to fit your requirement more closely. Whilst Candidate B has some great skills but has no proven coding ability. Given what you need B would require a longer learning curve to get up top speed. Further, how much of your work requires intimacy with and or creation of complex algorithms?
In any case, hire the one that fits best with the rest of your coders. Getting a good team culture going takes time and effort - bringing someone in who might disrupt that or not fit can be very damaging.
|
|
|
|
|
This looks to me a bit out reality. Like choice between car mechanic that can take engine apart and put it back blindfolded but has no idea how to drive and a perfect driver that can drift around town all day long but can't change a tire. They are two extremes unlikely to happen without anything in between.
But to answer your question I would hire the one that I enjoyed talking to more. The one that is friendlier and seems more team player as it would go a long farther way than any skill he has already.
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
Candidate A.
You can teach algorithms. You can't teach extremely clean and readable code.
cheers
Chris Maunder
|
|
|
|