|
my stepdads beer posted:the haskell ones seem cool. statically verifying if your templates are correct html at compile time? drat. don't forget the type separation of code and data which make injection and XSS attacks much harder
|
#
?
Mar 21, 2015 14:23
|
|
|
|
| # ? May 10, 2024 00:53 |
|
|
triple sulk posted:the ruby devs that are still obsessed with ruby are now doing poo poo like ruby together out of a desperate attempt to keep it relevant, or something Rofl A trade association dedicated to paying for the guy who made bundlers beer money more like
|
|
#
?
Mar 21, 2015 17:48
|
|
|
http://techcrunch.com/2015/03/21/the-terrible-technical-interview/ tef is famous
|
|
#
?
Mar 21, 2015 18:33
|
|
|
gonadic io posted:don't forget the type separation of code and data which make injection and XSS attacks much harder not really an inherent property of haskell though, unless there's something i'm missing? most half decent web frameworks accomplish this. maybe i'm an idiot but i don't see what is so unique about all the ~*statically checked*~ magic in frameworks like yesod or snap that isn't accomplished in other languages like c# or java with the added benefit of being more mature, better documented, easier to deploy, etc. etc.
|
|
#
?
Mar 21, 2015 19:19
|
|
|
triple sulk posted:http://techcrunch.com/2015/03/21/the-terrible-technical-interview/ I'm leading a group on improving our interview process at work soon so seeing more like this and the post by the matasano guy on how they did theirs are super interesting. The group I work for hires for entry level positions mostly so deciding based on projects they've already done isn't super practical all the time, but I'm pretty sure we're gonna do some kind of work sample thing.
|
|
#
?
Mar 21, 2015 20:17
|
|
|
rrrrrrrrrrrt posted:not really an inherent property of haskell though, unless there's something i'm missing? most half decent web frameworks accomplish this. maybe i'm an idiot but i don't see what is so unique about all the ~*statically checked*~ magic in frameworks like yesod or snap that isn't accomplished in other languages like c# or java with the added benefit of being more mature, better documented, easier to deploy, etc. etc. ive never used a java or c# web framework, but haskell's type system is better than either of those languages at least
|
|
#
?
Mar 21, 2015 20:24
|
|
|
fart simpson posted:ive never used a java or c# web framework, but haskell's type system is better than either of those languages at least in general heck yeah, a million times better. but frameworks like yesod and snap talk about their magic type safety and how great it is, but i just don't get what it buys you in practice (for the purposes of a webapp) that poo poo like Spring MVC or Play or WebAPI or whatever don't do. url routes in those frameworks will be type checked/validated automatically, templates and form data will have pretty bullet proof escaping by default (for any good framework), form data will be type checked automatically when you marshall, etc. the power of haskell's type system just doesn't seem to buy you a whole lot wrt the machinery of webapps. i'm open to having it explained to me like a baby tho. maybe i'm just too focused on the front end part of it. if you have complicated poo poo going on under the hood written in haskell and you want to expose it through http then i guess it makes sense, but if your app is that complicated you're probably already at the point of pretty disparate front ends and back ends anyway.
|
|
#
?
Mar 21, 2015 20:55
|
|
|
rrrrrrrrrrrt posted:templates and form data will have pretty bullet proof escaping by default (for any good framework), as we learned yesterday, this is a bad assumption to make
|
|
#
?
Mar 21, 2015 21:01
|
|
|
triple sulk posted:http://techcrunch.com/2015/03/21/the-terrible-technical-interview/ quote:Now, this does require one huge prerequisite: every candidate must have a side project that they wrote, all by themselves, to serve as their calling card.
|
|
#
?
Mar 21, 2015 21:40
|
|
|
also the interviewer will require much more time investment per candidate
|
|
#
?
Mar 21, 2015 21:43
|
|
|
comedyblissoption posted:also the interviewer will require much more time investment per candidate I'm not sure this is true when you consider that at many companies interviews are day-long ordeals anyway
|
|
#
?
Mar 21, 2015 22:01
|
|
|
false negatives in the interview process is actually a problem that needs to be addressed though I agree coding on a whiteboard in a technical interview is really loving dumb when you could just use an actual computer instead w/ internet access for most programming jobs doing a basic fizzbuzz screener followed by some basic straight forward collection processing is probably good enough. transform this list of stuff into that other type. group this list of stuff and then count the amount of times x happens in each group. this type of poo poo is required by most programming jobs ityool 2015. don't do technical problems that require you to have an aha moment in regards to the properties and relationships between numbers if you havent encountered that type of problem before unless this is required as part of the job don't do technical problems that require recalling how to efficiently implement in-place array computer science data structures algorithms unless you actually need to implement novel algorithms of this nature as part of the job i think this would decrease the number of false negatives w/o dramatically increasing the number of false positives false positives are not cheap at most corporate cultures for various reasons. being willing to hire people then quickly turning around and firing them in under a month or two has its own cons.
|
|
#
?
Mar 21, 2015 22:02
|
|
|
the main reason technical interviews are needed is because you cannot give candidates the benefit of the doubt. technical interviews are adversial and awkward because unfortunately you cannot give people the benefit of the doubt you unfortunately cannot give a candidate the benefit of the doubt for certifications, technical college degrees, or claimed work experience because people lie about these and people also actually have these while being awful in a typical job board style hiring process, the majority of applicants are the people that have trouble finding gainful employment in the industry because they are bad at it. you need some way to screen these. the people who are not bad have much shorter job search times and are not on the market for long the only way you could make technical interviews not adversial and awkward is to have some way to give candidates the benefit of the doubt without having to technically check them. the only things i can think of that work at scale is professional licensing/certification as exhibited in other fields. this has its own set of large cons though and id rather programming not have this.
|
|
#
?
Mar 21, 2015 22:15
|
|
|
So I'm doing babbys first data analysis in python and I'm trying to figure out how to write things that will scale well to larger data sets. What I want to be able to do is automate the cleaning of the data for multiple datasets. At present I have something that looks like:code:
|
|
#
?
Mar 21, 2015 22:37
|
|
|
vodkat posted:
i assume you are wanting something like code:code:
|
|
#
?
Mar 21, 2015 22:43
|
|
|
i do not understand this hate for whiteboard interview questions are people asking whiteboard questions with the expectation that the candidate will write syntactically correct code with proper use of actual existent library functions? because that is dumb as hell. i ask whiteboard questions and assume the candidate is writing pseudocode that looks vaguely like java or c or whatever, and if i see them wasting time thinking about picky stuff i will gently interrupt them and tell them it doesn't matter. what i am looking for is how they think through the problem and talk about their solution and anticipate problems and respond to questions, and secondarily just to check that they have some basic ability to turn ideas into implementation. it is pretty subjective but in my experience it gives you a very clear picture of their technical ability, maybe i have a ton of false negatives but i don't think so this "let's code review a side project" idea seems really bad. i have no idea who's actually contributed to that side project, maybe the technical design is 90% somebody else and the candidate has just learned to parrot it. and if they re-use this side project across interviews, then guess what, they've basically been coached by previous interviews / code reviews to speak intelligently about that one project. plus you are basically asking to be subjectively swayed by how cool the project seems, without any real sense of how much time the candidate's put into it or whether it was even their original idea. and what do you do if it's a collaborative project, i don't really want to discourage that, but now the existing code tells me nothing. also it is discriminatory in any number of ways because it expects the candidate to have a lot of free time to devote to a side project, which is specifically hard for older and poorer folks who are more likely to have other responsibilities
|
|
#
?
Mar 21, 2015 22:51
|
|
|
it's also discriminatory towards idiot flakes who never follow through on their side projects like me
|
|
#
?
Mar 21, 2015 22:56
|
|
|
rjmccall posted:i do not understand this hate for whiteboard interview questions all the code in my side projects is way lower quality/readability than what I do for work as well. I wouldn't want to be judged on that basis as things I've done on a job are a lot more impressive
|
|
#
?
Mar 21, 2015 22:57
|
|
|
Yeah, the side project interview has all the same problems as getting a job through hackathon/open source/body of github work. While it can be a valid method of discovering someone, expecting it as a primary method of gauging technical ability is just discriminatory.
|
|
#
?
Mar 21, 2015 23:03
|
|
|
i don't understand why interviewers don't just give people the benefit of a doubt and let a 30-day probation period sort out the false positives this job isn't that fuckin hard. if you can fake your way through an interview you'll probably make a fine python janitor
|
|
#
?
Mar 21, 2015 23:08
|
|
|
Valeyard posted:i assume you are wanting something like Yes! this seems to be working well now, but just to be pedantic how would I get everything back under its original name as: everything[1] = dataset everything[2] = dataset2 without having to write everything out? maybe its a bit ott but it seems like having lots of things stored this way and losing their descriptive names might cause me more headaches down the line.
|
|
#
?
Mar 21, 2015 23:15
|
|
|
Corla Plankun posted:i don't understand why interviewers don't just give people the benefit of a doubt and let a 30-day probation period sort out the false positives you waste a lot of time hiring then firing someone in 30 days because you have to on-ramp the hiring process all over again for that position and re-start the training and take a ding to lowered morale for wasting all that time on someone. even in a place w/ the lowest hiring and firing overhead imaginable that's still a lot of wasted time a lot of applicants with seemingly ok resumes will apply for technical positions and not be able to do fizz buzz-caliber questions in an interview or workplace situation. people like this cannot be python janitors you do at least basic screening because it's more expensive not to
|
|
#
?
Mar 21, 2015 23:19
|
|
|
vodkat posted:Yes! this seems to be working well now, but just to be pedantic how would I get everything back under its original name as: im not sure if i am understanding the question correctly, but if you want to maintain those names then it might be better to make "everything" a dictionary, with the keys being whatever the name is and the value being the dataset
|
|
#
?
Mar 21, 2015 23:23
|
|
|
rjmccall posted:also it is discriminatory in any number of ways because it expects the candidate to have a lot of free time to devote to a side project, which is specifically hard for older and poorer folks who are more likely to have other responsibilities it also requires the candidate to be allowed by their current (or a previous) employer to have a side project that isn't owned by the employer.
|
|
#
?
Mar 21, 2015 23:25
|
|
|
Valeyard posted:im not sure if i am understanding the question correctly, but if you want to maintain those names then it might be better to make "everything" a dictionary, with the keys being whatever the name is and the value being the dataset Thanks, as you can tell I'm not really a programmer so trying to wrap my head around how to do things is my major problem atm. I'll play around with dictionaries a bit and try and sort it out that way.
|
|
#
?
Mar 21, 2015 23:28
|
|
|
If the data sets are not known in advance when the program runs but you have some type of name or identifier for each data set, then use a dictionary of keys to values where the keys could be a identifier or string name for the data set. If the data sets are known in advance when the program runs, define a new data structure whose properties correspond to the data sets.
|
|
#
?
Mar 21, 2015 23:34
|
|
|
Corla Plankun posted:i don't understand why interviewers don't just give people the benefit of a doubt and let a 30-day probation period sort out the false positives a bad hire is really expensive, both in direct costs (relocation costs, administrative costs of making hire and setting them up, however many months of salary + benefits, possible damage to code) and opportunity costs (lost chances to hire somebody better candidate, lost productivity from better candidate, lost productivity from everyone they interacted with, lower morale of existing team, increased cynicism of existing team about hiring new people). also a month is a really short time; if you hired somebody bad enough to fire after a month of disappointment, you hosed up badly and you need to seriously reconsider you hiring process. if somebody just was a marginal hire and you hired them anyway, it's probably at least 2-3 months before you realize that your optimistic analysis was not correct the cynicism thing is probably the most important. a team that makes a habit of hiring marginal candidates and then firing them after a month if they don't work out is going to be a team that does not make any effort to invest in its new hires because hey, they'll probably wash out like all the others also the fraud problem gets worse the lower your expectations are, there really are candidates who just make up everything on their resume
|
|
#
?
Mar 21, 2015 23:35
|
|
|
set up a pair programming session where you have the interviewer explain a problem they themselves just had to solve recently and have the candidate do it themselves. have them fix a bug or implement a new case to handle in a certain method or whatever. answer their questions liberally on anything related to the system or let them get away with 'mistakes' that are only mistakes because they've never worked in your code base and don't know how things work yet. obvious weak point is your interviewers can easily get lazy and revert to being shitheads but this is a human process and like any other human process it's really really fallible. idk i think you just have to accept that there will be mistakes and try your best at identifying employees who'd make good interviewers / train them to iron out any bad habits
|
|
#
?
Mar 22, 2015 01:33
|
|
|
my current job was like 5 hours of white boarding but then they're really really forgiving (because they hired me and also because they are) so i dont know
|
|
#
?
Mar 22, 2015 01:34
|
|
|
MALE SHOEGAZE posted:my current job was like 5 hours of white boarding ouch
|
|
#
?
Mar 22, 2015 01:35
|
|
|
your odds of finding a 'perfect' interview process are just as likely as finding a perfect dating process or whatever. you're trying to accurately gauge how a person will behave over years in just a few hours. idk i think the whole discussion would be better focused on accepting the fact that you're going to inevitably hire lovely people and how to handle them once you're stuck with them. for example one of our senior techs has a masters from stanford and a perfect pedigree on paper but irl he's worthless. turns out he's real good at talking with clients so i think my boss just bit the bullet and accepted the fact that he bought a really expensive functional consultant. you win some you lose some
|
|
#
?
Mar 22, 2015 01:37
|
|
|
i think it's okay to hire marginal people since people can get better and be trained if they like the work it's poisonous for an employer to hold out for a magical unicorn developer they can underpay you just want to avoid people where the role is so above their head that your team would've been better off if you had no one in the position and you took the money for their compensation, dug it in a hole, and burned it during the time they were employed which is why a place that has absolutely no technical coding screening should trigger alarm bells
|
|
#
?
Mar 22, 2015 01:44
|
|
|
Necc0 posted:set up a pair programming session where you have the interviewer explain a problem they themselves just had to solve recently and have the candidate do it themselves. does this work for you at your job? do you have a lot of problems that can both be explained and solved in the time frame without any previous context with your system? how do you choose the problems to maintain consistent evaluation criteria? one important technique for reducing the effect of bias (including implicit) in hiring is having consistent questions.
|
|
#
?
Mar 22, 2015 01:44
|
|
|
Subjunctive posted:does this work for you at your job? do you have a lot of problems that can both be explained and solved in the time frame without any previous context with your system? we do both small-scale one-off jobs as well as big ones so with this job it'd be pretty easy to set up a bunch of bite-size problems to work through. most of the questions could be answered by the interviewee knowing how to look at java documentation via their IDE which they should know for this job anyways. this would mostly be your baseline idiot filter so for example: here's this method that's being passed this object. go in and find data x, y, z, do the following calculations/manipulations on it, then put it back into the object. the methods you'll prob be most interested in are a, b, and c but you can drill in and look at whatever you want. for the bigger problems like sys architecture or w/e i think is better handled by just talking to them and asking them about projects they worked on before / weird things that came up during development / lessons learned etc. idk i think focusing on perfect repeatability and consistency is the wrong direction to move in because that road always results in the lovely interviews we're complaining about.
|
|
#
?
Mar 22, 2015 01:51
|
|
|
someone posted a really loving good chart that had dozens of technical competencies listed off and scaled each of them on a scale from 1-4 and while it wasn't perfect that'd be a pretty good guiding document for interviewing teams to use. gonna see if i can find it
|
|
#
?
Mar 22, 2015 01:54
|
|
|
yeah something like this: http://www.starling-software.com/employment/programmer-competency-matrix.html obviously every team is gonna be different so it'd have to be tweaked for each case but training your interviewers to lead candidates into talking about these topics and see how far they get would be a pretty decent approach somewhat objective, allows flexibility and repeatability, shouldn't fall into the traps of lovely 'gotcha' interviews as long as someone is keeping an eye on everything to make sure it doesn't happen. obviously not perfect but better than what a lot of companies have; lightyears ahead of what my company does
|
|
#
?
Mar 22, 2015 01:58
|
|
|
so basically take that matrix as a rough guide, determine which skills and competencies are important to your job, quantify what levels you want your candidates to perform at and then build a few questions / sample real-world problems that encompass those competencies. any time you get a candidate that hits all the correct notes while not coming across as a total creep gets hired.
|
|
#
?
Mar 22, 2015 02:01
|
|
|
Necc0 posted:yeah something like this: http://www.starling-software.com/employment/programmer-competency-matrix.html "Has his own library to help with defensive coding, writes unit tests that simulate faults" lol
|
|
#
?
Mar 22, 2015 02:05
|
|
|
i've been doing a lot of interviewing lately so i've been thinking about this topic a lot. i've found that while it's really easy to point out bad practices there's almost no "good" ones. you're gonna have to sacrifice on something no matter what you do and you'll always have blind spots. best thing you can do is find experienced employees who work really well with lots of different people and try to train them into being dispassionate but helpful interviewers. it's still bad but i think it's the least bad.
|
|
#
?
Mar 22, 2015 02:06
|
|
|
|
| # ? May 10, 2024 00:53 |
|
|
Valeyard posted:"Has his own library to help with defensive coding, writes unit tests that simulate faults" the cool thing is you can change what the levels/competencies are based on the particular job you're hiring for! wow!!
|
|
#
?
Mar 22, 2015 02:09
|
|