This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (6)
- # architecture (2)
- # babashka (30)
- # beginners (90)
- # calva (21)
- # cider (22)
- # clj-kondo (27)
- # cljs-dev (7)
- # clojure (132)
- # clojure-europe (51)
- # clojure-nl (12)
- # clojure-norway (3)
- # clojure-spec (3)
- # clojure-uk (5)
- # clojurescript (69)
- # cloverage (9)
- # conjure (5)
- # core-async (54)
- # cursive (14)
- # datomic (34)
- # emacs (7)
- # fulcro (10)
- # graalvm (40)
- # graalvm-mobile (2)
- # gratitude (2)
- # improve-getting-started (1)
- # introduce-yourself (1)
- # jobs-discuss (61)
- # leiningen (5)
- # malli (6)
- # off-topic (59)
- # pathom (11)
- # polylith (38)
- # reagent (3)
- # reitit (3)
- # rewrite-clj (3)
- # shadow-cljs (53)
- # tools-build (35)
- # transit (8)
- # vim (62)
- # web-security (26)
- # xtdb (4)
What does "6 year startup that is still pre-IPO who is really shaking things up in our industry" mean? My career doesn't have twice as many years as that. And I also been to university. So I'm puzzled what should one understand from such a statement.
It doesn't mean anything. It's just jargon and buzzwords.
By itself, it's a cheap attempt to make someone interested, to "sell" the company. "6 year" is probably the only useful part of that statement. Chances are, the company won't disappear tomorrow. "Startup" is just a synonym for "company" but with a flair of "we do things differently". Which, by itself, is not useful at all. "Still pre-IPO" means only that there hasn't been an IPO. It can be good, it can be bad - as far as I know, it's impossible to tell beforehand what IPO will change, if it ever comes at all. "Really shaking things up in our industry" - completely useless without actual data.
Ah, this is about the Boulevard job that is Elixir but looking to recruit Clojure or similar developers? I'll mention it to the Admin team...
It's like Uber and Amazon, right? 😄
Yes, that's what I meant. Startup is a reputable business model to attract good talent. They are in a good talent attraction business. 😄
Any tips on preparing for coding interviews? I seem to be particularly terrible at them.
For Google-like interviews you may start with https://www.hackerrank.com/interview/interview-preparation-kit HR has a nice thing that it allows to submit most of the solutions in Clojure.
when I've done technical interviews before as the interviewer I'm mostly interested in helping them to be relaxed
A recent mob programming style interview I did backfired when I told the interviewers “I’m going to do things my way”… It soon became clear that what they wanted was me to solve the problem in a fairly rigid TDD approach. Not that I think this is necessarily a good way to conduct interviews, but it is possible to decode what an interviewer is looking for in certain situations, and to work that in your favour.
@U0525KG62 I include the Practicalli GitHub Org and my practicalli-john GitHub account as the first thing on my CV, along with links to my books. Fairly sure this is never looked at. Neither are the 100+ hours of live coding on YouTube. Perhaps I should explicitly send a video for prospective employers to view.
You could always just go an ask them why the things you sent along aren't sufficient. That might be a good insight into whether or not you want to work for that company
@U05254DQM With your portfolio you should not have to invert linked lists or whatever they are doing now.
Maybe talking to a knowledgeable recruiter and outlining what kind of job you want would work?
Yeah, I tend to suck at those things too - really happy that I didn't have to do them for a few years. In most cases you don't want to work for a company where they insist on ridiculous timeboxed coding exercises
Yeah, I would imagine that someone with your level of contributions shouldn't have to go to interviews 🙂
Coding interviews are just a terrible idea. So many false positives and negatives. The industry is just broken in this area. I've never given a coding interview (with one exception I'll explain next) and I've walked out of interviews that have turned into live coding tests.
When I was just getting started as a hiring manager (back in the early '90s), my boss insisted that I create a coding interview challenge for candidates, even though I'd said they don't work. So I created one and used it on one candidate -- who aced it (as I suspected they would) -- and then said to my boss "You know, if we're going to use a coding test as a way to gauge candidates, we should make everyone on the existing team take it so we have a baseline of how people score at each job grade".
He thought that was a great idea. So, everyone on the team took the test. The senior folks, who'd been promoted into mostly non-coding analysis/lead roles at that point all aced the test. The junior devs all failed it (some failed it spectacularly). Most of the mid-to-senior devs on the team also got less than stellar scores (about half of them passed, and half failed).
Confronted with that, my boss reluctantly agreed that maybe coding tests are not the way to establish whether developers are actually good at their jobs.
(this has been one of my hobby horses for over 25 years!)
Glad I'm not the only one. When I was starting out it really hit my confidence but years later I still wouldn't pass some of the live coding tests I sat through. I resent spending my free time cramming for these things
Cracking the coding interview + http://leetcode.com prepared me enough to do well in a couple of Facebook interviews.
I'm just sad that those things even exist 😞
Thanks everyone for sharing your thoughts and experiences. I think I'll revisit the work I did on 4Clojure and http://Exercise.org along with some other content for the community. I would prefer to do something constructive rather than feel I have to cram for a test (although I appreciate people sometime have to go through that to get a job - unfortunately)
@U04V70XH6 Unfortunately in India that is pretty standard that we had to go through coding tests, questions on API level details which I think is meaningless as the API doc is available to look into. I think an interview should judge a candidate's problem solving aptitude and approach and his ability and willingness to learn new things on job. But unfortunately in India, even many big names that I don't want to mention, don't conduct interview that way.
@U017AGUF30R Not you alone. Me too and even today, can't crack a live coding interview. I don't feel comfortable coding that way, and I fail.
It's not just India. And I wouldn't think India would be different from the rest of the World as whole and in detail. Surely such a huge country has examples of all kinds of practices, just like every other country.
As someone who gives a lot of coding interviews these days, I’d say the single most effective technique IMHO is to always talk through what you’re going to do before you write code — both at the level of “my overall approach to this problem will be X…although, hmm, X won’t scale well, so Y might be better…should I expect it to need to scale?” and at the level of “so now I’m going to write this function F that’ll parse the sequence of integers coming from the caller and return the median value…” Then if someone screws up the code, it’s clear to me as the interviewer that it’s not because they didn’t know what they were trying to do, they’ve just messed up the syntax for something, or forgotten a variable name, or whatever. ie they’re making the same sort of mistake that we all make a hundred times a day. Whereas if they haven’t told me where they’re going, I can’t consistently distinguish those types of problems from the deeper problem of not knowing what they need to do. I also find that really really useful when I’m the interviewee, both for the above reason and because it gives my brain a bit of time to mull over the actual implementation in the background. And I, at least, really can’t talk and write code at the same time, so interspersing them works way better.
That all is something I can second to, however if the interviewee is someone who doesn't feel the vibe of the interviewer, they can simply appear inexperienced. Simplicity in this case would not a be a good thing 🙂
"I’d say the single most effective technique IMHO is to always talk through what you’re going to do before you write code" -- and I'd say that if you can talk through a problem like that in an interview then you don't need to do the actual coding part. When we code, we rely on our editor setup, code assist, documentation, Google/Bing. It's almost impossible to replicate someone's "home" coding setup in an interview context so how they perform on coding in that setup is never going to match how they would perform in their actual job.
@U02T32E0V1B "Unfortunately in India that is pretty standard that we had to go through coding tests, questions on API level details which I think is meaningless as the API doc is available to look into." -- Unfortunately everywhere that is pretty standard. We, as an industry globally, seem incapable of learning how to interview people properly. Managers are focused on coding, coding, coding as if that's the biggest part of our job. It simply isn't. Thinking about the structure of systems, thinking about the trade-offs between several solutions to a problem, communicating with our engineers about ideas and systems, communicating with business folks about requirements and user scenarios. Those are much bigger -- and much more important -- parts of our job. Coding, you can teach. Languages are just tools -- syntax and semantics -- even if it takes years of practice to master idomatic usage.
The ones I do (and this seems typical these days) have the interviewee using their own computer and own setup and sharing their screen. That said -- while I disagree with you at least somewhat on this issue, in practice giving coding interviews is an organizational decision that I had nothing to do with. Regardless, it's hopefully useful information for someone who has a hard time with them, whether or not it's a good idea to give them at all.
One of my poorest coding interview experiences was such that you couldn't really talk much. I got a few algorithmic problems and pretty fierce deadline. I had to share my screen and was supposed to solve the problem within the deadline. I could ask some basic questions if I didn't understand something in the written instructions but a real discussion was impossible as they would not respond to you or interact with you in any way. Horrible and never want to do such a thing again
If you don't feel comfortable at an interview for any reason, it's a red flag that you might not feel comfortable working there. It's not a perfect indicator, my current job is such that all the interviews were great (had a pair programming exercise, but it was more about talking that coding), but then the actual job still sucks.
@U06BE1L6T Back in the '90s, a company flew me from London to Dallas for an interview and there was a horrible coding interview where they shut me in a room with a Windows PC and a print out of requirements and expected me to code a Visual C++ solution in 45 minutes. I'd never used Visual C++ for development work -- I worked on the C++ Standards Committee so I knew what should work but not what was specific to Microsoft's dialect -- and I'd never done development on Windows. I simply walked out, called a taxi to the airport and flew home early. They called a few days later to offer me the job and I said I would never work anywhere that treated people like that.
We should all, as an industry, stop putting up with this B.S.
Coding tests in interviews are often terrible - sometimes pointless, in particular tough algorithm challenges when the actual job is about contributing to yet another webapp that doesn't do anything special - but I had also positive experiences with them, at both ends. If done in a sensible manner, they can be useful, and here useful doesn't necessarily mean "getting/offering/accepting a job". A few elements that made them OK for me and I see they make sense also when I am the interviewer: • the candidate codes on their own machine, not an half harsed laptop provided by the interviewer (candidate can opt in to use a machine provided by the interviewer if at the moment they don't have one); • the challenge somehow mimics a situation similar to work, like trying to add a feature to an existing codebase, where there's room to discuss together what we think of the code base, what we might like to improve and how, while being aware that we are not going to finish everything, that's not the point; • everybody keeps the session fun! It's coding after all. In particular in the first part in my career, I worked for many companies that don't have any coding challenge at all. It doesn't happen all the time, but it does happen to hire people that do talk the talk, but not walk the walk. As interviewer I witnessed myself people not able to write a single line of code, in 1 hour, on their own machine, on a language of their own choice. This is something you want to catch, if the position requires coding and the potential salary is fat 😁 no need to get obsessed by complex stuff, the simplest challenge (even something like "write a function that adds 2 numbers") makes the trick to avoid this failure. It! Could! Work! 🙂
@U017QU43430 tbh, it seems to me you are talking about something I believe can be done without coding interviews, but for some reasons not everyone believes so or tries?
@U017QU43430 well said, that's pretty much my position as well. It can be horrible but it doesn't have to be (especially with an interviewer who tries hard to minimize the inherent stress and awkwardness), and I too have seen it catch applicants who talked a good game but straight-up couldn't write code.
@U0VQ4N5EE what do you have in mind? I sense that an alternative is obvious to you, but clearly it isn't to me 🙂
@U05254DQM I was wondering if: • you received any feedback at all; • you spotted you might prefer or score better with a certain format (take home, pairing session).
@U017QU43430 https://clojurians.slack.com/archives/C0KL616MN/p1644702360573959?thread_ts=1644499191.733749&cid=C0KL616MN this is what I meant
I see a couple of problematic preconditions there: • that an interview happens necessarily on a machine provided by the interviewer, which hasn't to be the case. Working on the candidate machine is a WIN WIN both sides; • it has to be made clear with a candidate that, as they might do at work, searching the internet (google, stack overflow, whatever) is absolutely fine, not the opposite. These are all details that can make the difference between a potentially meaningful coding session and a plain waste of everybody's time. I agree that it's better not having that at all, if the local management/people can only conceive a broken format.
@U017QU43430 In a 25 year software engineering career I don't recall any company has providing feedback as to why I didn't get the job. Most of the time it's pretty obvious to me though and usually down to the interviewers not having a shared view about what is important.
The last interview I did included a live coding test. These are often incorrectly described as pairing or to assess ways of working. But ultimately if you don't solve the problem sufficiently, or forget something, then you are marked down as not being able to code. Any interviewer has their own biases as to what they think should be known / obvious / easy. I haven't ever been in an interview where the interviewer writes code whilst being observed. Ever wondered why that is?
I've been in such interviews, indeed, I've written code in an interview in front of an interviewee and asked their opinion about it. But then, even those occasions, probably the coding part wasn't entirely necessary. Some people dislike using a laptop during an interview, other people dislike the whiteboard, I think it's important to know if someone is not comfortable with either in an environment where everyone expects it, at least the interviewee can see what they are joining.
I have something else lined up for the spring, so I can turn my efforts away from interview preparation and focus on more constructive things for a few months. Although I would have time for some contracting / consulting / coaching work (which I might just branch off to anyway) Thanks for all your feedback.
@U04V70XH6 you spoke my heart!! This is the pathetic reality we live through and that is counter-productive I think.
@U04V70XH6 What is your approach to interviewing a candidate? Is there any coding at all; like fizz-buzz level? Do you talk through a problem or a problem you present a candidate had solved in the past? Is it something else? Is there any effort made to assess a candidate on N parameters or is it sort of overall impression/subjective?
No coding. No tests. I do ask candidates to talk about one or more technical problems they've solved in the past and may drill into specifics. You've seen the mind map I use to guide my interviews? It's pinned here I think.
We care a lot about communication, and we also want to hear about how a candidate approaches testing and automation and their overall workflow.
So many candidates fail on communication skills and critical thinking.